Torsten,
<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... Hmmm... I looked at precept stuff early on, but liked the way Schematron handled phases. I'll take another look... <snip> > > 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) The pace of innovation in this group is amazing. Don't know how anybody keeps up. Wish I could help on this one, but I'm too busy with forms stuff for now... <snip> > > 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 I apologize for not crediting you properly. <snip> > > 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. Regex constraints are more flexible because you can pass the regex string to client javascript for evaluation? What about non regex constraints? I still need rule based constraints as in Schematron, but they need to be represented in a way which can be translated into javascript (i.e. not as non-parsed character data in the "test" attribute.) <snip/> > 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... I plan to take another, closer look at Precept when I have finished my excercises with XMLForm. --Michael --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
