Digester XML rules and more complex pattern evaluation (XPath)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Digester XML rules and more complex pattern evaluation (XPath)

Richard Wood
Hello

A digester problem.
I'm trying to trigger different rules depending on the value of an
attribute.
Something like this

xml
<X type="a"/>
<X type="b"/>

xml rules
<pattern value="X@type='a'">
..do something
</pattern>
<pattern value="X@type='b'">
..do something else
</pattern>

The patterns are using XPath similar notation.

How can I extend the existing DigesterRuleParser so that I can add my own
"pattern matching" method?
I'm guessing I would have to write my own extension of RulesBase.
But how can I combine an instance of MyRulesBase with FromXMLRuleSet and
DigesterRuleParser?

Help would be much appreciated
Thanks
    Richard


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Digester XML rules and more complex pattern evaluation (XPath)

Simon Kitching
On Wed, 2005-08-10 at 08:23 +0200, Richard Wood wrote:

> Hello
>
> Didn't get any feedback in the user group. I'll try this one hoping that
> somebody might have an idea how to solve...
> A digester problem.
> I'm trying to trigger different rules depending on the value of an
> attribute.
> Something like this
>
> xml
> <X type="a"/>
> <X type="b"/>
>
> xml rules
> <pattern value="X@type='a'">
> ..do something
> </pattern>
> <pattern value="X@type='b'">
> ..do something else
> </pattern>
>
> The patterns are using XPath similar notation.
>
> How can I extend the existing DigesterRuleParser so that I can add my own
> "pattern matching" method?
> I'm guessing I would have to write my own extension of RulesBase.
> But how can I combine an instance of MyRulesBase with FromXMLRuleSet and
> DigesterRuleParser?
>
> Help would be much appreciated

Hi Richard,

I saw your email on the user list earlier but unfortunately didn't have
any time to write a decent reply.

I've redirected this email back to the user list as it is more
appropriate there.

I think the task of writing a RulesBase implementation that supports
xpath-like syntax would be very large. I suspect its not actually
possible without significantly changing the API between digester and the
RulesBase, as currently RulesBase objects aren't passed enough
information to match on anything but element names. Changing that API
would of course break backwards compatibility unless care is used.

I have been working on a digester 2.x design, and supporting xpath-like
matching is a goal for that, but there's a long way to go.

In the meantime, as long as you only have a few cases where you need to
match based on attributes, using custom rules or rule "filters" is more
feasable than implementing a custom RulesBase I think.

Here's one proposal along those lines, though I haven't analysed the
actual design:
  http://issues.apache.org/bugzilla/show_bug.cgi?id=31329

I think that writing a rule "decorator" might be reasonably easy and
effective:
  public class RuleAttributeFilter implements Rule {  
    public RuleFilter(Map attributes, Rule decoratedRule) {
    }

    private StackOfBooleans enabled = new StackOfBooleans();

    public void begin(....) {  
      // check the attributes, and push a true or false onto the enabled
      // stack depending on whether the rule is "enabled" or not.

      if (enabled)
        decoratedRule.begin(..);
    }

    public void body(...) {  
      if (enabled.peek()) decoratedRule.body(...);
    }

    public void end(..) {  
      if (enabled.peek()) decoratedRule.end(...)
      enabled.pop();
    }
  }
Note that this requires each conditional rule to be wrapped
individually.

All of the above has been discussed before on the commons-user list in
various forms, so I suggest searching the archives for past discussions.

Of course if you insist on using xmlrules (which I am not at all fond
of) then you'll need to go through extra steps to figure out how to make
that functionality available via xmlrules. This has also been discussed
on the commons-user list in the past, so you should find useful info on
this in the archives.

If you get something working, then please send an email with the details
(or create a wiki entry) as you're not the first to ask about this.

Cheers,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Digester XML rules and more complex pattern evaluation (XPath)

Richard Wood
Thanks for the insights Simon

I found a way to create an object depending on the values of attributes
without parsing the patterns after all.
Using an existing digester mechanism. factory create rules.

I had to create my own factory create rule extending from the original as I
needed to pass a context to the instantiated factory.
And it works fine.

My mistake was that I generalized too much. I only want to control the
instantiation. Not to define different rulesets for various patterns where
only the attribute value is different.

Regards
    Richard

----- Original Message -----
From: "Simon Kitching" <[hidden email]>
To: "Richard Wood" <[hidden email]>
Cc: <[hidden email]>
Sent: Thursday, August 11, 2005 10:53 AM
Subject: Re: Digester XML rules and more complex pattern evaluation (XPath)


> On Wed, 2005-08-10 at 08:23 +0200, Richard Wood wrote:
>> Hello
>>
>> Didn't get any feedback in the user group. I'll try this one hoping that
>> somebody might have an idea how to solve...
>> A digester problem.
>> I'm trying to trigger different rules depending on the value of an
>> attribute.
>> Something like this
>>
>> xml
>> <X type="a"/>
>> <X type="b"/>
>>
>> xml rules
>> <pattern value="X@type='a'">
>> ..do something
>> </pattern>
>> <pattern value="X@type='b'">
>> ..do something else
>> </pattern>
>>
>> The patterns are using XPath similar notation.
>>
>> How can I extend the existing DigesterRuleParser so that I can add my own
>> "pattern matching" method?
>> I'm guessing I would have to write my own extension of RulesBase.
>> But how can I combine an instance of MyRulesBase with FromXMLRuleSet and
>> DigesterRuleParser?
>>
>> Help would be much appreciated
>
> Hi Richard,
>
> I saw your email on the user list earlier but unfortunately didn't have
> any time to write a decent reply.
>
> I've redirected this email back to the user list as it is more
> appropriate there.
>
> I think the task of writing a RulesBase implementation that supports
> xpath-like syntax would be very large. I suspect its not actually
> possible without significantly changing the API between digester and the
> RulesBase, as currently RulesBase objects aren't passed enough
> information to match on anything but element names. Changing that API
> would of course break backwards compatibility unless care is used.
>
> I have been working on a digester 2.x design, and supporting xpath-like
> matching is a goal for that, but there's a long way to go.
>
> In the meantime, as long as you only have a few cases where you need to
> match based on attributes, using custom rules or rule "filters" is more
> feasable than implementing a custom RulesBase I think.
>
> Here's one proposal along those lines, though I haven't analysed the
> actual design:
>  http://issues.apache.org/bugzilla/show_bug.cgi?id=31329
>
> I think that writing a rule "decorator" might be reasonably easy and
> effective:
>  public class RuleAttributeFilter implements Rule {
>    public RuleFilter(Map attributes, Rule decoratedRule) {
>    }
>
>    private StackOfBooleans enabled = new StackOfBooleans();
>
>    public void begin(....) {
>      // check the attributes, and push a true or false onto the enabled
>      // stack depending on whether the rule is "enabled" or not.
>
>      if (enabled)
>        decoratedRule.begin(..);
>    }
>
>    public void body(...) {
>      if (enabled.peek()) decoratedRule.body(...);
>    }
>
>    public void end(..) {
>      if (enabled.peek()) decoratedRule.end(...)
>      enabled.pop();
>    }
>  }
> Note that this requires each conditional rule to be wrapped
> individually.
>
> All of the above has been discussed before on the commons-user list in
> various forms, so I suggest searching the archives for past discussions.
>
> Of course if you insist on using xmlrules (which I am not at all fond
> of) then you'll need to go through extra steps to figure out how to make
> that functionality available via xmlrules. This has also been discussed
> on the commons-user list in the past, so you should find useful info on
> this in the archives.
>
> If you get something working, then please send an email with the details
> (or create a wiki entry) as you're not the first to ask about this.
>
> Cheers,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]