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.
http://wiki.netbeans.org/MoreDeclarativeRegistrationUsingAnnotations#Navigator_panels
Created attachment 114669 [details] Proposed patch
Please review.
Y01 Better support for laziness. Right now all NavigatorPanel interfaces need to be loaded, even only one of them is usually visible. Avoid this. I'd suggest to include displayName, hint and other necessary attribute to the @Registration annotation. Y02 Simplify the API. Allow people to annotate any JComponent with the annotation, so in simple cases people don't need to create the NavigatorPanel interface at all.
Y01 - can look into this, though note that the payoff is small: leaving aside the special case of XMLNavigatorPanel (cf. bug #129558) which is likely to be loaded anyway, the only known cases of a MIME type with more than one panel are text/x-maven-pom+xml (2) and text/x-java (6), meaning at best six classes saved (but one proxy class added in all cases). Y02 is out of scope, and probably not feasible anyway since it would not permit the context to be attached.
Re. Y01, OK, please look at it. Achieving scalability with annotations is much easier than with old java classes and can only pay off. Re. Y02: The component could have a constructor taking Lookup it would be passed into it. Moreover the component could take any Type (for example JavaSource) which would then be injected into it.
(In reply to comment #4) > text/x-java (6) ...and four of those six are in java.debug, where they are conditionally displayed in dev builds, meaning they cannot be represented with a lazy annotation. (cf. bug #207001)
Y02 - ctor taking Lookup would be possible, but a little subtle because the infrastructure might actually need to pass a proxy for the current lookup, unlike the current panelActivated which might be called several times with different lookups. Ctor taking the specific type (or collection?) would not work at all unless the JComponent were recreated each time the panel were displayed, which is not necessarily efficient. Activated and deactivated events would still need to be sent somehow, so you would need to separately document what JComponent methods these correspond to. getLookup would not work unless you implemented Lookup.Provider, which would also need to be separately documented. All in all, it seems like this would make everything more complicated, not simpler, and make documentation worse since there would be no natural "home" for Javadoc explaining what each method should do; and upgrading current NP impls would not be trivial. If you really want this, it can be done as a separate API review but I do not plan to work on it.
Created attachment 114689 [details] Revised patch Includes Y01 and converts some more registrations.
core-main #a263d7624177
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/a263d7624177 User: Jesse Glick <jglick@netbeans.org> Log: #206954: annotation to register navigator panels.