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.
In some cases it is sensible to want to add new node properties to nodes you do not own, e.g. JavaNode`s are used very frequently by integrators and sometimes the best UI would be to add new node pr operties to them. Since it is ugly and dangerous to actually find the nodes and insert the properties (even if the methods were not protected), suggest a callback system like ToolsAction: - Create a class ToolsPropertySet extending Node.PropertySet, or ToolsSheetSet extending Sheet.Set (NOTE: currently final), or built into Sheet.java. Any node wishing to support tool properties would add this sheet set to its sheet in createSheet, or add the property set to its list of property sets in getPropertySets, or call a special constructor of Sheet.Set indicating that it wished to permit tool properties. - Modules could add "property providers"--either from static register/unregister methods in the appropriate class, or according to a manifest section tag OpenIDE-Module-Class: PropertyProvider, which impl would add to a model in the APIs (as for ToolsAction). The provider would be anything implementing an interface, which would have one method taking a node as argument (the node to attach properti es to) and returning a (possibly empty/null) list of properties, or a Sheet. - If returning a list of properties, then to support updates to the list, the provider would listen to (e.g.) cookie changes on the node, and call some static refresh method (taking e.g. the node and the provider as args). Then all tool properties would be clustered in one Tools sheet set, or perhaps separated into one sheet set per module, or something. If a sheet set were empty, it would be setH idden (true). - If returning a Sheet (more flexible solution), then the sheet sets returned would be automatically merged into the regular sheet sets explicitly created by the node. Attempts to modify the propertie s or sets merged in in this way would throw an error. The provider could simply update its she
This is the pattern that should replace "the chain" of nodes in the Java module. Let's use this bug to discuss possible implementations.
Priority is changed to P4 (normal).
Target milestone -> 3.3
I guess this is in progress?
Target milestone -> 3.3.1.
The tasks in this issue can be considered identical with functionality of the Looks API, thus making this issue a duplicate of Create Stable LooksAPI task. *** This issue has been marked as a duplicate of 18177 ***
Resolved for 3.4.x or earlier, no new info since then -> verified
Resolved for 3.4.x or earlier, no new info since then -> closing.