see comments below:
> -----Original Message-----
> From: Alessandro Saporiti
> [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 09, 2000 6:07 AM
> To: [EMAIL PROTECTED]
> Subject: JESS: Store and fetch objects
>
>
> Hi ,
> as you can argue I'm dealing with a problem about object handling.
> I want to pass objects from Java to Jess and viceversa. So I
> use store and
> fetch.
> Both store() and fetch() allow to handle one object at a time using a
> specific name for each object.
> The problem is that the number of object to be passed in and
> out (Java -
> Jess) is not fixed.
[alan]
You can create a "holder" HashMap or other collection and populate it with
your objects. Pass this into jess and you are on your way. I found the
easiest way to pass object to jess is to:
Userfunction fun = m_rete.findUserfunction("your-deffunction-name-here");
if ( fun == null )
{
return false;
}
// Create your arg values
Value arg1 = new Value( myArg1 );
Value arg2 = new Value( myArg2 );
// Create your "callstack"
ValueVector vv = new ValueVector();
vv.add( new Value( "your-deffunction-name-here" ) ); // see BTW below
vv.add( arg1 );
vv.add( arg2 );
// NOTE: you may want to create a collection to pass in as a single arg...
// call the deffunction
fun.call( vv, m_rete.getGlobalContext() );
BTW - I still don't know why the first callstack value (the deffunction
name) is required since we got this function from findUserfunction() - oh
well.
See the following references:
http://herzberg.ca.sandia.gov/jess/docs/api/jess/Rete.html#findUserfunction(
java.lang.String)
> So I can't determine the name every object refers to.
> Now I use one only name to store all the objects. But I can't
> do the same
> for fetching them, because the object returned (fetched) is
> always the last
> stored (of course: I use one only name for all !! ).
[alan]
I ran into a similar problem where I tried to definstance the *same* object
twice under *different* names. The upshot is that only *one* instance of an
object can used for *pattern matching* regardless of its alias (you can
however have many instances of object one or more facts as mentioned in the
discussion below.)
Note - be carefull because sometimes you may be given two object references
to the same object. This is the case with the Apache JServ - the
HttpServletRequest and HttpServletResponse passed into your service method
are actually just interfaces implemented by the same object (it is actually
a JServConnectionRequestResponseSomthingOrOther.)
See the manual for more information:
http://herzberg.ca.sandia.gov/jess/docs/functions.html#definstance
Also, for more info on why things are the way they are (ideas on how to
resolve these issues are welcome!!!):
*** from private email exchange with author ***
Hi Alan,
Thanks for figuring out what was going wrong. I gave this some
thought, as to whether Jess should allow things to be "doubly
definstanced" this way. I tought of a few minor difficulties and a few
serious performance indications for doing so.
One thing is the "undefinstance" command. Its syntax would have to
change: you'd have to say "(undefinstance ?x as TypeName)" or
something like that. This might be difficult for the user in some
cases; they might not be tracking which definstances are of which
defclass, so they'd need to keep a table of some kind.
Another is what happens when Jess gets a PropertyChangeEvent for a
definstanced object. Right now, it can simply look up the class in a
hashtable, retrieve the relevant fact, modify it, and reassert it. If
there could be multiple facts, Jess would need a more complex data
structure (this is trivial) but would need to make some difficult
choices. Since it couldn't know which defclass the Bean was modified
through, it would either have to sort through all of the facts looking
for changed slots (lots of messy, expensive code on every property
change) or it would have to simply change them all (which would cause
unexpected effects if the user doesn't know that two definstances
actually refer to the same object, as was the case here.)
In its current state, Jess does return an error for the second
definstance - you're showing the code below, and you can see the
<Fact--1> in the output (fact-ID minus 1). If this were a possiblity,
you could of course test for this return value in Jess code.
I think what I will do, rather than making any significant changes at
this late date, is simply to document that a given object can only be
definstanced once.
In the present case, I note in passing that one of the two defclasses
has no slots at all save for the OBJECT slot, and therefore there
really isn't any point in defclassing it anyway. If all you want are
facts referring to the objects, (assert (Response ?resp) (Request
?req)) (with no defclasses) would work fine; you couldn't match on the
slots, but I'm not sure you wanted to do that anyway.
Alan Moore wrote:
>
> Well, after debugging a regular console window version of jess, I found
the
> following code in ReflectFunctions.java (definstance.call):
>
> // Make sure we're not already matching on this object
> if (m_facts.get(o) != null)
> return new Value(-1, RU.FACT_ID);
>
> The return gets executed. Is it true that you can only have one instance
of
> a given object in the working store?
>
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
