FWIW the betwixt subproject in the sandbox is an attempt to provide bean to
XML mapping meta-data in a similar way to what the java.beans.BeanInfo and
Introspector classes do for mapping a bean to properties & events.
At the moment I'm focussing mostly on mapping a bean into XML so that XSLT
and XPath can be done on them - though it wouldn't be that hard to make the
mapping bidirectional. (Then we'd have the basis of a bidirectional bean <->
XML serialization framework). So given a mapping of a bean <-> XML mapping
via betwixt it could be possible to auto-generate digester rules that could
turn the XML into the beans.
Just a thought...
James
----- Original Message -----
From: "robert burrell donkin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 27, 2001 6:39 PM
Subject: Re: [digester] dynamic digester via DTD/Schema
> On Monday, August 27, 2001, at 12:57 AM, Craig R. McClanahan wrote:
>
> > On Sun, 26 Aug 2001, Jason van Zyl wrote:
> >
> >> Date: Sun, 26 Aug 2001 19:15:29 -0400
> >> From: Jason van Zyl <[EMAIL PROTECTED]>
> >> Reply-To: [EMAIL PROTECTED]
> >> To: [EMAIL PROTECTED]
> >> Subject: [digester] dynamic digester via DTD/Schema
> >>
> >> Hi,
> >>
> >> Has anyone played with making a Digester that works generically from a
> >> DTD
> >> or Schema? Robert, I think you started something yes? It would be very
> >> cool
> >> point a DynamicDigester at a DTD/Schema and not have to worry about the
> >> making the rules yourself :-)
> >>
> >
> > I can see how you'd decide what patterns made sense from a DTD or a
> > Schema, but how would you decide what rules to fire? Even if it's a
> > simple "instantiate an object tree that is isomorphic to the XML
> > document", you'd still have to decide how to map XML elements to Java
> > class names, deal with attribute<-->property mismatches, and so on -- to
> > say nothing of figuring out what method names to fire for SetNextRule
> > calls ... by that time, you might as well just go ahead and make the
> > rules.
>
> (it depends on how complex the schema is. i bet that the batik team over
> in xml-land really loved having to rewrite their DOM implementation when
> the standards body changed the SVG schema. generating DOM implementations
> seems easier to me :)
>
> in general, i think that craig's right. xml-> object model mappings can
> get very complex and - in general - there's no way to avoid a lot of
> effort.
>
> *but* so long as we're not trying to create a generic solution, a solution
> for common mapping problems might be useful. i've hand-coded digester
> rules for reasonably large schema's and it does take some time and effort.
> for complex mappings, you probably have to hand-code the rules - but for
> simple, regular mappings it could save a lot of time where you have a
> large number of elements. also it might save the time needed to learn
> digester rules in detail. at the very least, it'd be useful to have most
> of the code generated and then start tweaking the complicated bits.
>
> in many cases you'll want xml to be represented by nice familiar java
> beans - and these beans will probably follow a very simple set of naming
> conventions.
>
> for example, elements map to object names and attributes to bean
> properties. a more variable question is how child objects attach
> themselves to their parents. in java, a one-to-one relationship might be
> mapped to a property and a one-to-many to a appendXXX method. a common
> naming convention would be to use the name of the object. (the one thing
> that i can't guess is where the body text would go - into a constructor
> maybe?)
>
> in this way you can come up with a set of conventions (extending the java
> bean naming conventions) that you can generate beans and rules from.
> equally well, you can dynamically create these rules from the schema and
> use existing beans.
>
>
> i have been thinking about the problems of naming mismatches similar to
> the ones that craig's raised and there's no getting away from them - but
> in the cases that generated rules would be useful, i don't think that they
> are such a problem. for generated beans, there would be no problem with
> mismatches. for xml schema produced with the intention of mapping to an
> existing java object model, then there should be no problem so long as the
> xml naming is created sensibly from the model. (i suppose that the xml
> schema could be generated by introspection in the first place in this
case.
> ) if people found that this was so amazingly useful that they wanted to
> extend it beyond this kind simple stuff then they could always submit
> patches :)
>
>
> in terms of technical details, i have been working on an extension to the
> standard patterning matching rules that allows (amongst other things)
> these kinds of relationships to be specified concisely. the reason why i
> haven't submitted it (yet) is that the algorithm is really pretty complex.
> i think that it's debugged now but i want to create a set of unit tests
> to make sure that it does what it should and also come up with a document
> detailing the matching rules and how they apply in combination. this will
> take some time and isn't a huge priority for me at the moment. (with a
> little prodding i could try to push it higher or submit a beta.)
>
> - robert
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
