> -----Ursprüngliche Nachricht----- > Von: robert burrell donkin > [mailto:[EMAIL PROTECTED]] > 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, > [EMAIL PROTECTED] 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:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
