A topic that regularly comes up on dev@platform is how to programmatically initiate in-place editing mode inside a BeanTreeView. It is a reasonable request since it is a common UI pattern to have an action which adds a new child node (think of New Folder actions in file choosers) and immediately places the node into edit mode for the user to supply a name.
There is no good way to do this currently - you have to fish around in the component hierarchy for the tree, try to map a VisualizerNode to a node without access to the VisualizerNode java class, and then call tree.startEditingAtPath() for it. All very complicated and not reliable.
I'm attaching a patch which adds TreeView.editNode(Node), with tests.
Since we are adding a method to TreeView, which is subclassable, technically this is an incompatible change (theoretically some subclass could exist which has a method called editNode(Node) with a non-void return type.
However, since subclassing TreeView or BeanTreeView is a very rare activity, I would argue that it is safe enough to simply add the method. If someone has a very strong objection to this, the method could be added as a static method ExplorerUtils.editNode (BeanTreeView, Node) - but this would be incredibly non-obvious, and so we will keep getting questions about it. Would prefer to do it the straightforward way.
Created attachment 95487 [details]
Patch adding TreeView.editNode(Node)
thanks for initiative, but it doesn't solve completely the use case.
Because clients have only Node object in their "performAction(Node nodes)"
=> the next logical question would be
"how to extract BTV from ProjectTab, Files Tab, Favorietes Tab, ClassView tab, ..."
Node class has "canRename" method which controls it's "rename" capability not bothering about current tree/list/... container => it's preferable to have editNode(Node) without bothering how to extract current view container.
May be we can put something into Node's lookup?
Then you need and additional API from whatever module is producing the view you want edit mode set in. That use case can't be solved just at the Node level - a Node can be visible in multiple views, and has no knowledge of the views that are showing it. However, this patch does solve the first half of the problem and will be needed to solve the second half of it.
(In reply to comment #3)
> a Node can be visible in multiple views, and has no knowledge of the views that
> are showing it.
Exactly. In general you would need to either have created the tree view yourself, so you can have a reference to it; or you can grep open TC's for those which are ExplorerManager.Provider's. (Issue #7551 is related but not the same as that would make it easier to find a node under a root node, whereas we also need the ability to find a view for a node.)
[JG01] Missing @since.
[JG02] "logs and error" - typo.
[JG03] editNode should probably be final; I don't see any use case for overriding it.
[JG04] Level.SEVERE is excessive for this purpose. WARNING would suffice.
[JG05] IAE is claimed to be thrown from editNode, but it will not be - it is thrown in EQ and will be caught there and logged as a WARNING.
any news when it can be pushed?
Who's going to take care of interating this?
If Tim can not integrate (Tim, any issues with integration?) then I can integrate this.
It's a usability issue which makes NB looks like student's prototype when instead of in-place editing shows modal dialog to change one "string" value
No plans to integrate this personally; assuming nobody objects strenuously, go ahead.