cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Flow and XMLForm [LONG]
Date Wed, 22 May 2002 21:32:10 GMT


I guess it depends on what one means by constraint.  XForms allows constraint
dependency rules described using XPath.  So if you have two fields, "CLASS_RANK"
"CLASS_SIZE"  you can (I think) write a rule that says "value of CLASS_RANK must
be less than or equal to CLASS_SIZE", i.e, something like:
      <xforms:bind ref="instance/CLASS_RANK" isValid="current()
<= ../instance/CLASS_SIZE" />

But even if you have such an XPath expression, it's just text to a parser--
nothing to
parse.  And so, very difficult to translate into javascript.  If instead you
have a regex constraint
you don't need to parse it, just drop the string into a javascript object and
create the handlers
that call the right method..

Anyway, I need to handle forms that have much more complicated dependencies
than the simple CLASS_SIZE/CLASS_RANK example given.  Such dependencies
are easy to "describe" in javascript,  difficult to describe in
So now I'm thinking about some kind of  "ur-language" for describing dependency
(and other?) relationships, abstract enough to be translateable into Schematron
rule markup, javascript procedural code, or whatever else is needed.


                      Torsten Curdt                                                      
                      <>          To: 
                      05/22/02 11:42 AM        Subject:  Re: Flow and XMLForm [LONG]     
                      Please respond to                                                  

> I apologize for not crediting you properly.

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


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


To unsubscribe, e-mail:
For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message