Bug 2217 - Provide facility for "tool" node properties, analogously to ToolsAction.
Provide facility for "tool" node properties, analogously to ToolsAction.
Status: CLOSED DUPLICATE of bug 18177
Product: utilities
Classification: Unclassified
Component: Search
3.x
All All
: P4 (vote)
: 3.x
Assigned To: Petr Hrebejk
issues@utilities
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 1999-06-11 02:03 UTC by Jesse Glick
Modified: 2003-07-01 15:52 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 1999-06-11 02:03:14 UTC
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
Comment 1 Jaroslav Tulach 2000-07-03 13:11:59 UTC
This is the pattern that should replace "the chain" of nodes in the Java module.
Let's use this bug to discuss possible implementations.
Comment 2 Marek Grummich 2000-07-25 09:07:59 UTC
Priority is changed to P4 (normal).
Comment 3 Jan Chalupa 2001-05-06 08:10:37 UTC
Target milestone -> 3.3
Comment 4 Jesse Glick 2001-11-06 15:08:35 UTC
I guess this is in progress?
Comment 5 Jan Chalupa 2001-11-27 15:30:26 UTC
Target milestone -> 3.3.1.
Comment 6 Petr Hrebejk 2002-04-03 11:40:13 UTC
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 ***
Comment 7 Quality Engineering 2003-07-01 15:47:48 UTC
Resolved for 3.4.x or earlier, no new info since then -> verified
Comment 8 Quality Engineering 2003-07-01 15:52:53 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo