Thanks to the great energy that Sylvain is able to put into things, we now have a community consensus on making woody the official cocoon form framework.
On the trip back from the GT, I spent some time talking to David Nuescheler. A while ago, I suggested him to take a look at linotype and he liked the concept and told his guys to use it.
On the train, he told me: "you know, the idea of making linotype a woody widget is not so far off as it seems, we did our own form framework and editing framework and came up with nothing that could distinguish the two, so we are making an effort to merge the two".
This triggered an incredible amount of thinking... during the hours that took me to get back and thanks to sylvain's handouts, I was able to have a solid reference for my thinking.
- o -
There are two widgets that cforms are missing:
- editor - uploader
Hey, you know what, some of the people that went to me after my talk proposed just the same ;-)
I see two potential types of editor:
- plain text - stuctured text
Rich text is one of the potential structured text.
I dislike "textarea" as a style if an string input field. it doesn't feel right: a textarea is the style of an editor.
Mmmh... What I understand above is that you distinguish two types of string inputs:
- single line inputs that go through a regular <input>
- multi-line strings or structured documents that go through an editor widget of which <textarea> is a particular representation ("styling", in the current terminology). Am I right?
This also calls for an additional built-in field datatype: "xml", that would automatically parse the input string upon submit. We can also have specialized validators for this datatype that check that the document is valid according to some kind of schema.
I also see two potential types of uploaders:
- active - passive
Passive uploaders are the usual ones, the ones with a input field and a "browse" button. (normally native widgets that are not CSS modifiable)
Active uploaders are the one that react on the content being uploaded and show it (like the image uplaoder in linotype).
Active upload is really cool.
An associated need for upload, along with drag'n dropping images in an editor, is for generic binary attachements to a document (in the general meaning of "document"). Graphically, this could be a drop zone associated to the (growing) list of file names.
The idea is the following: both widgets make available to the controller (after having been processed), an object model that contains the content. The template generators should be able to process the object model of a structured text and crawl it transparently to generate SAX events.
This calls again for the "xml" datatype, with an associated set of converters (xml/wiki/slop parsers).
- o -
Note, however that these widgets don't resolve the need for a semi-structured editing capabilities of the page (a-la contentEditable), but they go a pretty long way to provide capabilities.
Another interesting feature would be providing different "modes" for the editor, just like different tab panes that react on the content.
In linotype you have Wysiwig and markup, introducing a wiki mode is in my todo list.
I would love to have linotype as a cform widget with pluggable editing modes that share content: so that you can write your wiki text, then click on the wysiwig tag and edit content like that, back and forward, you can cut/paste stuff in and out.
Implementation-wise, having multiple simultaneous formats client-side may be require tricky javascript development. Since we must have the parsers for these formats server-side, we can use the "submit-on-change" feature so that clicking on a format tab does a round-trip to the server to convert the format.
now, what do you think?
I think: kewl ;-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
