You can clone with
HTTPS or Subversion.
Add github like editor that enables content to be stored (and then rendered) in multiple formats (markdown, textile, html etc.).
got any plans for how to upload and format images within content?
nice project, btw.
in what places would you like to see this editor?
The media module will manage images, but hasn't been written yet, then it needs to be connected up to the content wysiwig editor ... I was going to do the two separately (so people could use different ones), and then join them together at the front end - very open to ideas on this one as it is quite a bit of work to get right, and we probably wont get it right first time!
cole: wherever there's a textarea ...
clifton: doing them separately sounds right. I'm working on a similar project, stitching together express, mongoose and sammy : my plan is to try to bash an existing out-of-the-box wysiwyg editor into it, then have a separate dedicated general-purpose file uploader.
I have (quite) a few more basic things to get done first, but I'll check back in once I'm focussed on the editor.
If only all existing wysiwyg editors didn't suck so much :)
I've seen a couple of different ones mentioned recently that look interesting:
https://github.com/twoism/reviser was used as a base for a custom editor by the drupal based http://www.pagebuild.net/ - the MIT license of reviser makes for easy inclusion into calipso, though it's age presumably means it needs work.
And a radically different approach, inline DOM based editing http://www.aloha-editor.org/ which is interesting in the sense that pages in a cms are often built with content from different modules. Rather than 'written' in a wysiwyg editor. License is AGPL. So, an interesting approach that may be emulated, and solve some of the UI issues wysiwyg editors have.
Agree - I think in line editing should be the aim, and shouldn't be difficult - just need to enable posting of json back to the content update function (with support for partial updates) to speed things up and make sure we aren't sending around the whole content object each time, and ensure that when we render blocks of content that we do so in a consistent manner that enables us to locate contents identifier at all times.
As long as aloha is implemented as a module, I don't see any issue with it being AGPL - it would be up to the site builder / user to choose to use it, our code would just wrap it (but not include it in core) ...
Can we collaborate on aloha integration. I've downloaded the latest version of aloha an updated the core aloha module and the aloha.styles.html template is not being rendered. I don't see aloha.css included anywhere. How is the integration going to work? Currently it looks like aloha is being called on textareas but I think it should be on content-block spans to enable in content editing.
The aloha integration is part of the published module. There might be defects but this has been completed.