This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 35025 - Should be TopComponent property for unique internal name, distinct from getName
Summary: Should be TopComponent property for unique internal name, distinct from getName
Status: RESOLVED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: mslama
URL:
Keywords: API, T9Y
Depends on:
Blocks:
 
Reported: 2003-07-21 18:00 UTC by Jesse Glick
Modified: 2008-12-22 23:58 UTC (History)
4 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-07-21 18:00:18 UTC
TC.getName() is used for the display name of the
TC. This is OK, but the window system also uses
the same string (after uniquification) as an
internal identifier for the TC instance - e.g. see
PersistenceManager.createNewPair. This does not
seem smart; the display name may have arbitrary
characters in it, be unpredictable in different
locales, etc. Suggest in TopComponent e.g.:

/**
 * Get a programmatic name for this component.
 * Should be unique among all components in the
 * system if possible. If it is unique, it will
 * be used as the ID in top component references
 * (see the Window System API documentation on
 * XML storage formats).
 * <p>The value ought not change from call to
 * call if possible.
 * <p>The default implementation just calls
 * {@link #getName}. Subclasses are strongly
 * encouraged to override this.
 */
public String getID() {
    return getName();
}

then use this new method in PersistenceManager and
wherever else it might be required.
Comment 1 Jesse Glick 2003-07-21 18:00:58 UTC
Note that the WS API does not currently specify how TC IDs are
generated for newly stored TC's, so this should be compatible.
Comment 2 mslama 2003-07-24 10:14:25 UTC
Some comments: Currently some kind of unique Id is used in winsys
persistence to create unique file name for serialization of
TopComponent. (It means that there is one additional requirement for
TC Id: It must be valid file name.) As not all TopComponents are
persistent currently used persistence TC Ids are subset of all unique
Id. I think there should be some global set of all used TC Ids which
are in use. This set must be initialized on startup from setting file
names. For newly created TC new unique Id must be created.

Yes. Currently when new peristence TC Id is created TopComponent name
is used as starting point. Then conversion is used to be able to
create valid file name (using InstanceDataObject method
escapeAndCut()). (Advantage is that we are able to guess what settings
file belongs to given TC. It is better then to create unique TC Id
like 'RDSFA3524'.)

Is there any preference what initial value should be taken as starting
guess for new Id?

I think this method should be final. (We want to get unique Id and
subclasses do not have access to necessary info to make sure that
their Id will be unique.)
Comment 3 Jesse Glick 2003-07-24 14:46:39 UTC
I think the whole point of adding this method to the API was to make
it *not* final. Otherwise there is no need for modules to pay
attention at all. You want to permit TC's to specify an ID based on
some programmer-friendly information. Using TC.name is not good
because it is based on a localized display name, which should never be
used as the basis of programmatic storage.

You could document protected getPreferredID() as providing a *hint*
for the persistence ID, that the window system might further uniquify
(e.g. "foo" -> "foo17"), and provide an additional method public
getID(), where it is documented that getPreferredID() is called only
once, from the superclass constructor (though this is a little evil),
and subsequently getID() is valid to call.
Comment 4 mslama 2003-07-30 13:32:17 UTC
> I think the whole point of adding this method to the API was to 
> make it *not* final. Otherwise there is no need for modules to pay
> attention at all. You want to permit TC's to specify an ID based 
> on some programmer-friendly information. Using TC.name is not 

I thought that user (developer) wants some unique AND fixed id for
TopComponent instance. If we allow subclasses to create their own id
we cannot make sure uniqueness of such id. Is there any reason why
subclass needs to create its own id?

If yes it is against persistence requirement and peristence must
create its own independent id.

> good because it is based on a localized display name, which 
> should never be used as the basis of programmatic storage.

> You could document protected getPreferredID() as providing a *hint*
> for the persistence ID, that the window system might further 
> uniquify (e.g. "foo" -> "foo17"), and provide an additional method >
public getID(), where it is documented that getPreferredID() is 
> called only once, from the superclass constructor (though this is 
> a little evil), and subsequently getID() is valid to call.

To decide if it should be used as persistence id we need some usecase
from Tor. The only usecase I know so far is persistence. Still I think
that any ID returned by getID() should be unique. Otherwise it has no
sense IMHO. So question is how to make sure it is unique. And when it
is unique it can be used by persistence if it is not unique
persistence cannot use it and must implement its own persistence ID.
Comment 5 Winston Prakash 2003-07-30 19:23:33 UTC
For project Rave, we are using external layout manager for window
management. In this layout manager, every window created need to have
its own unique id. Initially we used TopComponent.getName() for this
purpose. This turned out to be meanigless for the argument below. So
we added TopComponent.getId() which solved the problem.

public String getId() {
    return getName();
}

I agree to Marek's argument that this Id should be unique for
persistence. So what we did for Project Rave is - let the user specify
an id (may not be unique). But while docking to Mode, this id is
checked with persistence manager and converted as unique one and set
back using setId().

tc_id = pm.lookupTCStringId(topComp);
topComp.setId(tc_id);

- Winston Prakash
Comment 6 Jesse Glick 2003-08-05 18:13:12 UTC
Right, the developer should be able to specify a *hint* for what the
ID should be - some unlocalized code name, without messy weird
characters etc.

I don't really like the setID suggestion - makes it seem like the ID
is mutable, which it should not be. Suggest maybe in TC:

/**
 * subclasses encouraged to override
 * value preferably unique, but need not be
 */
protected String preferredID() {
    return getName();
}
/**
 * unique permanent ID
 */
public final String getID() {
    // looks up some global collection of TC's
    // and chooses a unique ID based on
    // preferredID, and remembers it
    // will be the same after externalization
}
Comment 7 Jiri Skrivanek 2003-09-03 08:35:17 UTC
For testing it would also be useful if top component has unique name.
We want to use Component.getName() to search for a component. That is
why we would appreciated if for example Filesystems tab is named
"tcFilesystems" or something similar. At least it should not be
localized name, e.g. for editor TC it should be "tcMyFile" instead of
"MyFile [Up-to-date; 1.2]". 
Comment 8 mslama 2003-09-03 10:00:24 UTC
Jiri it is different issue. This issue is about unique TopComponent Id
not about value returned by getName(). (Even if getName() could be
used by default as hint for creating unique Id.)
Comment 9 Jesse Glick 2003-09-03 17:10:27 UTC
I don't think it is a different issue. Currently - unwisely, IMHO -
Component.getName is overridden in TopComponent to mean a localized
name (whereas in Component it is more like an internal ID). Since it
is too late to correct this API defect, the least we can do is make a
distinct internal ID for a TopComponent which can be used like getName
is for regular Component's - for uniquely identifying a displayed
component, creating a registry path for persisting state, etc.

Re. editor TC's - agreed that the ID should be "plainer" (e.g. not
include crap like VCS annotations). Might even suggest that it be made
more uniquified, e.g. the CloneableEditor for MyFile.java might have
an ID like

file:///home/jglick/src/org/nb/foo/MyFile.java

(ideally FileObject.getURL under masterfs would produce a good URL
like this) which would really be unique and capture its identity.
Comment 10 mslama 2003-10-13 12:12:14 UTC
Methods public String getID() and protected String preferredID() was
added to TopComponent. TopComponent.getName()/setName() should not be
used for display name anymore in new winsys.