[rules-users] Dynamic JavaBeans

[Mark Proctor]

feel free to work on a patch for us and let us know what you come up with.

Mark
Felipe Piccolini wrote:
> Mark,
>
>    What about my previous mail where I report an issue with update 
> using dynamic JavaBeans (using propertyListeners)?
>
> The problem is that when the engine is fired again from an 
> propertyListener the evaluations on conditions (seems to me)
> dont take the new state of the Facts changed in the set<Attribute> call.
>
> I will try using MVEL modify, but thats not the better solution, 
> because the feature of propertyListerners inside javaBeans let
> me write my rules in a cleaner way from BRMS/bussines editor.
>
> Thanks.
>
>
> On 28-06-2007, at 8:28, Mark Proctor wrote:
>
>> If it can be done cleanly I'm not averse to it. however there is 
>> something else...
>> In the new MVEL dialect you no longer need propertychangelisteners if 
>> you don't want to call update()
>>
>> modify ( cheese ) { price = 25, quality = premium }
>>
>> This will modify all the setters and notify the engine at the end of 
>> the block setter. Is that good enough for you?
>>
>> Mark
>> Yuri de Wit wrote:
>>> Mark,
>>>
>>> btw, If this is a feature that makes sense from Drools pov I wouldnt
>>> mind giving a shot at implementing it and contributing it back to
>>> Drools.
>>>
>>> -- yuri
>>>
>>> On 6/28/07, Yuri de Wit <ydewit at gmail.com <mailto:ydewit at gmail.com>> 
>>> wrote:
>>>> Sure. The solution I am taking right now is dont use dynamic
>>>> properties, which is not optimal (depending on the problem property
>>>> changes not being batched defeats the purpose of dynamic beans).
>>>>
>>>> The bottom line is that I was hoping that this feature would (1)
>>>> either already be taken care of in 4.0 or (2) become a feature request
>>>> for future releases.
>>>>
>>>> -- yuri
>>>>
>>>> On 6/28/07, Mark Proctor <mproctor at codehaus.org 
>>>> <mailto:mproctor at codehaus.org>> wrote:
>>>> > No we don't do anything to batch property change listener 
>>>> results. But
>>>> > maybe you can do this yourself.
>>>> > instead of calling modify, add it to a transaction list (that you 
>>>> make
>>>> > available in the current context). Then at the end of the consequence
>>>> > you can iterate that list and call modify on each object. Or
>>>> > alternatively don't use dynamic properties.
>>>> >
>>>> > Mark
>>>> > Yuri de Wit wrote:
>>>> > > I am not talking about assert, but modify. I have a dynamic fact
>>>> > > already asserted but now I need to perform N changes on N different
>>>> > > properties on the same object on the same consequence. Drools 
>>>> is going
>>>> > > to traverse the RETE network N times once for each time the
>>>> > > PropertiesListener is called (each setProperty called).
>>>> > >
>>>> > > -- yuri
>>>> > >
>>>> > > On 6/28/07, Mark Proctor <mproctor at codehaus.org 
>>>> <mailto:mproctor at codehaus.org>> wrote:
>>>> > >> Why would doing the assert work at the end of the consequence 
>>>> be any
>>>> > >> quicker than doing it during the consequence?
>>>> > >>
>>>> > >> Mark
>>>> > >> Yuri de Wit wrote:
>>>> > >> > I noticed that changes performed on facts asserted 
>>>> dynamically causes
>>>> > >> > the fact to be modified right away and therefore triggering 
>>>> a RETE
>>>> > >> > network traversal and rule schedulings.
>>>> > >> >
>>>> > >> > For apps with a large number of facts this could be a 
>>>> significant
>>>> > >> > scalability problem. At least in my case, I would like to be 
>>>> able to
>>>> > >> > use dynamic facts and perform any number of updates and have 
>>>> those
>>>> > >> > updates commited to working memory only when the rule 
>>>> consequence is
>>>> > >> > completed.
>>>> > >> >
>>>> > >> > Looking at the code, it seems that it would not be a major 
>>>> effort to
>>>> > >> > collect the facts received by the 
>>>> ReteooWorkingMemory.propertyChange
>>>> > >> > and perform the actual modifyObject() only when the consequence
>>>> > >> > evaluation is actually completed.
>>>> > >> >
>>>> > >> > Does that makes sense? Or are there side effects I am not 
>>>> seeing? Is
>>>> > >> > this a problem that 4.0 already resolves?
>>>> > >> >
>>>> > >> > thanks in advance,
>>>> > >> >
>>>> > >> > -- yuri
>>>> > >> > _______________________________________________
>>>> > >> > rules-users mailing list
>>>> > >> > rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>>> > >> > https://lists.jboss.org/mailman/listinfo/rules-users
>>>> > >> >
>>>> > >>
>>>> > >> _______________________________________________
>>>> > >> rules-users mailing list
>>>> > >> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>>> > >> https://lists.jboss.org/mailman/listinfo/rules-users
>>>> > >>
>>>> > > _______________________________________________
>>>> > > rules-users mailing list
>>>> > > rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>>> > > https://lists.jboss.org/mailman/listinfo/rules-users
>>>> > >
>>>> >
>>>> > _______________________________________________
>>>> > rules-users mailing list
>>>> > rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>>> >
>>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>                                                                         
> *Felipe Piccolini M.*
> felipe.piccolini at bluesoft.cl <mailto:felipe.piccolini at bluesoft.cl>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070628/0bd81bcb/attachment.html