On 2001.08.09 22:01:25 -0400 Toby Allsopp wrote:
> On Thu, Aug 09, 2001 at 08:48:45PM -0400, David Jencks wrote:
> > > It will run into problems with complicated data structures because it
> > > pretty much just flattens the XML file into a series of setAttribute
> > > calls.
> >
> > I didn't find this problem, I made a pretty complicated data structure
> > load. I used [collections of] inner classes, and the appropriate
> setXXX
> > method created an inner class instance and had the reflective parser
> call
> > the setYYY on the inner class. This was for the rule engine adapter I
> > worked on, the rules and other config was all in xml.
>
> Cunning. I guess it's not so much a limitation of the technique
> but of my use of it. Perhaps I should factor it out of RARMetaData
> and make it generally accessible.
Thats what I did for my rule engine adaptor. I keep thinking about
converting all the xml reading configuration code. The only thing I didn't
like was all the methods called by reflection had to be public. If you
know a way around this I'd like to know it -- I tried to make an inner
class descend from the reflector but couldn't get it to work, and I think
tried giving the reflection invocation more privileges but couldn't figure
that out either.
>
> > Still I'll have to look at the Castor stuff.
> >
> >
> > Hmmm, just looked at sun - there's something called JAXB that
> apparently
> > compiles an xml schema into a custom parser that does 2 way translation
> > between xml and an object tree. Since this is an impending standard it
> > will presumably be the way to go.. for castor as well.
>
> I don't really like the idea of having to regenerate classes whenever
> the DTD/schema changes, but JAXB does look kind of cool.
I'm not enthusiastic about the resultant code, however it's not like we
have to look at it. I think it might actually be really good, since:
1. dtd changes
2. regenerate base classes
3. try to recompile the derived classes that have our functionality.
If we missed something in taking account of (1), (3) will almost certainly
fail.
Hmm, I haven't seen yet how the parsing is going to construct a tree of
subclasses of the generated classes rather than the generated classes
themselves. Have to keep reading.
david jencks
>
> Toby.
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
