You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Slawek Zachcial <sl...@yahoo.com> on 2002/02/06 09:21:05 UTC
Re: (Betwixt) a task for a volunteer [Was Re: digester data to XML]
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 <ro...@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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: (Betwixt) a task for a volunteer [Was Re: digester data toXML]
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Jason van Zyl" <jv...@zenplex.com>
> On 2/6/02 2:25 PM, "James Strachan" <ja...@yahoo.co.uk> wrote:
>
>
> >
> > 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.
>
> You might also want to look at this:
>
>
http://cvs.apache.org/viewcvs/jakarta-turbine-stratum/src/java/org/apache/st
> ratum/xo/Mapper.java?rev=1.13&content-type=text/vnd.viewcvs-markup
>
> It automatically maps a 'common' XML bean format into a specified object.
> The object can be created, or a live bean can be used. We're using this
> successfully in turbine for a number of mappers and we don't have to
specify
> any rules provided the XML adheres to a simple format.
>
> I was going to take a crack at modifying some of the betwixt code to get
the
> bidirectional behaviour working as I will need this in Tambora very
shortly.
> The mapper users dom4j to parse the XML.
>
> All the code is stratum will eventually all be put in the commons so the
> mapper will hopefully land in the commons in much the same fashion as the
> struts utilities have landed in the commons.
Thanks Jason - I'll take a look.
James
>
> > James
> >
> >>
> >> Regards,
> >> Slawek
> >>
> >>
> >> --- robert burrell donkin <ro...@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:
> >>> <ma...@jakarta.apache.org>
> >>> For additional commands, e-mail:
> >>> <ma...@jakarta.apache.org>
> >>>
> >>
> >>
> >> __________________________________________________
> >> Do You Yahoo!?
> >> Send FREE Valentine eCards with Yahoo! Greetings!
> >> http://greetings.yahoo.com
> >>
> >> --
> >> To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> >> For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: (Betwixt) a task for a volunteer [Was Re: digester data to
XML]
Posted by Jason van Zyl <jv...@zenplex.com>.
On 2/6/02 2:25 PM, "James Strachan" <ja...@yahoo.co.uk> wrote:
>
> 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.
You might also want to look at this:
http://cvs.apache.org/viewcvs/jakarta-turbine-stratum/src/java/org/apache/st
ratum/xo/Mapper.java?rev=1.13&content-type=text/vnd.viewcvs-markup
It automatically maps a 'common' XML bean format into a specified object.
The object can be created, or a live bean can be used. We're using this
successfully in turbine for a number of mappers and we don't have to specify
any rules provided the XML adheres to a simple format.
I was going to take a crack at modifying some of the betwixt code to get the
bidirectional behaviour working as I will need this in Tambora very shortly.
The mapper users dom4j to parse the XML.
All the code is stratum will eventually all be put in the commons so the
mapper will hopefully land in the commons in much the same fashion as the
struts utilities have landed in the commons.
> James
>
>>
>> Regards,
>> Slawek
>>
>>
>> --- robert burrell donkin <ro...@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:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Send FREE Valentine eCards with Yahoo! Greetings!
>> http://greetings.yahoo.com
>>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: (Betwixt) a task for a volunteer [Was Re: digester data to XML]
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Slawek
----- Original Message -----
From: "Slawek Zachcial" <sl...@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 <ro...@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:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Send FREE Valentine eCards with Yahoo! Greetings!
> http://greetings.yahoo.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Cache in Sandbox [PATCH] fix for deprecated JUnit asserts
Posted by Tim O'Brien <to...@discursive.com>.
I attached a simple patch to be applied to jakarta-commons-sandbox/cache
module. It replaces all deprecated JUnit calls to assert(boolean) and
assert(String,boolean) with assertTrue(boolean) and assertTrue(String,
boolean).
Tim O'Brien
tobrien@discursive.com
(847) 863-7045
Re: (Betwixt) a task for a volunteer [Was Re: digester data to XML]
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Slawek Zachcial" <sl...@yahoo.com>
> The problem I see with the XMLBeanInfo being a class
> for a bean (FooBean --> FooBeanXMLBeanInfo) is that
> it's very static. You may want to map the bean in
> several different ways - depending on your
> application.
> The XML should do this job :-)
Good point. Maybe just the xml format is all thats required to customize the
'XMLBeanInfo'
> Also, I think that XMLIntrospector should have the
> same lookup mechanism as JavaBeans Introspector - look
> at Introspector.get/setBeanInfoSearchPath. Like this
> you can provide a default XMLBeanInfo and when
> deploying your bean customize it by putting the new
> XMLBeanInfo at the path preceding the default one.
Agreed.
James
>
> cheers,
> Slawek
>
> --- robert burrell donkin <ro...@mac.com>
> wrote:
> >
> > On Wednesday, February 6, 2002, at 08:21 AM, Slawek
> > Zachcial wrote:
> >
> > > Hi Robert,
> > >
> > > I'm still digesting the betwixt code :-).
> >
> > so am i :)
> >
> > i'll give you what help i can and hopefully if james
> > is around later he'll
> > be able to give you definitive answers.
> >
> > > 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?
> >
> > <snip>
> >
> > > Is my understanding correct?
> >
> > yes
> >
> > >
> > > 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.
> >
> > that sounds a lot to me like you're volunteering to
> > solve another item on
> > the betwixt to do list - being able to use xml to
> > describe the mapping :)
> >
> > i think that james said that he was planning to take
> > a look into this next.
> > don't let this stop you thinking about it - your
> > ideas sound pretty good
> > to me. hopefully james'll be around a bit later so
> > you can talk about them
> > and come up with a plan so you don't step on each
> > other's fingers.
> >
> >
> > the XMLBeanInfo item is actually quite a lot easier.
> > the idea is that
> > people can create XMLBeanInfo classes which are
> > similar to BeanInfo
> > implementations. (the way that BeanInfo
> > implementations - roughly - work
> > is that the java bean introspector looks for a class
> > called FooBeanInfo
> > when asked to introspect bean Foo - if it exists
> > then that implementation
> > is used, otherwise Foo will be introspected.)
> >
> > so, you need to change the XMLIntrospector so that
> > it looks for a
> > corresponding XMLBeanInfo class in the same package
> > as the given bean. if
> > it finds such a class then it should create an
> > instance. otherwise it
> > introspects in the way that it does now.
> >
> > for example, if XMLIntrospector is introspecting an
> > instance of
> > org.example.FooBean, then it looks to see if there's
> > a
> > org.example.XMLBeanInfoFooBean class (this class
> > should extend XMLBeanInfo)
> > . if it finds that such a class exists, it creates
> > an instance and uses
> > that. otherwise, it introspects as it does at the
> > moment.
> >
> > if you still fancy giving it a go, i'd be cool if
> > you could create a unit
> > test (the tests are under the src/text directory).
> >
> > - robert
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Send FREE Valentine eCards with Yahoo! Greetings!
> http://greetings.yahoo.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: (Betwixt) a task for a volunteer [Was Re: digester data to XML]
Posted by robert burrell donkin <ro...@mac.com>.
hi Slawek
i think that you need to talk to James Strachan. i don't really have a
deep understand of the betwixt design or james's future plans for betwixt.
he's the master - i'm just lending a hand where i can :)
- robert
On Wednesday, February 6, 2002, at 08:47 PM, Slawek Zachcial wrote:
> The problem I see with the XMLBeanInfo being a class
> for a bean (FooBean --> FooBeanXMLBeanInfo) is that
> it's very static. You may want to map the bean in
> several different ways - depending on your
> application.
> The XML should do this job :-)
>
> Also, I think that XMLIntrospector should have the
> same lookup mechanism as JavaBeans Introspector - look
> at Introspector.get/setBeanInfoSearchPath. Like this
> you can provide a default XMLBeanInfo and when
> deploying your bean customize it by putting the new
> XMLBeanInfo at the path preceding the default one.
>
> cheers,
> Slawek
>
> --- robert burrell donkin <ro...@mac.com>
> wrote:
>>
>> On Wednesday, February 6, 2002, at 08:21 AM, Slawek
>> Zachcial wrote:
>>
>>> Hi Robert,
>>>
>>> I'm still digesting the betwixt code :-).
>>
>> so am i :)
>>
>> i'll give you what help i can and hopefully if james
>> is around later he'll
>> be able to give you definitive answers.
>>
>>> 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?
>>
>> <snip>
>>
>>> Is my understanding correct?
>>
>> yes
>>
>>>
>>> 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.
>>
>> that sounds a lot to me like you're volunteering to
>> solve another item on
>> the betwixt to do list - being able to use xml to
>> describe the mapping :)
>>
>> i think that james said that he was planning to take
>> a look into this next.
>> don't let this stop you thinking about it - your
>> ideas sound pretty good
>> to me. hopefully james'll be around a bit later so
>> you can talk about them
>> and come up with a plan so you don't step on each
>> other's fingers.
>>
>>
>> the XMLBeanInfo item is actually quite a lot easier.
>> the idea is that
>> people can create XMLBeanInfo classes which are
>> similar to BeanInfo
>> implementations. (the way that BeanInfo
>> implementations - roughly - work
>> is that the java bean introspector looks for a class
>> called FooBeanInfo
>> when asked to introspect bean Foo - if it exists
>> then that implementation
>> is used, otherwise Foo will be introspected.)
>>
>> so, you need to change the XMLIntrospector so that
>> it looks for a
>> corresponding XMLBeanInfo class in the same package
>> as the given bean. if
>> it finds such a class then it should create an
>> instance. otherwise it
>> introspects in the way that it does now.
>>
>> for example, if XMLIntrospector is introspecting an
>> instance of
>> org.example.FooBean, then it looks to see if there's
>> a
>> org.example.XMLBeanInfoFooBean class (this class
>> should extend XMLBeanInfo)
>> . if it finds that such a class exists, it creates
>> an instance and uses
>> that. otherwise, it introspects as it does at the
>> moment.
>>
>> if you still fancy giving it a go, i'd be cool if
>> you could create a unit
>> test (the tests are under the src/text directory).
>>
>> - robert
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@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>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: (Betwixt) a task for a volunteer [Was Re: digester data to XML]
Posted by Slawek Zachcial <sl...@yahoo.com>.
The problem I see with the XMLBeanInfo being a class
for a bean (FooBean --> FooBeanXMLBeanInfo) is that
it's very static. You may want to map the bean in
several different ways - depending on your
application.
The XML should do this job :-)
Also, I think that XMLIntrospector should have the
same lookup mechanism as JavaBeans Introspector - look
at Introspector.get/setBeanInfoSearchPath. Like this
you can provide a default XMLBeanInfo and when
deploying your bean customize it by putting the new
XMLBeanInfo at the path preceding the default one.
cheers,
Slawek
--- robert burrell donkin <ro...@mac.com>
wrote:
>
> On Wednesday, February 6, 2002, at 08:21 AM, Slawek
> Zachcial wrote:
>
> > Hi Robert,
> >
> > I'm still digesting the betwixt code :-).
>
> so am i :)
>
> i'll give you what help i can and hopefully if james
> is around later he'll
> be able to give you definitive answers.
>
> > 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?
>
> <snip>
>
> > Is my understanding correct?
>
> yes
>
> >
> > 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.
>
> that sounds a lot to me like you're volunteering to
> solve another item on
> the betwixt to do list - being able to use xml to
> describe the mapping :)
>
> i think that james said that he was planning to take
> a look into this next.
> don't let this stop you thinking about it - your
> ideas sound pretty good
> to me. hopefully james'll be around a bit later so
> you can talk about them
> and come up with a plan so you don't step on each
> other's fingers.
>
>
> the XMLBeanInfo item is actually quite a lot easier.
> the idea is that
> people can create XMLBeanInfo classes which are
> similar to BeanInfo
> implementations. (the way that BeanInfo
> implementations - roughly - work
> is that the java bean introspector looks for a class
> called FooBeanInfo
> when asked to introspect bean Foo - if it exists
> then that implementation
> is used, otherwise Foo will be introspected.)
>
> so, you need to change the XMLIntrospector so that
> it looks for a
> corresponding XMLBeanInfo class in the same package
> as the given bean. if
> it finds such a class then it should create an
> instance. otherwise it
> introspects in the way that it does now.
>
> for example, if XMLIntrospector is introspecting an
> instance of
> org.example.FooBean, then it looks to see if there's
> a
> org.example.XMLBeanInfoFooBean class (this class
> should extend XMLBeanInfo)
> . if it finds that such a class exists, it creates
> an instance and uses
> that. otherwise, it introspects as it does at the
> moment.
>
> if you still fancy giving it a go, i'd be cool if
> you could create a unit
> test (the tests are under the src/text directory).
>
> - robert
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: (Betwixt) a task for a volunteer [Was Re: digester data to XML]
Posted by robert burrell donkin <ro...@mac.com>.
On Wednesday, February 6, 2002, at 08:21 AM, Slawek Zachcial wrote:
> Hi Robert,
>
> I'm still digesting the betwixt code :-).
so am i :)
i'll give you what help i can and hopefully if james is around later he'll
be able to give you definitive answers.
> 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?
<snip>
> Is my understanding correct?
yes
>
> 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.
that sounds a lot to me like you're volunteering to solve another item on
the betwixt to do list - being able to use xml to describe the mapping :)
i think that james said that he was planning to take a look into this next.
don't let this stop you thinking about it - your ideas sound pretty good
to me. hopefully james'll be around a bit later so you can talk about them
and come up with a plan so you don't step on each other's fingers.
the XMLBeanInfo item is actually quite a lot easier. the idea is that
people can create XMLBeanInfo classes which are similar to BeanInfo
implementations. (the way that BeanInfo implementations - roughly - work
is that the java bean introspector looks for a class called FooBeanInfo
when asked to introspect bean Foo - if it exists then that implementation
is used, otherwise Foo will be introspected.)
so, you need to change the XMLIntrospector so that it looks for a
corresponding XMLBeanInfo class in the same package as the given bean. if
it finds such a class then it should create an instance. otherwise it
introspects in the way that it does now.
for example, if XMLIntrospector is introspecting an instance of
org.example.FooBean, then it looks to see if there's a
org.example.XMLBeanInfoFooBean class (this class should extend XMLBeanInfo)
. if it finds that such a class exists, it creates an instance and uses
that. otherwise, it introspects as it does at the moment.
if you still fancy giving it a go, i'd be cool if you could create a unit
test (the tests are under the src/text directory).
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>