Hi Tim, One of my key goals is to ease integration with B2B and webservices. I'm finding that lots of what's in my current project would fit this framework well.. For instance I have an Order form.. But why should this just be entered from a web form using Struts. I'd like to be able to export the Schema and have some other app send me Orders which my app already knows how to work with. Using a standard schema would be great. I guess from this perspective I'm thinking of starting with XML.
Cheers, Jon Stephenson Tim wrote: > guys, > > thought i'd throw in my 2cents as i enjoyed reading your discussion so far. > > i have been trying to solve the same problem - to generate the struts forms > and resource properties (maybe actions too). First there was a chap posted > an announcement to the list recently to that used XSL transforms acting on > the struts config did you see it? And secondly i use XMI (XML Metadata > Interchange) from the OMG to model the metadata before applying another set > of XSL transforms to generate the code. > > I guess the question is with the proliferation of metadata (all in XML of > course!) what is your preferred starting point? > > rgds, tim > > -----Original Message----- > From: Jon Ferguson [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 10 January 2002 7:22 PM > To: Struts Developers List > Subject: Re: Building Form Beans from XML Schema? > > 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]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
