On Friday, November 29, 2002, at 10:56 AM, Martin van den Bemt wrote:
The TestSchema you changed should be a cool example, I'll try to use the
beaninfosearchpath and register an xmlbeaninfo for component to see if
it works correctly (probably next week, Sorry about my "lack' of
interest lately, but I am in the process of trying to buy a (sailing)
boat and selling my house, so I can do what I want : sail around the
world :) (besides the big deadlines at work..)
that sounds very cool :)
good luck and a fair breeze!
- robert
Mvgr,
Martin
On Wed, 2002-11-27 at 23:25, robert burrell donkin wrote:
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, [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 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:commons-dev-
[EMAIL PROTECTED]
org>
For additional commands, e-mail: <mailto:commons-dev-
[EMAIL PROTECTED]
org>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED].
org>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED].
org>
--
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]>
