Arron, I agree with the analysis. There are of course other tools that do similar things (including the Digester) but I've seen no others that do all three (XML/Schema/SQL) at least opensource. It seems like a natural way to proceed in order to automate some of this stuff. When I noticed that you could get Castor to generate beans with the validate method I thought the author probably had Struts in mind.. If I get a chance, I'll look into it further.
Thanks, Jon Arron Bates wrote: > Jon, > > I'm quite certain the parser has the ability, it just doesn't do it. > It's the generation of the Java code which is stopping it. I would think > you could hack it, so when an object's setter is called automatically > call it's validate() method (which the system creates both, so all you'd > have to hack is when and where) for each object continuing to set all > data (it carries invalid data quite happily, only complains when you ask > it to marshal the document out or validate it) and remember all the > validation errors which were thrown and just pop them into the pile for > Struts. Could be groovy... but it's not an out-of-the-box ability. > > I've only had the chance to use the schema side of the matter. We use it > to create the XML documents against the schema, when we have to do > something which requires XML. I don't think my current client is a > particular fan of XML per-se. > > Arron. > > Jon Ferguson wrote: > > >Arron, > > > >Thanks for the hands-on. Shame really.. surely the parser provides this data.. > >wonder if there's another way to 'compile' that information into a method. > > > >BTW, have you used Castor's Object-Relational mapping? The second half of the > >equation would be to use that to persist the populated beans from within the > >Action. > > > >Cheers, > > > >Jon > > > >Arron Bates wrote: > > > >>I've tried to do this with Castor generated objects. Problem is though, > >>is that the errors are not fine grained at all. > >>You validate the document by calling the validate() method on the top > >>node, and you get a yes or a no. > >>You can do this for all of the sub objects, but it's just that, you > >>still have to implement the field validation yourself. > >> > >>Naturally you can't play any tricks with the calling of property methods > >>to work around various issues as your objects are locked down to the > >>automation process. > >> > >>Otherwise it's quite excellent. > >> > >>Arron. > >> > >>Jon Ferguson wrote: > >> > >>>( Republished under appropriate Subject :-( ). > >>> > >>>Hey, > >>> > >>>I've been toying with the idea of Modelling my form beans using XML Schema, > >>>then generating the actual beans using some XML binding tool like Castor (which > >>>should also generate my validate function). I should also be able to use > >>>Castor to do RDBMS mapping as well.. (but from a session bean manipulating the > >>>formbeans for example). > >>> > >>>I'm thinking of utilising schema from developments such as RosettaNet, BizTalk > >>>Frameworks and ebXML - noting that often the info entered into forms could be > >>>the same message information that might be passed between businesses. (Eg. a > >>>Purchase Order, etc.). > >>> > >>>I'm hoping that the result would: a) help to standardize the business app. b) > >>>leave it wide open for making use of b-2-b developments such as webServices and > >>>the above efforts. c) provide automatic form validation (inherent in the > >>>Schema), d) obviate the hand-coading of formbeans. > >>> > >>>Any comments on this approach? Has anyone tried this? > >>> > >>>Cheers, > >>> > >>>Jon > >>> > >>> > >>>------------------------------------------------------------------------ > >>> > >>>-- > >>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > >>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > >>> > >>-- > >>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > >> > > > > > >------------------------------------------------------------------------ > > > >-- > >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > Part 1.2 > > > > Content-Type: > > > > text/plain > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
