[kepler-dev] problems with annotations

[Shawn Bowers]

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