commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Slawek Zachcial <slawek_zachc...@yahoo.com>
Subject Re: (Betwixt) a task for a volunteer [Was Re: digester data to XML]
Date Wed, 06 Feb 2002 20:47:02 GMT
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 <robertdonkin@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:  
> <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>


Mime
View raw message