Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Thu, 9 Oct 2003 23:28:52 +0200
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Subject: [RT] what cocoon forms lack
From: Stefano Mazzocchi <stefano@apache.org>
To: Apache Cocoon <dev@cocoon.apache.org>
Content-Transfer-Encoding: 7bit
Message-Id: <9459E432-FA9F-11D7-90C3-000393D2CB02@apache.org>

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

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.

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).

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.

                                     - 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.

now, what do you think?

--
Stefano.