True, but that's not necessarily why we use Digester (avoiding DOM). Sometimes folks (like Tomcat) use Digester to just parse some simple configuration files. But, if you are parsing some *huge* file and processing it as you go along, the XSLT method might not work.
-----Original Message----- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Friday, August 11, 2006 9:01 AM To: Jakarta Commons Users List Subject: RE: Digester and Inheritance Hi James, On Fri, 2006-08-11 at 07:38 -0400, James Carman wrote: > The XSLT solution isn't really that bad. The XSLT would be somewhat trivial > (if you're familiar with XSLT). True. However wouldn't the xslt engine potentially need to load the entire document into a DOM or equivalent in order to execute the reordering [1]? That rather kills the point of using a sax-based library like Digester ;-). [1] Potentially, an xslt engine can do clever analysis to figure out what parts of a document it can discard after reading. I know some people were working on this for xerces, but don't know how far advanced it is or whether it would apply in this case... Cheers, Simon > > -----Original Message----- > From: Simon Kitching [mailto:[EMAIL PROTECTED] > Sent: Friday, August 11, 2006 7:31 AM > To: Jakarta Commons Users List > Subject: Re: Digester and Inheritance > > Hi German, > > On Wed, 2006-08-09 at 14:18 -0300, German Balbastro wrote: > > I have an object model whith an abstract parent class Class1 and two > > implementations Class2 and Clas3. > > > > I don't know how i can create the implementations. > > > > For example i have this xml file: > > > > <Class1> > > ... fields of class1 ... > > <Class2> > > ... fields of class2 ... > > > > </ Class2> > > </ Class1> > > <Class1> > > ... fields of class1 ... > > <Class3> > > ... fields of class3 ... > > > > </ Class3> > > </ Class1> > > For this example, digester should create one instance of Class2 and one > > instance of Class3, and in both cases setter the attributes for the > > class and for inheritance for the parent class. > > > > I need to know how to create the digester's rules. > > It's not going to be easy to process this format of input with Digester. > Digester is sax-based, so there is no way of saying "when tag X is > found, get data from some tag that comes before X". > > Or in other words, data must be processed when it is encountered, not > later. > > If you could use the format suggested by Fabian Sergio de Rosa then > there would be no problem: > <Class2> > ...fields of class1.... > ...fields of class2.... > </Class2> > > Maybe at <Class1> you could create some Hashmap-like object, and store > field data into that. Then when you get to a Class2 or Class3, you could > use reflection to copy values out of the map into your newly created > Class2 or Class3 instance. Don't know if this will work, but even if it > does it isn't pretty. > > Or maybe you could run the input through an XSLT stylesheet to reorder > it into something easier to deal with? > > However unless the input data is very large, I would suggest instead > reading the document into memory as a DOM and then walking it to build > your necessary objects. Using DOM gives you that "access earlier data" > feature you need, but of course at the price of a performance hit and > extra memory usage. > > Sorry the answer isn't more positive, but I can't see any easy > solution.. > > Regards, > > Simon > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
