[kepler-dev] What is this?
Ilkay Altintas
altintas at sdsc.edu
Fri Oct 15 13:49:59 PDT 2004
> -----Original Message-----
> From: Edward A. Lee [mailto:eal at eecs.berkeley.edu]
> Sent: Friday, October 15, 2004 5:24 AM
> To: Ilkay Altintas
> Cc: Christopher Brooks; Rod Spears; kepler list
> Subject: RE: [kepler-dev] What is this?
>
>
> At 01:29 PM 10/14/2004 -0700, Ilkay Altintas wrote:
> >The problem is, since attributeChanged is being called
> >everytime I update the operation names, or in the constructor, etc..
> >So when I save and reopen the test workflows, all the link to
> >the configured actor is gone because the ports have been
> >renewed.
>
> Even if you fix this, I think that deleting ports is risky because
> it discards user data. Perhaps a reasonable compromise would be to
> delete a port only if the newly selected service does not require
> a port with the same name... This way, if you switch services
> but they have common port names, you don't lose connections...
Edward,
Thanks for the tip... In the case of the web service actor, I
believe checking the port names wouldn't solve the problem
because everytime I open the workflow, the operation name is
being set to empty string again and everytime I add a new
choice to the operation name, the attributeChanged is being
called again.
So I checked the url, operation name and state of the actor
before the url and operation had changed. Depending on that
state, I apply the changes (sometimes partially) or not. It
looks like this has solved the problem for now.
I was wondering if there could be a safer way of doing GUI and
port updates without having to do it right when the attributes
are changed. Like collecting the changes somehow and applying
them at once so that the changes in the middle won't change
the GUI and port configuration. Would changeRequest() be used
for this purpose?
Thanks,
Ilkay
> Edward
>
>
>
> ------------
> Edward A. Lee, Professor
> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
> phone: 510-642-0455, fax: 510-642-2739
> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>
More information about the Kepler-dev
mailing list