You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/10/09 23:28:52 UTC
[RT] what cocoon forms lack
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.
Re: [RT] what cocoon forms lack
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
Re: [RT] what cocoon forms lack
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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
Re: [RT] what cocoon forms lack
Posted by Upayavira <uv...@upaya.co.uk>.
I have a prototype of an upload widget on my HDD. Just need to finalise
a sample before committing. It is what you describe as 'passive'. It
holds within itself the Part when a file is uploaded, which can then be
accessed from flow.
Oh, and I would _love_ to see a CocoonForms linotype widget. Ideas start
streaming forth...
Regards, Upayavira
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
>
> 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.
>
>
Re: [RT] what cocoon forms lack
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Vendredi, 10 oct 2003, à 10:21 Europe/Zurich, Stefano Mazzocchi a
écrit :
>>> ...I dislike "textarea" as a style if an string input field. it
>>> doesn't feel right: a textarea is the style of an editor....
>>
>> OTOH being able to edit (wiki-like?) text from a plain textarea must
>> be possible as a fallback for when people don't have the right
>> browser, mobile stuff, etc. It is certainly easy to do but must be
>> taken into account.
>
> Sure. but you missed my point. The critic was not about "HTML
> textarea" but about where the "textarea" concept resides on woody.
> Today, woody believes that textarea is a "style" of a string input
> widget. I dislike this. I think "textarea" is a "mode" of a
> yet-to-be-there editor widget, exactly for the reasons you mention
> above and because widget should be separate for their use, not for the
> output they create.
ok, got it now ;-)
>>> ...In linotype you have Wysiwig and markup, introducing a wiki mode
>>> is in my todo list.
>>
>> Do you envision a server-side format converter for this?
>
> no, client-side. I plan to write javascript to do this, so that I'm
> able to move back and forward from a wiki view, a markup view and a
> WYSIWIG view from the client side.
Why not server-side java?
Is it a design or implementation concern?
Client-side avoids a round-trip but introduces client dependencies
which could be avoided.
And being able to write pluggable format converters in java for
Linotype editing would be cool. Not sure about javascript.
>
>> ...I'm asking because a good birdirectional wiki-to-xhtml conversion
>> component in java would be very useful. The current chaperon stuff
>> doesn't provide this.
>
> a javascript wiki2xhtml parser would be just as functional and can be
> used on both sides (even if would require some tricky things, since in
> the client side the dom is already there, exposed)
hmm..back to DOM server-side?
(but if you're writing the code and I'm not, who am I to argue ;-)
>> ...I like this - if this is used for our docs later on, being able to
>> cut/paste wiki stuff in and out would be very useful for offline >> work.
>
> yep, the gt-notes-editing experience showed me this as well!
I'm glad to hear this!
-Bertrand
(trying hard to get back to this bread-and-butter stuff ;-)
Re: [RT] what cocoon forms lack
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Oct 10, 2003, at 09:27 Europe/Rome, Bertrand Delacretaz
wrote:
> (commenting on the editor stuff only)
>
> Le Jeudi, 9 oct 2003, à 23:28 Europe/Zurich, Stefano Mazzocchi a écrit
> :
>
>> ...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....
>
> OTOH being able to edit (wiki-like?) text from a plain textarea must
> be possible as a fallback for when people don't have the right
> browser, mobile stuff, etc. It is certainly easy to do but must be
> taken into account.
Sure. but you missed my point. The critic was not about "HTML textarea"
but about where the "textarea" concept resides on woody. Today, woody
believes that textarea is a "style" of a string input widget. I dislike
this. I think "textarea" is a "mode" of a yet-to-be-there editor
widget, exactly for the reasons you mention above and because widget
should be separate for their use, not for the output they create.
>> ...In linotype you have Wysiwig and markup, introducing a wiki mode
>> is in my todo list.
>
> Do you envision a server-side format converter for this?
no, client-side. I plan to write javascript to do this, so that I'm
able to move back and forward from a wiki view, a markup view and a
WYSIWIG view from the client side.
> I'm asking because a good birdirectional wiki-to-xhtml conversion
> component in java would be very useful. The current chaperon stuff
> doesn't provide this.
a javascript wiki2xhtml parser would be just as functional and can be
used on both sides (even if would require some tricky things, since in
the client side the dom is already there, exposed)
>> ...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?
>
> I like this - if this is used for our docs later on, being able to
> cut/paste wiki stuff in and out would be very useful for offline work.
yep, the gt-notes-editing experience showed me this as well!
--
Stefano.
Re: [RT] what cocoon forms lack
Posted by Bertrand Delacretaz <bd...@apache.org>.
(commenting on the editor stuff only)
Le Jeudi, 9 oct 2003, à 23:28 Europe/Zurich, Stefano Mazzocchi a écrit :
> ...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....
OTOH being able to edit (wiki-like?) text from a plain textarea must be
possible as a fallback for when people don't have the right browser,
mobile stuff, etc. It is certainly easy to do but must be taken into
account.
> ...In linotype you have Wysiwig and markup, introducing a wiki mode is
> in my todo list.
Do you envision a server-side format converter for this?
I'm asking because a good birdirectional wiki-to-xhtml conversion
component in java would be very useful. The current chaperon stuff
doesn't provide this.
> ...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?
I like this - if this is used for our docs later on, being able to
cut/paste wiki stuff in and out would be very useful for offline work.
-Bertrand
Re: [RT] what cocoon forms lack
Posted by Gianugo Rabellino <gi...@apache.org>.
Andrzej Jan Taramina wrote:
>>now, what do you think?
>
>
> I think that following/supporting the XForms standard, which seems to be
> getting traction, would be a good thing.
>
> Not sure the world needs YAFF (yet another forms framework).
>
> Or is the NIH syndrome rearing it's ugly head here? ;-)
We have been through this so many times that unless something new (but
it should be _incredibly_ new) comes up the discussion is pretty much
over. Please do dig the archives: you'll find that this XForms/Woody
debate showed up in quite a few occasions and in the end there was
consensus on simply not being good enough for server side form handling.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] what cocoon forms lack
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
Stefano:
> No and the fact that we started with implementing xforms shows it
> pretty well.
I think you missed the smiley on my last line. ;-)
> The XForms standard is a client-side technology. There *is* a block
> that implements form handling in cocoon, but we moved away from it
> because of its design limitations on the server side.
That is not entirely correct. Though XForms can be implemented through a
client-side user interface, it is also intended to be used with XHTML/WML and
other forms of markup and given the slow progress in browser extensions,
presumes the availability of server side solutions as well.
> Simply put, Xforms was designed as a client side technology, and we
> support it that way. (just like we do with cinclude and xinclude where
> cinclude is for the server side and xinclude is left for the client
> side)
I'll check the archives for other discussions on this topic, to understand
the decision that was taken with regards to Cocoon.
In the meantime, I'll stick to Chiba for my standards-based form processing.
;-)
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
Re: [RT] what cocoon forms lack
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Oct 10, 2003, at 01:17 Europe/Rome, Andrzej Jan Taramina
wrote:
>> now, what do you think?
>
> I think that following/supporting the XForms standard, which seems to
> be
> getting traction, would be a good thing.
>
> Not sure the world needs YAFF (yet another forms framework).
>
> Or is the NIH syndrome rearing it's ugly head here? ;-)
No and the fact that we started with implementing xforms shows it
pretty well.
The XForms standard is a client-side technology. There *is* a block
that implements form handling in cocoon, but we moved away from it
because of its design limitations on the server side.
BTW, it is entirely possible to use xforms as the presentation markup
instead of HTML. You can even use XForms inside FO and have a PDF
serialization library come up with PDFForms and some javascript
built-in that sends back the XML-ized form. You can do many things.
Simply put, Xforms was designed as a client side technology, and we
support it that way. (just like we do with cinclude and xinclude where
cinclude is for the server side and xinclude is left for the client
side)
--
Stefano.
Re: [RT] what cocoon forms lack
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
> now, what do you think?
I think that following/supporting the XForms standard, which seems to be
getting traction, would be a good thing.
Not sure the world needs YAFF (yet another forms framework).
Or is the NIH syndrome rearing it's ugly head here? ;-)
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com