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.
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.
Note that the WS API does not currently specify how TC IDs are generated for newly stored TC's, so this should be compatible.
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.)
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.
> 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.
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
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 }
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]".
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.)
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.
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.