commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [Betwixt] XMLBeanInfo customization
Date Wed, 27 Nov 2002 22:25:00 GMT
hi

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, h.dietrich@webfair.com wrote:

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


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