8:26 a.m.
Is there any way to circumvent the constraint that only getter methods can
be called from the asserted bean object? If the input data is dynamic in
nature and instead I capture it in a HashMap, then how can I retrieve
specific key-value pairs in the "when" block of a Rule?
Basically, I need to utilize a method, in the bean, which would have a
definition like:
<code>
public String getValue(String sKey){
return (String)hmpData.get(sKey);
}
</code>
Can this getValue method be accessed by the "when" block? If no, then can
someone let me know which class in the source I might have to tweak to
extract a similar behavior from the engine?
Thanks a lot!
Anirvan
8:45 a.m.
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
Anirvan Majumdar wrote:
Is there any way to circumvent the constraint that only getter methods
can be called from the asserted bean object? If the input data is
dynamic in nature and instead I capture it in a HashMap, then how can
I retrieve specific key-value pairs in the "when" block of a Rule?
Basically, I need to utilize a method, in the bean, which would have a
definition like:
<code>
public String getValue(String sKey){
return (String)hmpData.get(sKey);
}
</code>
Can this getValue method be accessed by the "when" block? If no, then
can someone let me know which class in the source I might have to
tweak to extract a similar behavior from the engine?
Thanks a lot!
Anirvan
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
11:42 a.m.
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
12:37 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
12:55 p.m.
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(a)yahoo.com
<mailto:dhar_ar@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(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
8:18 a.m.
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).
6971
days inactive
6973
days old
5 comments
3 participants
participants (3)
-
Anirvan Majumdar -
Arjun Dhar -
Mark Proctor