On Sunday, November 17, 2002, at 09:36 PM, Stephen Colebourne wrote:

From: "robert burrell donkin" <[EMAIL PROTECTED]>
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?
I've lost track of the original request, but...
[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?
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] ;)

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

Reply via email to