On Thu, 13 Dec 2001, Mika Goeckel wrote:
> Date: Thu, 13 Dec 2001 00:35:58 +0100
> From: Mika Goeckel <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Self configuring Objects or is it possible to change the rule
> set during the parse phase?
>
> Hi!
>
> Is it possible to add rules to the ruleset of a digester after the
> parse has been started? The reason for that is, that it would enable
> us to put the knowledge about child objects within something like a
> configure() method of a just created object.
>
> For example if someone creates a complicated valve with subobjects in
> tomcat, the knowledge that a valve needs to be created is for example
> in org.apache.catalina.startup.ContextRuleset. Now if someone needs a
> Valve with subobjects configured via digester he/she has to change the
> ContextRuleset class.
>
It would be technically feasible to add new rules as you suggest.
However, I'm not sure it would really meet the goals you are after. In
your example, let's say that a particular Valve had a subobject named
"Foo". You could then conceivably add a new rule that matched the pattern
"Server/Service/Engine/Host/Context/Valve/Foo" -- but this would match a
"Foo" subelement on *any* Valve, not just the particular one you are
configuring. You'd need to be very careful about having unique subelement
names, or define your own Rules matcher that matched the above pattern
*only* if the className attribute of the Valve was the one you were
looking for.
> If it would be possible to call a configure method on the specific
> implementation of a class, it could itself add the rules for childs.
>
> A class could implement a ProvideRules interface defined in the
> digester package to let the digester know that it wants to provide
> additional rules.
>
> Comments please?
>
The approach I took in the Workflow project (in jakarta-commons-sandbox
right now) was to let the application configure all the RuleSet entries it
wanted before starting the parse in the first place. That seems to deal
with most of the use cases I've run into so far.
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
