There is a request from various modules to control the appearance of dialog that
is shown when a delete action is invoked on node(s) in explorer. Modules
providing nodes shown in explorer might want to replace default confirmation
dialog containing yes/no buttons with more complex deleting logic.
One of these issues is #49517 - the semantic of delete action on EJB node is not
clear and it can mean delete the record from deployment descriptors and keep
related Java sources untouched or delete the information together with sources.
Both choices are valid so the module wants to show customized dialog before
delete that will also serve as input what should be deleted.
Proposed solution is to provide a hint from a node obtained by explorer via
Node.getValue() that will supress showing of default confirm dialog by explorer
support and nodes can do handling in their own code.
This is obviously not perfect solution. Some known drawbacks:
- Default policy for showing of confirm dialog will be ignored. (In the
particular case of EJBs we need additional input anyway.)
- More dialog can be shown for multiselection of nodes that override default
behaviour. Bad but better than limiting the module.
- Multiselection containing nodes with default behaviour and modified nodes will
show both dialog.
Created attachment 20779 [details]
patch with suggested change, apichange, documentation and test
Martin, can you confirm if it helps you?
Work fine for me.
I have just one suggestion: can you introduce String constant "customDelete"
somewhere so I can use it instead of direct usage of String value?
So far I intentionaly did not published the name of attribute - it is in arch
document only. Of course API reviewers can comment this.
I am amazed by the test and I like the whole patch. We do not know of better
solution to this need in current times.
Re. publishing customDelete - if it is only "under development" API we cannot
publish it as a field of any of org.openide.** class - that would immediatelly
make it "official" api. While I agree with the patch, I do not think the whole
solution clasifies for "official" api, it really does not support multiselection
well which would be imho one needed feature of such "official" api.
Any other opinions on this change? We need another reviewer to close this fast
I agree with Jarda. I think the patch can be integrated as it is proposed, with
stability under development.
Checking in openide/openide-spec-vers.properties;
/cvs/openide/openide-spec-vers.properties,v <-- openide-spec-vers.properties
new revision: 1.167; previous revision: 1.166
Checking in openide/api/doc/changes/apichanges.xml;
/cvs/openide/api/doc/changes/apichanges.xml,v <-- apichanges.xml
new revision: 1.235; previous revision: 1.234
Checking in openide/arch/arch-openide-explorer.xml;
/cvs/openide/arch/arch-openide-explorer.xml,v <-- arch-openide-explorer.xml
new revision: 1.20; previous revision: 1.19
Checking in openide/src/org/openide/explorer/ExplorerActions.java;
new revision: 1.66; previous revision: 1.65
Checking in openide/src/org/openide/explorer/ExplorerActionsImpl.java;
new revision: 1.8; previous revision: 1.7
Checking in openide/test/unit/src/org/openide/explorer/ExplorerActionsImplTest.java;
new revision: 1.7; previous revision: 1.6
Checking in openide/test/unit/src/org/openide/explorer/ExplorerPanelTest.java;
new revision: 1.12; previous revision: 1.11
reopening to changed 'assigned to'
closing as fixed again
*** Issue 33931 has been marked as a duplicate of this issue. ***
*** Issue 40992 has been marked as a duplicate of this issue. ***