Both of you have good points, guys.
I am not sure what is the answer to these tough questions. And I certainly don't mind any further extensions that will benefit Cocoon users. I can only say that the next thing I'll be working on is to show how XMLForm can be used to write REST oriented Web Services. Before I started commiting code to Cocoon, I was looking for a framework which will allow web apps to be written and then web services enabled with little effort. This is a real business drive for me for real enterprise projects. The functionality is already in XMLForm. What is missing is a good test case. I hope the feedback wizard is a decent example of how user interactive pages are written. Now I am planning to use AntEater to demo how the wizard can be used as: 1) Web Service 2) remote portal plug-in. RSS has been successful for static remote content. It's time to show how interactive forms can be embedded remotely. Regards, Ivelin ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 21, 2002 4:19 PM Subject: Re: Flow and XMLForm [LONG] > > Hello, > > > From: "Ovidiu Predescu" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Monday, May 20, 2002 10:03 PM > > Subject: Re: Flow and XMLForm > > <snip /> > > JavaScript client validation improves the user experience quite a bit, > > so I think a validation solution should generate both client and > > server side validation code. > > <snip /> > > Yes, but that doesn't solve the problem for current browsers that > > don't support XSLT (Opera, Konqueror? etc.), or for older browsers, > > which support JavaScript only, or WAP, iMode, and many other browsers > > integrated in small devices. IMO Cocoon should be able to reach these > > not so mainstream browsers as well. And do a good job at supporting > > them, by providing the their users with the best possible user > > experience. > > Ovidiu has a point here. Javascript is widely supported in browsers, available > for PDA's > (http://industry.java.sun.com/javanews/stories/story2/0,1072,41318,00.html) and > wireless devices (WMLScript). Usability is a key feature of any forms > technology. Just point a Flash 5.0 enabled browser at > http://reservations.broadmoor.com/ to see usability on steroids. Consider that > there are already xml converters which produce binary .swf (.cfm) files. Maybe > supporting such media in Cocoon is pretty distant, but supporting usability in > general shouldn't be: usability is an issue *now*. > > Here's a *basic* form using client side javascript: > http://www.applyweb.com/public/contribute?cmsccard > Yes, you could do all the validation/calculation server side, but there are so > many dependencies that pressing the "calculate" button could result in multiple > interrelated errors. (Quantity must be greater than 3 if "Imprint" is true; sum > of all imprints must be less than 70; all Quantities must be numeric; all > Amounts must be floats rounded to hundredth; Total depends on Imprint Total > which depends on Quantities and Imprint, etc. And this is a *basic* form.) > Maybe all such form "behaviors" could be implemented on the server for embedded > internet devices, but browser users demand a much higher degree of usability. > > The current incarnation of XMLForm could not directly handle a form like this > one; neither could any XForms equipped browser that I have seen (including the > most recent version of XSmiles). The XForms language itself has pretty limited > syntax for expressing dependencies and calculations. Ivelin has choosen to > support a subset of XForms behavior on the server- a useful limitation. XMLForm > plus authentication/authorization plus database integration should serve the > needs of many (most?) form developers. > > But some form developers will require something like what Ovidiu has described. > Writing validation routines in javascript for both server and client grants the > developer a "behavioral flexibility" that XPath/Schematron just can't match. > Maybe no XML based language would have the necessary expressiveness. The > problem is that the developer might pay a pretty high price for such > flexibility! Create "custom" javascipt for *each* form? Even using standard > validation libraries this would take far more effort than writing Schematron > rules. How can such a process scale? > > I think there are potentially three broad use-cases, and possible three > different form module solutions: > 1) USE_CASE: "simple" forms: forms with one or a few "views", limited > behavioral repetoire, relatively "simple" validation rules, straightforward > usability requirements. SOLUTION: Precept, XML Form, a combination of these? > 2) USE-CASE: "complex" forms: forms with many (10-20) views, dozens of > widgets per view, complicated behavioral requirements, complex validation or > depenedency rules, or usability "issues". SOLUTION: flow engine with > javascript validation ?? something else ??? > 3) USE-CASE: "industrial forms". Same as complex forms but even more so, > and with the additional requirement that form development must scale. Hundreds > or thousands of forms developed, supported, and maintained per year. SOLUTION: > (I think) must emphasize form components written in "pure" XML markup (leverage > contenxt checking, document validation, helper technologies) rather than java or > javascript. > > But as Thoreau says, "one world at a time". XMLForm is useful *now*. Anyone > interested in forms should check it out in detail. I just asking: isn't there > room in Cocoon for more than one way to handle forms? Could any one forms > "solution" handle all the wacky kinds of forms out there? Shouldn't there be a > simple solution for people who need to handle "simple" forms, a more complex > solution for people who need to handle "complex forms" (and are willing to pay > the price) and an even more complex solution for people who need to handle > "industrial forms" (and are *really* willing to pay the price). Or do my > use-cases #2 and #3 simply exceed the bounds of what Cocoon was/is intended to > do? > > Cheers > --Michael > > > > > Ovidiu Predescu > <[EMAIL PROTECTED] To: "Ivelin Ivanov" <[EMAIL PROTECTED]> > g> cc: [EMAIL PROTECTED] > Sent by: Subject: Re: Flow and XMLForm > [EMAIL PROTECTED] > up.hp.com > > > 05/20/02 11:04 PM > Please respond to > cocoon-dev > > > > > > > On Tue, 21 May 2002 00:12:16 -0500, "Ivelin Ivanov" <[EMAIL PROTECTED]> wrote: > > > ----- Original Message ----- > > From: "Ovidiu Predescu" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Monday, May 20, 2002 10:03 PM > > Subject: Re: Flow and XMLForm > > > > > > So there are three ways an XMLForm-like capability could be > > > implemented: > > > > > > - translate today's XPath-based Schematron to JavaScript scripts for > > > both client and server side > > > > > > - translate a constraint expression syntax, not based on XPath, to > > > JavaScript for client and server side > > > > > > - write the validation functions in JavaScript, same scripts being > > > used on the server and client side. > > > > > > I don't know about you, but the last approach looks to me being the > > > easiest one to implement (basically write your scripts). One problem I > > > see with it though is ties the validation to JavaScript, making it > > > difficult to support clients that don't run JavaScript, like browsers > > > on WML phones (although the language used is very similar). > > > > Just a note in regard to client/server side validation. > > New generation browsers support XSLT. > > Which means that Schemtron validation can be run on the client as well. > > Haven't tried it myself. > > Yes, but that doesn't solve the problem for current browsers that > don't support XSLT (Opera, Konqueror? etc.), or for older browsers, > which support JavaScript only, or WAP, iMode, and many other browsers > integrated in small devices. IMO Cocoon should be able to reach these > not so mainstream browsers as well. And do a good job at supporting > them, by providing the their users with the best possible user > experience. > > > I am speculating that XML standards will be better supported in the long run > > than ECMAScript based languages. > > Supporting standards usually takes a very long time, you cannot assume > everybody will support the latest standards. Even then, you still have > to support older browsers that don't adhere to the latest > standards. Just look at how many JavaScript versions and variations > are in today's Web browsers; it's a total mess! Nevertheless, good > service providers try to support them all. > > > Regards, > -- > Ovidiu Predescu <[EMAIL PROTECTED]> > > >>> I'm in the job market again, check out my resume and qualifications at: > http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
