Re: [rules-dev] Handling Dynamic Input Data Behaviour
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).