<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.
That's exactly the goal of the precept idea... > <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. Yepp! > 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*. Not at all. I have already written a FlashTranformer and a FlashSerializer and am about to put them in scrachtpad (or should I put them directly into the main trunk?) Problem is that the flash stuff is based on project that lacks developers and is not that far yet. But it's a good starting point... I just try to push that project a little so it's enough for a little example. ...don't expect much of it yet(!!) (As far as I heard SWF is a complete nightmare) > 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 Sorry, I don't wanna be picky - but "we" have chosen IIRC > 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? Well, actually my idea was to define validation more expressive so we can even generate client side javascript validations! This should work quite easy if you look at the precept example. I see the problem in a different area: schematron - all you have are XPathExpression constraints. Easy to come up with, but - you only know that a specific XPathExpression failed. This doesn't give useful information for clientside validation. If you had different type of constraints e.g. a regular expression constraint that failed this could be easily translated it into javascript by a stylesheet. <snip/> > 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? Not at all... Unfortunately I am forced not to spent (too) much time on the form handling stuff currently (company's will) but be sure I am still working on it... -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
