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.

Bug 182427 - Need a way to programmatically initiate edit in-place edit
Summary: Need a way to programmatically initiate edit in-place edit
Alias: None
Product: platform
Classification: Unclassified
Component: Explorer (show other bugs)
Version: 6.x
Hardware: PC All
: P2 normal (vote)
Assignee: Vladimir Voskresensky
Depends on:
Blocks: 163675
  Show dependency tree
Reported: 2010-03-20 19:08 UTC by _ tboudreau
Modified: 2015-03-20 10:02 UTC (History)
6 users (show)

See Also:
Exception Reporter:

Patch adding TreeView.editNode(Node) (8.70 KB, patch)
2010-03-20 19:19 UTC, _ tboudreau
Details | Diff
Updated patch (8.16 KB, patch)
2014-11-14 16:03 UTC, ilia
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2010-03-20 19:08:52 UTC
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.
Comment 1 _ tboudreau 2010-03-20 19:19:54 UTC
Created attachment 95487 [details]
Patch adding TreeView.editNode(Node)
Comment 2 Vladimir Voskresensky 2010-03-20 22:32:35 UTC
Hi Tim, 
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?
Comment 3 _ tboudreau 2010-03-21 04:55:00 UTC
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.
Comment 4 Jesse Glick 2010-03-22 14:01:46 UTC
(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.
Comment 5 Vladimir Voskresensky 2010-04-07 22:01:44 UTC
any news when it can be pushed?
Comment 6 Jaroslav Tulach 2010-10-07 18:25:34 UTC
Who's going to take care of interating this?
Comment 7 Vladimir Voskresensky 2010-10-08 12:20:53 UTC
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
Comment 8 _ tboudreau 2010-10-17 02:42:30 UTC
No plans to integrate this personally;  assuming nobody objects strenuously, go ahead.
Comment 9 Jaroslav Tulach 2014-11-05 12:01:34 UTC
Long time open API review request with no progress. Closing to raise people's attention.
Comment 10 _ tboudreau 2014-11-05 12:12:04 UTC
Legitimate use cases, Vladimir offered to integrate.
Comment 11 Jaroslav Tulach 2014-11-05 12:23:02 UTC
OK, rasing priority to be treated as bug. If nobody integrates, not even the module owner, close the issue and Tim, please don't try to reopen then unless you are willing to finish the work.
Comment 12 Vladimir Voskresensky 2014-11-10 12:51:39 UTC
if there are no objections I will update apichanges.xml and integrate
Comment 13 Jaroslav Tulach 2014-11-10 13:11:46 UTC
I see JG01-JG05 which has not been addressed as far as I can tell. Probably create updated patch first. When addressed, it should be no brainer to integrate.
Comment 14 Vladimir Voskresensky 2014-11-10 13:16:39 UTC
Ok. I will prepare the updated patch.
Comment 15 ilia 2014-11-14 16:03:13 UTC
Created attachment 150492 [details]
Updated patch
Comment 16 ilia 2014-11-14 16:03:35 UTC
JG01-JG05 fixed.

Also the class "EditInitiator" has been made final.
A patch is attached.