cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@iname.com>
Subject Re: Cocoon Form binding and validation [was: RE: SchemoX forms]
Date Thu, 28 Mar 2002 13:58:56 GMT
Mats,

Thanks for the response, hope Koshuke can help with the open questions.

... see below ...

----- Original Message -----
From: "Mats Norén" <mats@alma.nu>
To: <cocoon-dev@xml.apache.org>; "Ivelin Ivanov" <ivelin@sbcglobal.net>
Sent: Thursday, March 28, 2002 5:16 AM
Subject: Re: Cocoon Form binding and validation [was: RE: SchemoX forms]


> The SaxErrorHandler can, to the best of my knowledge, NOT provide you with
> the XPath location of the bad element,
> a quick workaround is to implement a tag tracking Stack in the
errorhandler.
> I build the XPath-expression when the events flow in and when an error
occur
> in an element I peek at the stack and use that as the location.
> In an conversation with Kohsuke Kawaguchi, the developer, he proposed the
> following solution:

That is a possible solution.
Developers which are validating DOM and JavaBeans would be really interested
in a set of XPath locators with corresponding error messages. So I guess
JARV is the validator skeleton which can be wrapped around Torsten's API and
used for its broad schema support.
If you have experience with JARV, can you scetch how the new/fast Schematron
validation can be wrapped in JARV without loss of efficiency?

> <paste>
> Umm, I'm not sure if I want to add such a specialized capability into
> the generic verifier implementation.
>
> It seems like the same goal can be achieved by using a SAX XMLFilter.
> Let's say there is an XMLFilter that tracks XPath. You can set up the
> pipeline as follows
>
> parser --> XPathTracker --> VerifierFilter --> YourHandler
>
> XPathTracker and VerifierFilter don't know anything about each other.
> XPathTracker will update XPath information before it passes an event to
> the next handler (in this case that's VerifierFilter.)
>
> Once an error is reported by VerifierFilter, the error handler can ask
> XPathTracker about the current XPath, it can then process
> ValidityViolation with XPath.
>
> XPathTracker only need to track element-level XPath. I can update MSV to
> report more information about attributes (i.e., which attribute went
> wrong? was it because of the bad value, or the attribute is undeclared?)


Would be very helpful. I guess the layer above JARV will have to convert
these errors into human readable messages.
Is this always possible? Can MSV report if the name attribute was NULL or it
was bigger than 30 characters? Both these constraints can be expressed with
XSD, so they can probably be reported as well. I guess the issue how to plug
that information in a standard API which will work well enough for different
schemas.
Have you considered support for Schematron and other rule/semantics based
schemas or just grammar based schamas ?
The nice thing about Schematron for user input validation is that it can
report a human readable message back.


I have also like to get some response to the question of JavaBeans
validation. Domain object validation through schemas is useful, how does it
work with JARV?

To restate my question again:
The API is designed to work with DOM. So when I would like to
validate domain objects as JavaBeans, I'll need to first convert the
JavaBean to DOM with Castor or similar, before I can validate it? Is there a
more efficient solution, similar to the JXPath based Schematron
implementation, which only travers to the JBean/DOM nodes which need to be
validated?



> </paste>
>
> > Also, how would you use JARV to implement partial document validation?
> > For example if you want to validate the user/car-info/model element, but
> not
> > necessary the whole user element.
>
> With MSV you can verify a single DOM Node and not the entire document.
> verifier.verify(Node node) should work as well as verifier.verify(Element
> element)

OK. So if you want to validate a set of nodes (a phase) you'll need to rerun
validate on each one?

> > BTW, what exactly is the MSV license. It seemed like its was open
source,
> > but it wasn't very clear to me. Is it compatible with Apache's?
>
> Not sure about that. The best thing to do is to ask the developer Kohsuke
> Kawaguchi.
> kohsuke.kawaguchi@sun.com
>
> >
> > Cheers,
> >
> > Ivelin
> Regards,
>
> Mats
>
>
> ---------------------------------------------------------------------
> 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