[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...


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?

> 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