Bug 182427 - Need a way to programmatically initiate edit in-place edit
Need a way to programmatically initiate edit in-place edit
Status: REOPENED
Product: platform
Classification: Unclassified
Component: Explorer
6.x
PC All
: P1 (vote)
: TBD
Assigned To: Jan Peska
issues@platform
cndreq
: API, API_REVIEW_FAST
Depends on:
Blocks: 163675
  Show dependency treegraph
 
Reported: 2010-03-20 19:08 UTC by _ tboudreau
Modified: 2013-05-30 14:03 UTC (History)
6 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Patch adding TreeView.editNode(Node) (8.70 KB, patch)
2010-03-20 19:19 UTC, _ tboudreau
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.


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