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]>
