JESS: Changing the value of Defglobal variables

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

JESS: Changing the value of Defglobal variables

Richard, Kevin R.
Changing the value of Defglobal variables

I'm planning on using a defglobal variable to reflect the state of a checkbox in the UI for my application.  The value of this variable, therefore will be set and modified in Java.  Looking at the Jess API, I don't see any means of changing the value of a Defglobal object once it has been set.  The value of this variable will influence many of the rules that I'll be running.  Am I missing something in the interface and is this the proper way to handle this type of construct?  I've searched the jess-users archive list and haven't seen this issue posted.

- Kevin

Kevin Richard
Northrop Grumman IT
Defense Enterprise Solutions
55 Walkers Brook Drive
Reading, Ma 01867
781.205.7748

Reply | Threaded
Open this post in threaded view
|

Re: JESS: Changing the value of Defglobal variables

friedman_hill ernest j
I think Richard, Kevin R. wrote:
> I'm planning on using a defglobal variable to reflect the state of a
> checkbox in the UI for my application.  The value of this variable,
> therefore will be set and modified in Java.  Looking at the Jess API, I
> don't see any means of changing the value of a Defglobal object once it
> has been set.  The value of this variable will influence many of the
> rules that I'll be running.  Am I missing something in the interface and
> is this the proper way to handle this type of construct?  

To set the value of a defglobal ?*g* to 1 from Java, you can say

  Rete engine = ...;
  engine.getGlobalContext().setVariable("*g*", new Value(1, RU.INTEGER));

But note that your proposed architecture probably won't work the way
you expect. From the manual:

  "If you match to a defglobal with a pattern like (foo ?*x*), the
  match will only consider the value of the defglobal when the fact is
  asserted. Subsequent changes to the defglobal's value will not
  invalidate the match - i.e., the match does not reflect the current
  value of the defglobal, but only the value at the time the matching
  fact was asserted.

Therefore, what you probably want to do instead is have a fact that
represents the state of the checkbox. Assert it from Java and store a
reference to the jess.Fact object someplace, then use Rete.modify() to
change it as needed in the event handler for the checkbox.



---------------------------------------------------------
Ernest Friedman-Hill  
Advanced Software Research          Phone: (925) 294-2154
Sandia National Labs                FAX:   (925) 294-2234
PO Box 969, MS 9012                 [hidden email]
Livermore, CA 94550         http://herzberg.ca.sandia.gov

--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [hidden email]'
in the BODY of a message to [hidden email], NOT to the list
(use your own address!) List problems? Notify [hidden email].
--------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: JESS: Changing the value of Defglobal variables

kahunamoore
In reply to this post by Richard, Kevin R.
Richard, Kevin R. wrote:
> I'm planning on using a defglobal variable to reflect the state of a
> checkbox in the UI for my application.  The value of this variable,
> therefore will be set and modified in Java.  Looking at the Jess API, I
> don't see any means of changing the value of a Defglobal object once it
> has been set.  The value of this variable will influence many of the
> rules that I'll be running.

You do not want to use a defglobal for this. You have several options,
including:

a) Make your object a standard Java Bean(1), call definstance() on your
Rete object passing it the bean instance(s), and have your Swing/Java
code update the bean to reflect the state of your UI.

Your rules can then directly pattern match against the bean's
properties. When those properties change (via PropertyChangeEvents), the
Rete object will automagically evaluate your rules to reflect the new
state of your UI.

b) Create your UI objects using Java and/or Jess code and then implement
the Swing/AWT callback methods directly using Jess deffunctions to trap
UI based events. In these deffunction handlers, you can update the Rete
with facts or other objects as needed. Again, your rules can react the
the changes made by the deffunctions.

To do this easily see the recently added (implement) function ;-D

In either of these cases, you will need to consider which thread your
rules will be firing on. IMHO, you should have a dedicated thread call
Rete#runUntilHalt() so that all you rule firings will be done on a
single thread and your UI/handler code won't be stuck spending time
firing rules instead of responding to the user.

There are a number of other usage patterns you could consider but these
are fairly typical and well documented in the manual and elsewhere.


alan

(1) Primarily, implement getters/setters + PropertyChangeEvents. See the
Jess manual and the book Jess In Action for more details and potential
hazards.

--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [hidden email]'
in the BODY of a message to [hidden email], NOT to the list
(use your own address!) List problems? Notify [hidden email].
--------------------------------------------------------------------