[rules-dev] Handling Dynamic Input Data Behaviour

[Anirvan Majumdar]

Yeah,

I'd second that. Mark's approach actually had me all dazed right from the
second line. I need to use Drools to accomplish a rather simple task,
however the suggestions made by Mark had me all lost.

My requirement is that I have an input XML which my application should parse
and output another XML. The output XML will have tags and values capturing
the required business model. The structure of the input XML is something
like this:

    <parent name="aaaaaaa">
           <child value="sdfsdfsdf"/>
           <child value="sdfsdfsdf"/>
           <child value="sdfsdfsdf"/>
           <child value="sdfsdfsdf"/>
    </parent>

Now the transformation of this input XML has to be done condition to certain
rules which our client will provide us. I thought Drools would fit in very
well. However after reading and acquiring a basic understanding I came
across this particular limitation.

My problem arises since, the input bean's parent tag can have varying number
of child tags. As a consequence, I can't define a single Bean class to
capture this XML data. I can capture the data in a HashMap, but then I can't
access the key-value pairs from the "when" block of a rule.

Arjun, as you suggested,
- can you tell me whether I can really utilize DynaBeans to meet my ends in
this particular case?
- Can you also let me know a simple approach I can adopt?
- also, if eval can be used in this case, can you pass across an example to
show how to access say, the key-values from a HashMap set in the asserted
Bean object.

Amongst the other Rule Engines, I still think that Drools fits in best. A
little help perhaps?

Thanks a lot!
Anirvan




On 5/15/07, Arjun Dhar <dhar_ar at yahoo.com> wrote:
>
> Mark Proctor <mproctor <at> codehaus.org> writes:
>
> >
> >
> > You need to alter the parser and the Extractor api, you also need to be
> > able to deal with ShadowFacts, where we need to know the previous and
> > current value.Further to that nested value should not change without
> > notifying the parent fact in the network - i.e. correct network state
> > must always been maintained. It's a complex area, we are looking at a
> > work around that allows this declarative language, but rewrites it as
> > an eval - so you don't get the performance advantages - but it's a
> > quick work around for now.
> > Mark
>
> If what you want is the ability to extend the use of the class beyond what
> it
> was designed for (like a Dyna Bean, I think it is that!), then as a work
> around
> you could use 'eval' over your object methods also, but this practice is
> discouraged for a few reasons.
>
> The other more sophisticated approach is already given by Mark!
>
> regards,
> Arjun
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070515/57a97f25/attachment.html