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.
Do not break binary compatibility of TopComponent subclasses by introducing new final methods, it would be nice to keep source compatibility, but that is not such a strong requirement. That is why it was agreed that there should be no public final String getId (); and that this method should be moved into WindowManager, where it logically belongs as WindowManager is the final decision maker as concern the actual id of the component: public abstract String WindowManager getId (TopComponent); It has however been decided that it is ok to keep the protected String TopComponent.preferredId (); that will be used by the window manager when computing the getId value. The possible source compatibility problems were found acceptable in this case.
My own opinion: I was thinking about the problem a bit and I'd like to suggest another solution, which would address the discoverability of the getId method (hidden in previous suggestion among other methods in WindowManager). The good think on this solution is that it does not introduce binary or source compatibility problems and also keeps the getId method in TopComponent. I'd like other reviewers to review attached patch. If not agreed, then just ignore it and implement the one described in previous chapter.
Created attachment 12017 [details] Introduces TopComponent.ID - caching of unique ID has to be done in WM, but that should be ok, I guess
Not sure that's much of an improvement. (BTW tc.getID().getID() is ugly.) If discoverability of the getID method is the main problem, consider simply renaming it to e.g. getPersistenceId() (with corresponding preferredPersistenceId()) and making it final in TC as before the TCR - unlikely to be a name conflict with an existing subclass. No strong feelings here though - either the solution initially described in this issue, or Yarda's new patch, would be OK.
My opinion is that tc.getID().getID() shouldn't be used. I think it should be much more important that the API is clear and understandable.
I am going to implement solution with public abstract String WindowManager.getTopComponentId(TopComponent) and protected String TopComponent.preferredId()
Created attachment 12052 [details] Diff of patch
Please check last diff. If there will be no objections I will commit it tomorrow.
Jarda suggests findTopComponentID instead of getTopComponentID due to some consistency with other WindowManager public methods.
Fixed in winsys branch.
Ok.
Can WindowManager.getTopComponentID be final, if topComponentID is doing the actual work anyway? Otherwise, fine.