[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