On Sunday, November 17, 2002, at 09:36 PM, Stephen Colebourne wrote:
probably so. unfortunately the amount of effort that i had intended to devote to the above solution is probably too little to make a difference to [clazz] ;)From: "robert burrell donkin" <[EMAIL PROTECTED]>I've lost track of the original request, but...On Saturday, November 16, 2002, at 02:08 PM, Martin van den Bemt wrote:since XMLBeanInfo's were supposed to correspond to java.beans.BeanInfo.
BeanInfo supports programmatic implementations. so if you had something
like xxx.yyy.zzz.FooBean then betwixt might look for a
xxx.yyy.zzz.FooBeanXMLBeanInfo class which would be a programmatic
XMLBeanInfo.
i don't know if adding this feature would help you or not.
This is already "kind of" supported, from a java.beans.Introspector perspective. Don't think it is an ellegant solution though that sun chose (with registring searchpaths)agreed :)i was thinking along the lines of allowing a custom programmatic XMLBeanInfo implementation but insisting that the package and name match exactly. so, for example, if you have a bean with full name xxx.yyy.FooBean, betwixt would try to discover a class called xxx.yyy.FooBarXMLBeanInfo. anyone have any improvements on this plan?
[clazz] is intended to provide a pluggable replacement to Introspector,
capable of pulling in data from XML files or specially coded classes.
Ideally I would like to see [betwixt] use [clazz] once complete, thus maybe
the effort should go into [clazz] as a broader solution?
a pluggable introspection solution would be cool.
what i was talking about (above) is a little different since really it'd be an alternative to .betwixt files for custom mappings. when you're using a custom mapping then betwixt only makes limited use of the introspector (if at all).
- robert
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>