commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From h.dietr...@webfair.com
Subject AW: AW: [Betwixt] XMLBeanInfo customization
Date Tue, 19 Nov 2002 10:55:09 GMT


> -----Urspr√ľngliche Nachricht-----
> Von: robert burrell donkin 
> [mailto:robertburrelldonkin@blueyonder.co.uk]
> Gesendet: Montag, 18. November 2002 22:53
> An: Jakarta Commons Developers List
> Betreff: Re: AW: [Betwixt] XMLBeanInfo customization
> 
> 
> On Monday, November 18, 2002, at 08:41 PM, 
> h.dietrich@webfair.com wrote:
> 
> > <%--- snip ---%>
> 
> >>> For handling XMLBeanInfos i guess a pluggable mechanism
> >> could be the right
> >>> way, since there are different opinions about how and 
> where to store
> >>> XMLBeanInfos.
> >>
> >> IMHO these are solutions to different problems.
> >>
> >
> > How do you propose to handle different strategies for getting 
> > XMLBeanInfos,
> > like introspection, .betwixt files, FooBarXMLBeanInfo classes, etc.?
> 
> i'd need to hear what other people thing about some of the 
> priorities but 
> i think that the basic flow of the algorithm should be 
> straight forward.

I agree. Right now Betwixt is very easy to use and that is a great benefit
of this component.

> 
> XMLBeanInfoRegistry would simply act as a cache. if the required 
> XMLBeanInfo isn't in the cache, then XMLIntrospector would 
> create one. it 
> would first look for a custom mapping (either a .betwixt file 
> or a custom 
> class). if it couldn't find a custom mapping, then it would use 
> introspection to create a generic mapping. (this 
> introspection might be 
> pluggable later).
> 
> > Should all his reside inside the XMLIntrospector? I would 
> like to see a 
> > way to
> > append new strategies without having to rewrite the code of 
> > XMLIntrospector
> > or put the info into the XMLBeanInfoRegistry without taking 
> care of the
> > XMLIntrospector.
> 
> i think that you should able to do this by adding 
> XMLBeanInfo's into the 
> XMLBeanInfoRegistry programmatically before starting the 
> betwixt reading 
> or writing. if an XMLBeanInfo's is in the registry, then 
> there would be no 
> need for XMLIntrospector to create one.

Maybe you are right again, but I am still a little sceptic...
It seems to me, that for customization the program flow could get very ugly,
since I have to implement the registry functionality of XMLIntrospector
again. But maybe it could be a solution to create a child class of
XMLIntrospector, which provides the required functionality, and put this
into the reader/writer instead of using the standard XMLIntrospector.
I am still thinking of this, because XMLIntrospector already provides two
quite different funtions - bean introspection and reading bean info from a
.betwixt file...

>
> > Since a cache might be flushed the initially added infos
> > would be lost without chance to put them back in the registry.
> 
> the intention was to allow the cache to be flushed 
> programmatically by 
> users. (the current XMLIntrospection has this feature.)
> 
> but maybe it wouldn't be necessary. if it's pluggable, then 
> users would be 
> able to flush the cache by replacing the current instance 
> with another. of 
> course, if users really needed a flushable implementation, 
> then they'd be 
> free to create on of their own.

Here I agree again :)

> 
> - robert
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:commons-dev-help@jakarta.apache.org>
> 

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