cocoon-dev mailing list archives

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

Torsten,

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"
and
"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
XPath/Schematron.
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.

--Michael



                                                                                         
                   
                      Torsten Curdt                                                      
                   
                      <tcurdt@dff.st>          To:       cocoon-dev@xml.apache.org 
                         
                                               cc:                                       
                   
                      05/22/02 11:42 AM        Subject:  Re: Flow and XMLForm [LONG]     
                   
                      Please respond to                                                  
                   
                      cocoon-dev                                                         
                   
                                                                                         
                   
                                                                                         
                   




> 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






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


Mime
View raw message