cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] what cocoon forms lack
Date Fri, 10 Oct 2003 08:26:41 GMT
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 ;-)

> 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



Mime
View raw message