On Mon, Apr 27, 2009 at 10:05 AM, Anna Södling anna.sodl...@passagen.se wrote:
Hi,
Is there anyone who has any idea what to do about this? Even a little
hint would be appreciated, you don't have to solve the whole problem!
snip/
Reply inline below.
/Linda
-Ursprungligt Meddelande-
From: Linda Erlenhov [u...@commons.apache.org]
Sent: 23/4/2009 2:30:58 PM
To: Commons Users List
Subject: Re: [SCXML] getting set datats in the datamodel
Hello again!
This seems to work, since we now can see that data has changed.
Unfortunately, we seem to have missed out an important part of the
question. In addition to being notified when a data value is set, we
also would like to be able to get/recieve the new data value aswell as
the
name (in this case numdat) so that we can display it to the screen in
our
interface.
And, in this example we only have one data value, NumDat. However, it
is possible to define several data values insade the DynamicData-tag.
Can we still just write assign name=DynamicData
expr=DynamicData/ after the first assign tag, or do we also have to
define what data value has been changed?
snap/
You will find that as more and more of the application-specific
patterns (and requirements) emerge, it is convenient to encapsulate
these patterns as custom actions (perhaps a time to rethink the no
custom action constraint).
Without that, you could always store the name (lets call it 'delta',
which signifies that it identifies the change) in the root context,
update it with every assign as needed and look it up for your
notifications, so along these lines (continuing example from earlier
in this thread):
scxml ...
datamodel
data name=delta /
/datamodel
state ...
onentry
!-- assignment below taken from example above --
assign location=Data(DynamicData,'NumDat')
expr=Data(DynamicData,'NumDat')+1/
!-- followed by assignment that triggers the set call with the
new value --
assign name=DynamicData expr=DynamicData/
!-- store the delta for use in notifications --
assign name=delta expr='NumDat'/
/onentry
...
/state
...
/scxml
and the Context#set() method previously discussed would then change
along these lines:
public void set(String name, Object value) {
// inherit behavior
super.set(name, value);
// notifications you need
// the second param is the new info needed
notify(name, get(delta), value);
}
Now, OTOH, all of this can really be distilled into a compact custom
action such as:
my:assign data=DynamicData location=NumDat
expr=Data(DynamicData,'NumDat')+1/
whose implementation encapsulates the pattern of updates and
notifications as needed by the application and thereby leaves the
markup cleaner.
-Rahul
Sincerely,
Linda
snip/
Yup, I see what you are running into. Unfortunately for the specific
usage pattern here, the two assign variations have different
semantics as follows:
1) assign name=... expr=.../
is a set operation, which produces a Context#set(...) call
2) assign location=... expr=.../
is really a mutation operation, it retrieves the XML data tree
(stored as a DOM node in memory) and manipulates it -- there is no
call to Context#set(...)
How do I notify when my DynamicData has changed?
snap/
ISTR that you prefer to not use custom actions. With those
constraints, one option (since you are generating all the SCXML) is to
accomodate for the above variation via the SCXML markup itself -- so
you could generate a redundant identity assignment to trigger the
Context#set(...) call like so:
!-- assignment below taken from example above --
assign location=Data(DynamicData,'NumDat')
expr=Data(DynamicData,'NumDat')+1/
!-- followed by assignment that triggers the set call with the new
value
--
assign name=DynamicData expr=DynamicData/
-Rahul
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
