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.
Summary: | Need a way to programmatically initiate edit in-place edit | ||
---|---|---|---|
Product: | platform | Reporter: | _ tboudreau <tboudreau> |
Component: | Explorer | Assignee: | Vladimir Voskresensky <vv159170> |
Status: | REOPENED --- | ||
Severity: | normal | CC: | apireviews, jglick, jtulach, thp, vkvashin, vv159170 |
Priority: | P2 | Keywords: | API, API_REVIEW_FAST |
Version: | 6.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 163675 | ||
Attachments: |
Patch adding TreeView.editNode(Node)
Updated patch |
Description
_ tboudreau
2010-03-20 19:08:52 UTC
Created attachment 95487 [details]
Patch adding TreeView.editNode(Node)
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? 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. Long time open API review request with no progress. Closing to raise people's attention. Legitimate use cases, Vladimir offered to integrate. 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. if there are no objections I will update apichanges.xml and integrate 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. Ok. I will prepare the updated patch. Created attachment 150492 [details]
Updated patch
JG01-JG05 fixed. Also the class "EditInitiator" has been made final. A patch is attached. |