I was able to fix the problem by adding MoMLChangeRequests (ch. 7, vol.
1 of the design doc) for some of the cascading updates. Comparing my
("autonomous") update code to the controllers for the PortConfigurer and
EditParametersDialog, it looks like the changes don't propagate to the
MoML source without explicit change requests. I had wrongly assumed
that my calls to setToken(), setTypeEquals(), etc. would force the MoML
changes. My actors now round-trip correctly.
For the service description buffer, I ended up persisting a Variable as
a ConfigurableAttribute (service descriptions are WSDL definitions, so
wrapping the buffer in <configure> tags was the easiest way to preserve
the original document).
Thanks,
Andy Z.
---
Andrew L. Zimdars
Sr. Software Engineer; Modeling, Simulation, and Information Sciences
Advanced Technology Center, Lockheed Martin Space Systems Co.
1111 Lockheed Martin Way, B/153, C/2J4 | Sunnyvale CA 94089
w : 408/742-2111 | [EMAIL PROTECTED]
m : 510/915-0662 | [EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 04, 2006 1:16 PM
To: Zimdars, Andrew
Cc: ptolemy-hackers@bennett.EECS.Berkeley.EDU
Subject: Re: Attribute updates not appearing in MoML document
Hi Andrew,
Perhaps the remote service buffer needs to be a parameter?
You can hide parameters from the user by setting it as an Expert
parameter.
See $PTII/ptolemy/actor/lib/gui/SketchedSource.java:
initialTrace.setVisibility(Settable.EXPERT);
You could also try having your remote service buffer be an Attribute.
I'm not sure if that will be preserved though.
You might also need to get trigger change requests, though that should
be happening for you.
_Christopher
--------
I'm working on an atomic actor right now where user-specified
parameter
changes trigger further updates to the actor. For example, the user
enters the name of a file that contains a remote service definition,
and
the actor loads and processes the file, extracting from it
information
like port names and types. The user update (entering a file name)
causes a cascade of calls to attributeChanged() -- the file is read
into
a buffer variable, triggering parsing of the buffer contents,
triggering
the creation of new ports and the assignment of types to those
ports,
and so on.
The end result is a correctly-configured actor. It has the correct
input and output ports, with the correct types; it knows how to bind
to
the remote service. However, when I save and reopen the model
containing the actor, I find that a lot of the configuration values
were
not persisted. In particular, the port types and the contents of
the
service definition buffer don't survive the round trip.
What objects do I need to notify when these "autonomous" updates
occur
so the new values make it into the exported MoML?
Thanks,
Andy Z.
---
Andrew L. Zimdars
Sr. Software Engineer; Modeling, Simulation, and Information
Sciences
Advanced Technology Center, Lockheed Martin Space Systems Co.
1111 Lockheed Martin Way, B/153, C/2J4 | Sunnyvale CA 94089
w : 408/742-2111 | [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
m : 510/915-0662 | [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
------------------------------------------------------------------------
---
-
Posted to the ptolemy-hackers mailing list. Please send
administrative
mail for this list to:
[EMAIL PROTECTED]
--------
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
