cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@dff.st>
Subject Re: Flow and XMLForm [LONG]
Date Wed, 22 May 2002 18:42:27 GMT
> I apologize for not crediting you properly.

I meant the people discussing it on the list... not just me :-)

<snip/>

> > 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?

the idea is to have all different kinds of constraints. the most ovious ones 
are probably:

- regexpr
- min length
- max length
- min value
- max value

...just to give you an idea. since those constraint can quite easiyl be 
translate into javascript. so if your validation schema supports a bit more 
than just right or wrong (like an xpath expression is) you will be able to 
have client side pre-processing and server-side double checking ;-)

> 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.)

you mean constraints that depend on some circumstances (nodes ...)?
...that's in the first place again a question of the validation schema - not 
of the framework.

> I plan to take another, closer look at Precept when I have finished my
> excercises
> with XMLForm.

...feel free to contact me directly for questions

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message