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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
