Re: [RT] what cocoon forms lack
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
- multi-line strings or structured documents that go through an editor
widget of which 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.
?
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 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
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
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
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
- multi-line strings or structured documents that go through an editor
widget of which 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
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
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
(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
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
> 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
Re: [RT] what cocoon forms lack
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.
[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.
