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
- 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
- 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
*** 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.