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: | Custom Actions for Project Nodes | ||
---|---|---|---|
Product: | projects | Reporter: | _ pkuzel <pkuzel> |
Component: | Generic Infrastructure | Assignee: | apireviews <apireviews> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jchalupa |
Priority: | P3 | Keywords: | API_REVIEW_FAST |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | TASK | Exception Reporter: | |
Bug Depends on: | 35827 | ||
Bug Blocks: | 57776, 182488 |
Description
_ pkuzel
2005-04-14 09:40:40 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 :-). 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. |