Re: [rules-users] Dynamic JavaBeans

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(a)gmail.com&gt; 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(a)codehaus.org&gt; 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(a)codehaus.org&gt; 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(a)lists.jboss.org >>>> > >> > https://lists.jboss.org/mailman/listinfo/rules-users >>>> > >> > >>>> > >> >>>> > >> _______________________________________________ >>>> > >> rules-users mailing list >>>> > >> rules-users(a)lists.jboss.org >>>> > >> https://lists.jboss.org/mailman/listinfo/rules-users >>>> > >> >>>> > > _______________________________________________ >>>> > > rules-users mailing list >>>> > > rules-users(a)lists.jboss.org >>>> > > https://lists.jboss.org/mailman/listinfo/rules-users >>>> > > >>>> > >>>> > _______________________________________________ >>>> > rules-users mailing list >>>> > rules-users(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/rules-users >>>> > >>>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > Felipe Piccolini M. > felipe.piccolini(a)bluesoft.cl > > > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users