Bug 57874 - Custom Actions for Project Nodes
Custom Actions for Project Nodes
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Generic Infrastructure
5.x
All All
: P3 (vote)
: 5.x
Assigned To: apireviews
issues@projects
: API_REVIEW_FAST
Depends on: 35827
Blocks: 57776 182488
  Show dependency treegraph
 
Reported: 2005-04-14 09:40 UTC by _ pkuzel
Modified: 2010-03-24 22:15 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2005-04-14 09:40:40 UTC
Use case:

Independent module wants to add an action directly into project node popup menu.
The action meets UI consistency criteria (external to this requirement) and it
is eligible to be placed into nodes of all project types.


Proposed solution:

Introduce well-known SFS folder (name) and suggest (a convention) all project
types to honor its content while contruction project node. Proposed folder name
is "Projects/Popup". 

The folder contains instance data objects representing SystemActions and (for
convenience and consisncy with loaders and editor) JSeparator instances.
Registered instances can be (locally) ordered to each other by FS means. Note:
global ordering in whole project node popup is the project node responsibility
and one can expect that some hints (another convention) could be developed in
future.

Note on project type implementation: folder processing code is kind of
boilerplate. One known (but heavy) solution is based on
Repository.getDefaultFileSystem() -> findResource():FileObject ->
DataObject.find():DataObject -> new FolderLookup -> allInstances().iterator().
It could be addressed in future by a support class if needed.
Comment 1 _ pkuzel 2005-04-14 10:04:10 UTC
Initial stability level: under development
Review timeframe: if no objetions instantly

Please suggest where to document the convention to be easily discoverable by:
  - project type implementors (documetation place A)
  - action providers (documentation place B)

I guess A could be equal to B and
<http://www.netbeans.org/download/dev/javadoc/ProjectUIAPI/org/netbeans/spi/project/ui/package-summary.html>

In such case there is little problem with mixing stability levels. Here I
request "under developement" level while PUIAPI has "official" level.

Hint: accepting the convetion on "official" level meets my requirements too :-).
Comment 2 _ pkuzel 2005-04-14 13:53:36 UTC
Note on actions implementation: When I was implementing action featuring popup
presenter visibility driven by actual project content (visible iff project
contains some versionable content) I have used deprecated JInlineMenu. That's
because the registration is static and it does not take any context.

I consider it low priority but if architecture team want to address it there is
still a solution: replace direct instance registrations with sort of factory
registrations. The factory interface would take addtional context to decide.
Drawback: factories would considerably complicate project types (boilerplate)
code and it introduces inconsitency with editor, tool-actions and loaders action
registrations.
Comment 3 Jesse Glick 2005-04-14 16:00:25 UTC
Uh, we already have a factory interface: ContextAwareAction. Any CAA in the
registration folder (and probably they should *all* be CAA's) and this in the
context menu will be given a Lookup - whatever the project node has. This allows
you to correctly enable/disable actions; for now please just do that (do not use
JInlineMenu!) and to be able to exclude disabled actions altogether, please take
a look at (and maybe vote for) issue #35827.

ProjectsRootNode.getActions can serve as a model for implementation.

Suggest "Projects/Actions" for consistency with "Loaders/*/*/Actions", but no
strong opinion.
Comment 4 _ pkuzel 2005-04-14 16:30:49 UTC
Jesse, thanks for your feedback!


ContextAwareAction Notes

Terminology: there is no problem with enableness but with visibility logic.

ContextAwareAction.createContextAwareInstance(Lookup actionContext) must not
return null. How could cvsmodule communicate that there is no action present for
given context? Could we redefine the CAA interface contract (to allow nulls) for
this particular convention only?

CAA convention requires contract update of registrations processing by project
types. I mean that project types must reiterate registry and recreate actions
(i.e. show/hide) on each popup construction.

Long life to simple (but claimed to be broken) JInlineMenu... :-)

Apart of above drawbacks I like CAA convention. 


Consistency Note

Projects/Actions vs. Projects/Popup = (soon to be deprecated) loaders vs. editor
consistency.
Comment 5 Jesse Glick 2005-04-14 16:46:56 UTC
"ContextAwareAction.createContextAwareInstance(Lookup actionContext) must not
return null. How could cvsmodule communicate that there is no action present for
given context?" - you can't. Hence issue #35827, q.v.

"Could we redefine the CAA interface contract (to allow nulls) for this
particular convention only?" - no.

"CAA convention requires contract update of registrations processing by project
types. I mean that project types must reiterate registry and recreate actions
(i.e. show/hide) on each popup construction." - yes of course.
Comment 6 _ pkuzel 2005-04-15 13:05:19 UTC
To conclude. No factories are necessary. Dynamic menu implementors can start 
with deprecated JInlineMenu. Once issue #35827 gets implemented actions can be 
rewritten to utilize it. 
 
The initial action instances registration proposal is OK.  
Any objections? 
 
 
 
BTW, I consider JInlineMenu deprecation that is not rewrittable a bug. 
Transitively, should not be issue #35827 marked as bug? 
Comment 7 Jesse Glick 2005-04-15 18:44:44 UTC
Re. issue #35827 being considered a bug - fine with me, if it helps get it fixed
finally.
Comment 8 _ pkuzel 2005-05-05 13:15:56 UTC
Checking in projectuiapi/arch.xml;
/cvs/projects/projectuiapi/arch.xml,v  <--  arch.xml
new revision: 1.8; previous revision: 1.7
done

Codified!

Excerpt from Project UI API Architecture document:

ProjectActions  -

Providers of generic project actions can register action and JSeparator
instances and s in a special folder Projects/Actions. So if any module wishes to
extend, hide or reorder some of them it can just register its actions there.
Revieved as issue #57874. Example code:

    <folder name="Projects" >
        <folder name="Actions" >
            <file name="org-mymodule-MyAction.instance" >
                <attr name="instanceCreate" stringvalue="org.mymodule.MyAction" />
            </file>
        </folder>
    </folder>
    
Comment 9 Jesse Glick 2005-07-21 17:46:40 UTC
You forgot to add an apichanges.xml entry. I will do it.


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