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 <[EMAIL PROTECTED]> 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:[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]>
