I think Dusan Sormaz wrote: > > Is there any reason why fact is not updated automatically, if fact is > changed.
There are two kinds of definstances: static and dynamic. Jess has to treat them differently. For static ones (those without PropertyChangeEvent support,) the modify function changes both the fact and the object. For dynamic ones (ones which do support PropertyChangeListeners) modify changes only the object, and relies on the ensuing change event to change the fact. It would be redundant to change the fact too, because then the fact would be updated twice. In your case it looks like you're using dynamic definstances that don't send change events, which would be weird. Do they accept listeners, and then not send events, or do they send incorrect events? Note that if you register an object as a dynamic definstance, you'll get an error if the object doesn't support PropertyChangeListeners, so this particular scenario is a tough one to get yourself into. The only way it might happen is if the object accepts listeners and then doesn't send events, or sends events with, e.g., null property names but sends them before the object's properties are modified. > Using property change event I need to go and modify all setters to > include jess update, this would make it messy if java object is used > outside of jess. Not clear why you feel this way. The PropertyChangeListener mechanism isn't Jess-specific. Anyway, if you don't want to support them, then don't support them at all and use static definstances. You can always use explicit Rete.updateObject() calls if the object is modified external to Jess. > > > > > Another related question. If I use shadow facts, and then Assert them in > > > RHS of the rule, is corresponding java object created autoimatically? > > > >Nope, doesn't work that way. > > why not? this is completely opposite action from modify. If shadow fact is > modified only underlying object is changed, if it is asserted only fact is > asserted?? You can defclass an interface or an abstract class; and not all classes have default constructors. Therefore, it would be impossible for Jess to create an object automatically in many cases. Furthermore, "assert" doesn't know if the object should be definstanced as static or dynamic. Finally, the whole point of using definstanced objects as opposed to plain facts is often those connections the objects have to other objects outside of Jess; those connections couldn't be automatically set up. I agree that this would be a convenient feature in a limited set of cases, but because it can't be applied generally, it would just be more confusing to include it. --------------------------------------------------------- Ernest Friedman-Hill Science and Engineering PSEs Phone: (925) 294-2154 Sandia National Labs FAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://herzberg.ca.sandia.gov -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
