You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mika Goeckel <mi...@gmx.de> on 2001/12/13 16:51:15 UTC
selfconfiguring objects patch for digester
Hi,
please find attached my changes to Digester, ObjectCreateRule and ObjectCreationFactory + two new interfaces (source in the jar).
I think my docu is not that good -- English is not my mother tongue.
Some example is in the documentation of SelfConfigureObject.
Looking forward to your comments.
Mika
Re: selfconfiguring objects patch for digester
Posted by robert burrell donkin <ro...@mac.com>.
On Thursday, December 13, 2001, at 06:23 PM, Mika Goeckel wrote:
> Hi Robert,
hi mika
> take your time.
i'm not a committer for digester, so i don't get a veto.
i was just telling people that i might have some opinions on this.
> The reason for me to change the basic rules is, that it is transparent to
> existing code. You will see that instantly when you look at the code.
yes i understand that.
i get nervous about changing to the basic rules (especially when i make
the patches ;)
i want to figure out exactly what effects these changes would have.
in principle, i would prefer additional rules and subclasses so that
there's less chance of breaking existing code. (that's why
ExtendedBaseRules is a subclass extending the standard pattern matching
behaviour.)
> On knowledge about rulesets: The object get's the digester instance so it
> has full access to the rules that already are in place. In addition to
> what
> I sent, it may be sensible to provide the attributes as well, to enable
> attribute specific configuration.
i meant the pattern matching rules.
the self-configuring object might add an additional rule with a pattern
("*/xxx") which is not understood by the current pattern matcher. of
course, the object could throw some kind of runtime exception. if i was
using somebody else's code that configured itself then i might not be able
to write the mapping ruleset that i need because of the self configuration
behaviour of the object.
still, adding a property that switches the self-configuration on and off
for the rule should prevent that happening.
> On debugging. Yes, it looks like it complicates, but on the other hand it
> enables better structuring by encapsulation, because you can keep the tag
> specific configuration in the regarding object itself.
having spend long periods trying to debug pattern matching rules and large
rulesets, debugging is an important issue. on the other hand, so long as
the writer of the ruleset could turn off self configuration for an
existing object, the onus would be on the coder of the object to get the
rules right when creating an extension object for a existing mapping.
> I thought about limiting the rules to tags nested inside the tag that
> caused
> the configuration method to be called, but that is much more complicated.
i think that simplicity is important. i don't see why - except security -
that you'd need to limit the scope of the rules. if the mapping is being
developed against an existing set of rules, then it's up to the developer
of the mapping to cope with these problems. otherwise, the developer of a
new mapping should be able to switch off the behaviour if it's causing
problems.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: selfconfiguring objects patch for digester
Posted by Mika Goeckel <mi...@gmx.de>.
Rob,
yes, foolish.... the second interface is not necessary. I review my code and
simplify it....
M.
----- Original Message -----
From: "robert burrell donkin" <ro...@mac.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, December 13, 2001 9:37 PM
Subject: Re: selfconfiguring objects patch for digester
> On Thursday, December 13, 2001, at 06:23 PM, Mika Goeckel wrote:
>
> > Hi Robert,
> >
> > take your time.
> >
> > The reason for me to change the basic rules is, that it is transparent
to
> > existing code. You will see that instantly when you look at the code.
>
> i'm a bit confused about why you need another interface as well as Rule.
> isn't it better to keep Rule and use the digester instance to to find the
> information you want to pass into the Self Configuration? or even better,
> why doesn't the self configuring object look up the information it needs
> >from the digester instance?
>
> - robert
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: selfconfiguring objects patch for digester
Posted by robert burrell donkin <ro...@mac.com>.
On Thursday, December 13, 2001, at 06:23 PM, Mika Goeckel wrote:
> Hi Robert,
>
> take your time.
>
> The reason for me to change the basic rules is, that it is transparent to
> existing code. You will see that instantly when you look at the code.
i'm a bit confused about why you need another interface as well as Rule.
isn't it better to keep Rule and use the digester instance to to find the
information you want to pass into the Self Configuration? or even better,
why doesn't the self configuring object look up the information it needs
from the digester instance?
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: selfconfiguring objects patch for digester
Posted by Mika Goeckel <mi...@gmx.de>.
Hi Robert,
take your time.
The reason for me to change the basic rules is, that it is transparent to
existing code. You will see that instantly when you look at the code.
On knowledge about rulesets: The object get's the digester instance so it
has full access to the rules that already are in place. In addition to what
I sent, it may be sensible to provide the attributes as well, to enable
attribute specific configuration.
On debugging. Yes, it looks like it complicates, but on the other hand it
enables better structuring by encapsulation, because you can keep the tag
specific configuration in the regarding object itself.
I thought about limiting the rules to tags nested inside the tag that caused
the configuration method to be called, but that is much more complicated.
Mika
----- Original Message -----
From: "robert burrell donkin" <ro...@mac.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, December 13, 2001 7:07 PM
Subject: Re: selfconfiguring objects patch for digester
i haven't had a look at this patch in detail but i'd like the chance to
take a decent look and have a little think about it before it's committed.
FWIW, my gut instinct is that modifying basic rules is the wrong way to
implement this feature and there has to be a better way.
a self configuring object would have to know about the matching ruleset in
order to create the appropriate matching patterns. the pattern matching
rules we have at the moment are fairly compatible but there has been
demand for pattern matching rules using incompatible patterns (eg. XPath).
the other possible wrinkle is that large rulesets are difficult enough to
debug as it is - but by allowing self-configuring object to dynamically
change the rules, debugging these rulesets could become nearly impossible.
- robert
On Thursday, December 13, 2001, at 03:51 PM, Mika Goeckel wrote:
> Hi,
>
> please find attached my changes to Digester, ObjectCreateRule and
> ObjectCreationFactory + two new interfaces (source in the jar).
> I think my docu is not that good -- English is not my mother tongue.
>
> Some example is in the documentation of SelfConfigureObject.
>
> Looking forward to your comments.
>
> Mika
> --
> 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:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: selfconfiguring objects patch for digester
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 13 Dec 2001, robert burrell donkin wrote:
> Date: Thu, 13 Dec 2001 18:07:44 +0000
> From: robert burrell donkin <ro...@mac.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: selfconfiguring objects patch for digester
>
> i haven't had a look at this patch in detail but i'd like the chance to
> take a decent look and have a little think about it before it's committed.
>
A completely different approach to this (which I unfortunately thought of
after Mika started down this path) is to use the namespace support in the
current version of Digester. This would avoid the "pattern clash" problem
that I raised in my initial response.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: selfconfiguring objects patch for digester
Posted by robert burrell donkin <ro...@mac.com>.
i haven't had a look at this patch in detail but i'd like the chance to
take a decent look and have a little think about it before it's committed.
FWIW, my gut instinct is that modifying basic rules is the wrong way to
implement this feature and there has to be a better way.
a self configuring object would have to know about the matching ruleset in
order to create the appropriate matching patterns. the pattern matching
rules we have at the moment are fairly compatible but there has been
demand for pattern matching rules using incompatible patterns (eg. XPath).
the other possible wrinkle is that large rulesets are difficult enough to
debug as it is - but by allowing self-configuring object to dynamically
change the rules, debugging these rulesets could become nearly impossible.
- robert
On Thursday, December 13, 2001, at 03:51 PM, Mika Goeckel wrote:
> Hi,
>
> please find attached my changes to Digester, ObjectCreateRule and
> ObjectCreationFactory + two new interfaces (source in the jar).
> I think my docu is not that good -- English is not my mother tongue.
>
> Some example is in the documentation of SelfConfigureObject.
>
> Looking forward to your comments.
>
> Mika
> --
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>