On Tue, 2003-10-28 at 01:00, joern turner wrote: <snip/>
i think there already have been lots of discussions on this topic but could you nevertheless summarize why XForms is not a good solution for the server-side? - ok, it defines things in terms of DOM and i understand and respect the history of Cocoon and its preferral for SAX based processing. but IMO this might get problematic if it narrows your perception for possible solutions.
are there other arguments beside that?
DOM vs SAX isn't even an issue, if you need a data model, of course you'll use DOM and not SAX.
Some time ago Sylvain Wallez made a comparison between Woody and XML Form (the "XForm implementation" of Cocoon), which you can find here: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105881304808076&w=2
(BTW, don't expect any further reactions from my side if you start rehashing the things said there)
thanks for the pointer - i'll see if theres anything for us.
but all of these have similar goals: to process forms - it would be good to know the strength and weaknesses of each to know when to use the one or the other tool.
Note that it doesn't make much sense IMO to compare Woody to XForms. Woody is about how incoming requests are handled on the server side, what programming interfaces are provided, etc. It would make much more sense to ask why we didn't use JSF.
as already stated: form processing is too complex to find a 'one size fits all' solution when it comes to practice. but it would be a big improvement to establish a standarized markup authors can rely on and a well-defined and accepted logical processing model (however this might be realized).
I'd also like to point out that Woody *is* based on standards: it uses XML where sensible, uses XSLT for publishing, produces standard HTML forms (and could handle other ones as well). It also integrates nicely in Cocoon and Avalon.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
