commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: (Betwixt) a task for a volunteer [Was Re: digester data to XML]
Date Wed, 06 Feb 2002 19:25:46 GMT
Hi Slawek

----- Original Message -----
From: "Slawek Zachcial" <slawek_zachcial@yahoo.com>
> Hi Robert,
>
> I'm still digesting the betwixt code :-).
>
> For XMLBeanInfo in the classpath my understanding is
> that customization you want to achieve is to specify
> what should be the element and attribute names in the
> generated XML and how they map to the real bean
> properties right? So for example for CustomerBean the
> XML generated is
> <CustomerBean>
>    <projectMap>
>       <entry>
>          <key>jaxen</key>
>          <value>http://jaxen.org</value>
>       </entry>
>    </projectMap>
>    <projectNames>
>       <String>jaxen</String>
>       <String>jakarta-taglibs</String>
>    </projectNames>
> </CustomerBean>
>
> and with this XMLBeanInfo we could have sth like
>
> <customer>
>    <project-map>
>       <project>
>          <project-name>jaxen</project-name>
>          <url>http://jaxen.org</url>
>       </project>
>    <project-map>
>    <project-names>
>       <project-name>jaxen</project-name>
>       <project-name>jakarta-taglibs</project-name>
>    </project-names>
> </customer>
>
> Is my understanding correct?

Totally - this is pretty much what I'd like to do.

>
> My first thought would be to have, for a class
> acme.CustomerBean, the XMLBeanInfo as xml file located
> in the classpath and called /acme/CustomerBean.xml (or
> CustomerBean.xmlbeaninfo, or CustomerBean.xbi, or
> ...).
>
> This file would look like:
> <element localName="xxx" qualifiedName="aa:xxx"
> uri="yyy">
>    <attribute
>       name="name"
>       localName="custName"
>       qualifiedName="aa:custName"
>       uri="yyy" />
>    <element
>       name="projectMap"
>       localName="project-map"
>       qualifiedName="aa:project-map"
>       uri="yyy" />
>    ...
> </element>
>
> The element's localName and qualifiedName would be
> used only for top level bean, i.e. if this bean has a
> property which is not primitive, then the name of this
> property would be specified as attribute.
>
> The XMLIntrospector would first get standard BeanInfo
> class and then would look for acme.CustomerBean.xml.
> The settings in xml will overwrite the names that
> would be normally generated by XMLIntrospector. All
> non-specified names will be generated as today.
>
> Today, whether the bean primitive properties are
> rendered as attributes or elements is specified on the
> XMLIntrospector level. Now we could do this in
> CustomerBean.xml file - i.e. have "element" child
> elements on the same level as "attribute" element.
>
> I'm brainstorming here as I still don't get the
> complete picture of betwixt :-).

You're spot on. This is exactly what I wanted to happen - I'm in the middle
of trying to put it together. I've a little bit of hacking to do but I'm
close to having something like this working.


> Now a few questions:
> 1. My understanding is that Expression is there to
> support "lazy" getter method (called when bean->XML
> happens) is that correct?

Yes. Though for some objects the mapping from bean -> XML can be a bit wierd
(like Map.entrySet().iterator() for example) or calling indexed properties,
mapped properties and the like. So the idea behind the Expression hierarchy
was that any kind of expression could be called to map to XML.

> 2. What is Context purpose?

Right now its more of a marker class in case more stuff is needed. e.g. it
might contain a set of all beans written so far (rather like Serialization
does) to avoid duplicating the same bean twice in an XML stream. Right now
it has the possibility of registering variables which could be used in the
serialisation to XML - not sure how useful they would be but its another
possible Expression.

> 3. Is Updater a kind of "lazy" setter (called when
> XML->bean happens)?

Yes. It was added as an experiment to see if the bean <-> XML mapping
information (XMLBeanInfo) could be used effectively in a bidirectional
manner, so that it could (say) autopopulate a Digester. I've a feeling that
a few more tweeks might be required to the current betwixt code base to
truly do that well, but I think it should be possible - at least for common
use cases.

There's a BeanReader that is-a Digester that tries to default some Digester
rules - right now the code doesn't manage to default terribly many useful
rules - but hopefully with some more work it might help minimise the amount
of digester rules that are required. Because BeanReader is-a Digester you
can always add other rules that don't get auto-generated.

James

>
> Regards,
> Slawek
>
>
> --- robert burrell donkin <robertdonkin@mac.com>
> wrote:
> >
> > On Tuesday, January 29, 2002, at 09:40 PM, Slawek
> > Zachcial wrote:
> >
> > > Hi,
> > >
> > > Can you list some betwixt points to be done? Maybe
> > I
> > > could help? ;-)
> >
> > hi
> >
> > any help would be greatly appreciated :)
> >
> > the best candidate for a nice independent task would
> > be to add the
> > XMLBeanInfo extension mechansim. here's a paragraph
> > i've pulled from one
> > of james's posts:
> >
> > "I've been meaning to put an extension mechanism
> > into XMLIntrospector that
> > works like the extension mechanism in
> > java.beans.Instropector. e.g. given
> > a
> > FooBean class it would look on the classpath for a
> > FooBeanXMLBeanInfo class
> > using the same Java beans mechanism."
> >
> > if you're not familiar with BeanInfo's then you'll
> > need to look up the
> > java beans specs. the idea is that programmers would
> > be able to create
> > XMLBeanInfo classes which allow the bean->xml
> > mapping to be customized in
> > the same way that standard bean introspection can
> > be.
> >
> > if you fancy giving this a go then please get back
> > and i'll try to give
> > you whatever help i can.
> >
> > - robert
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Send FREE Valentine eCards with Yahoo! Greetings!
> http://greetings.yahoo.com
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message