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
