[kepler-dev] How To Get a Reference to the Configuration?
Matthew Brooke
brooke at nceas.ucsb.edu
Mon Nov 21 15:04:07 PST 2005
Hi Edward -
Thanks for the response. Unfortunately, I couldn't figure out how to get
a reference to a TableauFrame anywhere in XMLIcon, so I couldn't call
getConfiguration() (like your example in
ptolemy.domains.tm.kernel.SchedulePlotter).
I finally stumbled blindly upon the following solution, which uses the
existing (and life-saving) static Configuration.findEffigy() method, but
which works *only* if called from the getBackgroundFigure() or getIcon()
methods of XMLIcon. It does *not* work if called from the constructor -
maybe because the icon hasn't yet been added to the hierarchy by that
point...? Anyway, here it is for posterity, in case anyone else ever
needs it, or in case I forget how I did it :-)
///////// code called from XMLIcon's /////////
///////// getBackgroundFigure() or getIcon() methods /////////
Nameable container = this.getContainerOrContainerToBe();
if (container == null || !(container instanceof NamedObj)) {
return null;
}
NamedObj topLevelNamedObj = ((NamedObj)container).toplevel();
Effigy effigy = Configuration.findEffigy(topLevelNamedObj);
if (effigy == null) {
return null;
}
NamedObj effigyTopLevel = effigy.toplevel();
if (! (effigyTopLevel instanceof Configuration)) {
return null;
}
return (Configuration)(effigyTopLevel);
//////////////
--
---------------------------------------------
Matthew Brooke, Ph.D.
Marine Sciences Research Building, Room #3407
University of California
Santa Barbara, CA 93106-6150
ph: (805) 893-7108 fx: 805-893-8062
brooke at nceas.ucsb.edu
---------------------------------------------
Edward A. Lee wrote:
>
> No, this won't do it... This will only yield a configuration
> if the object is contained in a library rather than a model.
>
> In fact, that it is difficult to get to the configuration is
> a consequence of the deliberate decision that we made some time
> ago that Ptolemy II models can run without Vergil. This means
> that the model should have no chain of references to anything
> in the UI, because if it does, then to load the model into
> a JVM, you have to load the UI classes.
>
> There are workarounds for this, but they are tricky.
> I did a quick search, and found an example in
> ptolemy.domains.tm.kernel.SchedulePlotter. Look
> for the invocation therein of getConfiguration().
> I'm sure there are other examples in the tree, but
> I don't have time right now to look for them...
>
> Edward
>
>
> At 01:10 PM 11/18/2005 -0800, Christopher Brooks wrote:
>> Hi Matthew,
>>
>> Edward knows this one, but I'll take a guess.
>>
>> Trying going up the containment hierarchy until
>> you get to an object that is a Configuration.
>>
>> moml/SharedParameter.java has code like:
>>
>> /** Return the top level of the containment hierarchy, unless
>> * one of the containers is an instance of EntityLibrary,
>> * in which case, return null.
>> * @return The top level, or null if this is within a library.
>> */
>> public NamedObj getRoot() {
>> NamedObj result = this;
>>
>> while (result.getContainer() != null) {
>> result = (NamedObj) result.getContainer();
>>
>> // FIXME: this means that ptolemy.moml depends on
>> // ptolemy.actor.gui. We could either do instanceof
>> // or else create ptolemy.kernel.ConfigurationBase
>> // and have Configuration extend it.
>> if (result instanceof Configuration) {
>> // If the results is a Configuration, then go no higher.
>> // If we do go higher, then we end up expanding the actor
>> // library tree which take a long time and fails if
>> // not all the actors are present. For example, not
>> // everyone will have Matlab or quicktime.
>> return null;
>> }
>> }
>>
>> return result;
>> }
>>
>> This might do it, though I think the object would need to have been
>> created from within the GUI.
>>
>> Edward would know for sure.
>>
>> _Christopher
>>
>>
>> --------
>>
>>
>> Hi all:
>>
>> I'm working on the Kepler project (www.kepler-project.org), and am
>> having trouble getting at the configuration object from other
>> parts of
>> the application. Is there an "standard" ptii way to do this, without
>> explicitly passing references?
>>
>> I'm interested in reading settings from the configuration.xml
>> file, but
>> it seems like I can get a reference only from a TableauFrame or
>> from the
>> MoMLApplication/VergilApplication classes. If I don't have a
>> reference
>> to any of those classes, how do I get the config?
>>
>> One workaround would be to read the config myself each time, by
>> creating
>> my own MoMLParser, but this seems unnecessarily expensive, and
>> still has
>> the problem that the parser needs the URL for the config file, which
>> also doesn't seem to be available globally.
>>
>> Any help from anyone would be greatly appreciated
>>
>> Thanks!
>>
>> Matthew
>>
>>
>> --
>>
>> ---------------------------------------------
>> Matthew Brooke, Ph.D.
>> Marine Sciences Research Building, Room #3407
>> University of California
>> Santa Barbara, CA 93106-6150
>> ph: (805) 893-7108 fx: 805-893-8062
>> brooke at nceas.ucsb.edu
>> ---------------------------------------------
>>
>>
>> ---------------------------------------------------------------------------
>>
>> -
>> Posted to the ptolemy-hackers mailing list. Please send
>> administrative
>> mail for this list to:
>> ptolemy-hackers-request at ptolemy.eecs.berkeley.edu
>> --------
>>
>> ----------------------------------------------------------------------------
>>
>> Posted to the ptolemy-hackers mailing list. Please send administrative
>> mail for this list to: ptolemy-hackers-request at ptolemy.eecs.berkeley.edu
>
> ------------
> 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
>
> ----------------------------------------------------------------------------
>
> Posted to the ptolemy-hackers mailing list. Please send administrative
> mail for this list to: ptolemy-hackers-request at ptolemy.eecs.berkeley.edu
More information about the Kepler-dev
mailing list