i've committed a first cut at XMLBeanInfoRegistry (if anyone wants to take a look).
(sorry it's been so long.)
- robert
On Tuesday, November 19, 2002, at 10:55 AM, [EMAIL PROTECTED] wrote:
-----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 customizationOn Monday, November 18, 2002, at 08:41 PM, [EMAIL PROTECTED] wrote:<%--- snip ---%>For handling XMLBeanInfos i guess a pluggable mechanismcould be the rightway, since there are different opinions about how andwhere to storeXMLBeanInfos.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.Maybe you are right again, but I am still a little sceptic...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 wouldlike to see away to append new strategies without having to rewrite the code of XMLIntrospector or put the info into the XMLBeanInfoRegistry without takingcare of theXMLIntrospector.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.
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]. org> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]. org>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>