Return-Path: Delivered-To: apmail-commons-user-archive@www.apache.org Received: (qmail 26790 invoked from network); 22 Apr 2009 17:02:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 22 Apr 2009 17:02:03 -0000 Received: (qmail 97087 invoked by uid 500); 22 Apr 2009 17:02:02 -0000 Delivered-To: apmail-commons-user-archive@commons.apache.org Received: (qmail 96979 invoked by uid 500); 22 Apr 2009 17:02:02 -0000 Mailing-List: contact user-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Users List" Delivered-To: mailing list user@commons.apache.org Received: (qmail 96965 invoked by uid 99); 22 Apr 2009 17:02:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Apr 2009 17:02:02 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rahul.akolkar@gmail.com designates 209.85.221.130 as permitted sender) Received: from [209.85.221.130] (HELO mail-qy0-f130.google.com) (209.85.221.130) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Apr 2009 17:01:55 +0000 Received: by qyk36 with SMTP id 36so158702qyk.10 for ; Wed, 22 Apr 2009 10:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ef0VvjUv2uCsQTWPrG+auVsFlno4+bE3oqV6zPdxnHE=; b=LwomTFlKsYogobrku83tnS7KngMTNfc6Ll1xuXUbpsaeuxdIT13giF4oSCAuiFOTNy TJYosmGKeFfoV7adm3VNpEsfAPQPZd0Tp8gA/76HIN8zGKJsk9+UxtYoUuDDEg8mqe6t CYZS/us0TUydC2h0Lix2o6bRnCVy42LMB2TIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Jvc4ZmGIOEzTmtinNt73/yWZMpvJVTZA/QFDJCBbm/6pNN4nw/3q3Ykw3kcanI+MkP Qm2zG8A89aDGKTwJrsA7U8oNsOTMsLjvyaK2yeZE1JYI9cFPLSosEEmIkwZ4gIrIpbno 9rBaIWGv0ygDl35lgxfwc4f79mf5aixNLreGI= MIME-Version: 1.0 Received: by 10.224.73.140 with SMTP id q12mr9676026qaj.293.1240419693640; Wed, 22 Apr 2009 10:01:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Apr 2009 13:01:33 -0400 Message-ID: Subject: Re: [SCXML] getting set datats in the datamodel From: Rahul Akolkar To: Commons Users List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Apr 22, 2009 at 9:35 AM, Linda Erlenhov wrote: > Hello > Is there anybody that can help me with my problem described below? > > best regards > //Linda > > On Mon, Apr 20, 2009 at 2:05 PM, Linda Erlenhov wrote: > >> Hello >> I think I=B4ve done some mixing between two things that doesn=B4t work t= ogether >> as I hoped it would. >> >> I have this Datamodel, the scxml document starts like this: >> ------------------------ >> > http://commons.apache.org/scxml" xmlns=3D"http://www.w3.org/2005/07/scxm= l"> >> >> >> >> 0 >> >> >> >> >> ------------------------- >> >> I assign the "Indication1" later on: >> >> --------------- >> >> >> >> >> >> >> ------------------------------- >> >> And the "DynamicData" also later: >> --------------- >> >> >> >> >> > expr=3D"Data(DynamicData,'NumDat')+1"/> >> >> >> >> ------------------------------- >> >> I implemented a custom context with a notification functionality in the >> "set" function (observer observed pattern) but the problem now is that t= he >> only time the "set" function in the context is used is when indications = are >> set. Not when the DynamicData is set. I know that the SCXML works and th= at >> the expressions evaluate properly because of the log:labels, my guess is >> that it=B4s something with the Data() function that makes these expressi= ons do >> something different. What? Where is the "set" for the DynamicData locate= d? Yup, I see what you are running into. Unfortunately for the specific usage pattern here, the two variations have different semantics as follows: 1) is a set operation, which produces a Context#set(...) call 2) is really a mutation operation, it retrieves the XML 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? >> 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: