cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] what cocoon forms lack
Date Fri, 10 Oct 2003 21:02:31 GMT

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.


Mime
View raw message