[rules-dev] Handling Dynamic Input Data Behaviour
Mark Proctor
mproctor at codehaus.org
Tue May 15 13:55:59 EDT 2007
You can do this, set it up relationally, this is the "best practice"
way. This is what I told someone else:
Nested lists and hashmaps aren't good things for rules. Instead what you
should do is break them apart and use a relational object to drive this.
Take at look at the conways game of life example in MR2. There you'll
see I have a grid of Cell objects, in the old version each Cell had a
HashSet of neighbour Cells - this setup doesn't work too well with Rule
Engines. Instead now I have a Neighbour class that acts as a relation,
so I assert all my Cells and then I assert a Neighbour class for each
neighbour pair I create. This creates a cross product, which you can
explioit to drive your application. Basically think relationally, not
nested structures, it's exactly the same problem if you wanted to
represent this information in a database.
Mark
Anirvan Majumdar wrote:
> 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
> <mailto:dhar_ar at yahoo.com>> wrote:
>
> Mark Proctor <mproctor <at> codehaus.org <http://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 <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/0dd4ae26/attachment.html
More information about the rules-dev
mailing list