[rules-users] Dynamic JavaBeans

[Felipe Piccolini]

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> 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> 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> 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
>>> > >> > https://lists.jboss.org/mailman/listinfo/rules-users
>>> > >> >
>>> > >>
>>> > >> _______________________________________________
>>> > >> rules-users mailing list
>>> > >> rules-users at lists.jboss.org
>>> > >> https://lists.jboss.org/mailman/listinfo/rules-users
>>> > >>
>>> > > _______________________________________________
>>> > > rules-users mailing list
>>> > > rules-users at lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/rules-users
>>> > >
>>> >
>>> > _______________________________________________
>>> > rules-users mailing list
>>> > rules-users at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>> >
>>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users



Atentamente,
______________________
Felipe Piccolini Marfull
Jefe de Proyectos
Agustina 1141 Piso 8-B
Santiago

Fono    +(56 2) 68830837
E-mail felipe.piccolini at bluesoft.cl





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070628/b0b147d0/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic.tiff
Type: image/tiff
Size: 262986 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/rules-users/attachments/20070628/b0b147d0/attachment.tiff