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]
