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?
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 :-).
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?
2. What is Context purpose?
3. Is Updater a kind of "lazy" setter (called when
XML->bean happens)?
Regards,
Slawek
--- robert burrell donkin <[EMAIL PROTECTED]>
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:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
