[kepler-dev] problems with annotations

[Edward A. Lee]

You can also create an anonymous inner class the subclasses ChangeRequest
and overrides the _execute() method to do whatever you need to do...
See for example ptolemy.actor.lib.SetVariable, which uses this mechanism
(search the file for "new ChangeRequest").

Edward

At 11:37 AM 10/31/2005 -0800, Shawn Bowers wrote:
>Hi,
>
>Thanks for the reply.
>
> From the Javadoc it appears that ChangeRequest is abstract, with only
>three subclasses: MoMLChangeRequest, RedoChangeRequest, and
>UndoChangeRequest.
>
>So, it appears that the only way to affect a change/update is by
>passing MoML, since Undo (as you stated below) and Redo (I'm guessing)
>require MoMLChangeRequest.
>
>
>-shawn
>
>
>Edward A. Lee wrote:
> >
> > Shawn:
> >
> > A change request does not have to be a MoML string. In fact,
> > many of them are not.  In particular, a change request is an
> > instance of ChangeRequest.  MoMLChangeRequest is a subclass.
> >
> > However, the "undo" mechanism in Vergil will only work if the
> > change request is an instance of MoMLChangeRequest. Thus,
> > if you make changes using ChangeRequest, they are not undone
> > by the undo command.  There are many circumstances in which
> > this is OK.
> >
> > Edward
> >
> > At 01:45 AM 10/27/2005 -0700, Shawn Bowers wrote:
> >
> >> The following comment may be coming from far left field, but I have
> >> never quite understood why a change request as it is currently defined
> >> in ptolemy requires the passing of a MoML XML string.
> >>
> >> In particular, it is confusing to me as a developer why I have to deal
> >> with *both* the object model of ptolemy/kepler as well as the
> >> serialization syntax of the part of the object model I'm
> >> instantiating or modifying.
> >>
> >> I think it would be more convenient to pass *objects* to change
> >> request, not XML serializations of the things I want to update.
> >>
> >> Does that make sense?
> >>
> >> Thanks,
> >> -shawn
> >>
> >>
> >> Edward A. Lee wrote:
> >>> At 08:01 AM 10/26/2005 -0700, Christopher Brooks wrote:
> >>>> Your design of using EmptyChangeRequest seems reasonable, though
> >>>> it seems to point out a bug in the Ptolemy code.
> >>> I don't think it's a bug in the Ptolemy code.
> >>> The reason that EmptyChangeRequest works is that after
> >>> any change request, the model gets redrawn.  This is
> >>> a very brute-force way to react to change requests,
> >>> and in fact is very costly (even changes that have no
> >>> visible side effects will trigger a redraw).
> >>> Thus, the real problem is long term: If we fix Ptolemy II
> >>> so that redraws occur only when necessary, then the
> >>> EmtpyChangeRequest will no longer do what you want...
> >>> Edward
> >>>
> >>> ------------
> >>> Edward A. Lee
> >>> Professor, Chair of the EE Division, Associate Chair of EECS
> >>> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720
> >>> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> >>> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
> >>> _______________________________________________
> >>> Kepler-dev mailing list
> >>> Kepler-dev at ecoinformatics.org
> >>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> >
> > ------------
> > Edward A. Lee
> > Professor, Chair of the EE Division, Associate Chair of EECS
> > 231 Cory Hall, UC Berkeley, Berkeley, CA 94720
> > phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> > eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal

------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal