[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093050#comment-17093050
]
Jaroslav Tulach commented on NETBEANS-4222:
-------------------------------------------
Thanks for providing the use-case. First and foremost there is
[PropertySheet|https://bits.netbeans.org/dev/javadoc/org-openide-explorer/org/openide/explorer/propertysheet/PropertySheet.html]{{.setNodes}}
method. Why can't you use that one? Obtain your nodes, do as much filtering as
you want, create suitable {{ownRepresentingNode}} node and
{{sheet.setNodes(ownRepresentingNode)}}. It's going to render what you provide
and the performance will be completely under your control.
Second, if you really want to reuse the code from {{ProxyNode}} (what's the
biggest motivation?) then: Would it be enough to add a single method to
{{PropertySheetView.setFinalNodeFilter(Function<Node,Node>
proxyNodeToCleanupNode)}} to do additional post processing?
Re. your comments about "rigidity, severely limits & co.":
[PropertySheet|https://bits.netbeans.org/dev/javadoc/org-openide-explorer/org/openide/explorer/propertysheet/PropertySheet.html]
API is an excellent example where making everything public leads. Look at the
list of deprecated methods in there! Once upon a time there was a guy who
thought exposing everything is a good idea. Then there was a guy who needed to
change the implementation to look completely different, but do the same (e.g.
display & edit properties of nodes). However the previous implementation was
leaking out. As a result of that there is more deprecated methods than not
deprecated ones.
It is not very likely someone is going to reimplement {{PropertySheet}}
internals again, but I am not willing to repeat similar mistake. It is
perfectly valid to request the "API to be more flexible", but that shall not be
achieving by making implementation public. API shall be designed, not created
ad-hoc by making parts of implementation public!
Last, but not least: You complain about poor performance of {{ProxyNode}} - do
you have an analysis? Wouldn't it be possible to improve it without changing
the API at all?
> Open up more of APIs in Node and PropertySheet
> ----------------------------------------------
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
> Reporter: Markus Sunela
> Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#000000}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
