On Friday, Oct 10, 2003, at 10:26 Europe/Rome, Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
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 ;-)
great
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?
yes
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'm thinking that naming a widget based on what it creates is a bad pattern. I think we should name the widget on what it does.
editor in "structure text" mode, will generate XML.... i see no reason for a structure text mode to return something else.
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.
yep
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.
<uploader mode="list"/>?
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).
no, again, I think that both you and Bertrand tend to look at this from a server side perspective.
- 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.
don't think so. it's basically parsing a string, you'd not be using any browser needs, just pure javascript regular expressions.
Since we must have the parsers for these formats server-side
why?
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.
that would be orders of magnitude slower and much more subjective to failure! I would love to reduce roundtrips (even for <groups> BTW, I think they should be handled client side)
now, what do you think?
I think: kewl ;-)
all right, so, how do we move on?
-- Stefano.
