[rules-dev] Handling Dynamic Input Data Behaviour

[Arjun Dhar]

Mark Proctor <mproctor <at> codehaus.org> writes:

> 
> 
> 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.

Anirvan, 'If you are destperate', here is the work around code (Be careful what 
you wish for, you were warned not to use it from a 'best practice' stand point):

QUICK FIX:
===================
In your condition use:
eval(<object>.getHashMapProperty("<propertyName>")==$1)


Conway example?
================
Mark, as per your soultion. I had something else in mind, but I guess your 
saying something else. 

Does the solution you provide:
Allow a user, 'without any extra code' to extend object attributes to use 
within the rules???

Looking at the conway example I dont see a direct correlation in whats required 
here and the concept you illustrate. A neighbour may create a cross product but 
it does not allow me to define extended name attrubites to use directly in the 
script, which is what I feel the business need is. 

Concept
========
You mention, relational Vs composition(kinda)! Well, from a script expression 
point of view can you provide an example, how it would be convenient to use 
this? The conway example does not seem to address this business need clearly! 
In conway you create more neighbour objects (not attributes), a clear 
difference in concept.

I was thinking more on the lines of generating a dynamic extended object that 
supports 'soft' attributes. Using OBJENESIS and assert that! Once in WM then 
users can use that in their scripts. (Was observing how you create Shadows and 
extending the concept to allow business users to not use Eval and yet extend 
their beans).