You need to log in before you can comment on or make changes to this bug.
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.
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 :-).
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.
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.
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.
"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.
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?
Re. issue #35827 being considered a bug - fine with me, if it helps get it fixed finally.
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>
You forgot to add an apichanges.xml entry. I will do it.
