Community
Participate
Working Groups
We need a command service and way to contribute implementations for different scopes. - command/object contributions - need to express that a command applies only to folders, or only to links of a certain type, etc. - when is the expression reevaluated? For menus only when the menu opens - evaluate against the selection - selection service - note that "selection" may really mean the hovered item in the case of a local actions menu on hover. - for bulk actions it's a more typical widget selection. There is a little bit of this released in 0.2M4-201012101722 - "Make Favorite" and "Delete" are now contributed in glue code as commands. - The table has the service render the command and provides a handler. - commands can have scopes - "global," "page," "dom," "object" - in the latter case, the command's visibleWhen function must be evaluated against the object in question. If the client code doesn't pass an object/objects in as the item in question, then the selection service is contacted. Right now only "object" scope and supplied item are being exercised. Things I don't like: - right now there is a callback supplied in the command and then a handler supplied by the client. I don't think either of these is really correct. The client is the one who can figure out what "items" the command applies to, but it seems like the implementation of the handler should be able to be done outside of the client. I expect the right answer to become clear when we get to the point where we want the tree and table to share commands. At that point, each nav will have its own way of ascertaining what "items" are involved, but we would hope the implementation of what to do with those items could be shared. So next steps are: - get the other commands in the nav-table rendered in terms of commands (this will push on the visibleWhen logic since we have different commands depending on what level you are at in the breadcrumb) - try to factor out the common parts among the navigators - implement a "menu" command render style Note that part of getting consistent rendering for commands is having the same thing be used for "button" style commands. We currently use dojo buttons up top, images in the nav bar, etc. Let's settle on one presentation and CSS class for these things, and we have to consider the case where we have just text and no icon.
The wiki is fairly up to date on the current direction here. http://wiki.eclipse.org/Orion/EAS/CommandService
in bug 334720, I added a link so you could download a folder as a zip file. I wasn't able to use the command._asLink(...) stuff because that assumes a callback to perform the action. The original idea of a link command was that it looks like a link, but it's not really. But now we have a use case (and I expect should have many more) for links that are true links, with locations. In this case, the client needs to be involved to ascertain the URL from the selected items. But the end result should be a proper href put in the anchor rather than calling back on click.
(In reply to comment #0) > Things I don't like: > - right now there is a callback supplied in the command and then a handler > supplied by the client. I don't think either of these is really correct. The > client is the one who can figure out what "items" the command applies to, but > it seems like the implementation of the handler should be able to be done > outside of the client. I expect the right answer to become clear when we get > to the point where we want the tree and table to share commands. At that > point, each nav will have its own way of ascertaining what "items" are > involved, but we would hope the implementation of what to do with those items > could be shared. Another example that can help push on this problem is Boris' new editor actions. Exactly the opposite from above, where the "what" (editor text) that is being operated on is the same, but what to do with the text will be different.
(In reply to comment #0) > Note that part of getting consistent rendering for commands is having the same > thing be used for "button" style commands. We currently use dojo buttons up > top, images in the nav bar, etc. Let's settle on one presentation and CSS > class for these things, and we have to consider the case where we have just > text and no icon. If we use dojo buttons without a background, we get a pretty clean look, and then we get whatever stylistic hover the theme defines. This may be the approach we want to take rather than images where we are coding the hover behavior ourselves. For M5, we do this for the top toolbar buttons, which now look a lot more like the image links below. But when there is no image supplied, I think we should just do a span with a text node that uses the underline (commandLink) CSS class. But if it's truly a link to a URL, then we would use an anchor and the same commandLink class, but it would have an href.
committed a change to: - render images using opacity so that we don't need a regular and hot image - convert the images created by favorites to commands
In the latest commit: - ALL navtable commands, dom and object scope, are rendered by the command service. - commands that will be common to the tree view (basic file manipulation commands) are moved into a separate file so that they can be shared by the tree view - you can now create files, folders, or import from folders in the list as well as the breadcrumb level. The presentation is ugly (a huge row of icons) but grouping will come next.
What should happen next: + need to render the separators for "image" style + need to start on the "menu" style of commands. ++ for popups, we generate separators based on group id as we do for images ++ for menu buttons, have to figure out how the label for the menu button and the labels for groups is determined + move tree view commands to the command service ++ things in the global toolbar move to a breadcrumb toolbar similar to nav-table ++ popups generated as object contributions + move editor commands to command service + remove glue code that installs editor actions from plugins and have the command service figure this out. This means that the command service could be told what extensions it should look in.
(In reply to comment #7) > What should happen next: TODO> + need to render the separators for "image" style done > + need to start on the "menu" style of commands. done > ++ for popups, we generate separators based on group id as we do for images done > ++ for menu buttons, have to figure out how the label for the menu button done > + move tree view commands to the command service done > ++ things in the global toolbar move to a breadcrumb toolbar similar... done > ++ popups generated as object contributions TODO> + move editor commands to command service TODO> + remove glue code that installs editor actions from plugins and have the > command service figure this out. This means that the command service could be > told what extensions it should look in.
committed changes to: - handle nested groups and drop down menus within image/tool bars - ensure no unnecessary separators are rendered - separate the addition/definition of commands from the definition of their contribution and nesting - allow named groups to be scoped by domId, so that something could be named in one place (such as the object menus) and unnamed elsewhere (tools in the nav bar).
- moved the editor toolbar buttons into the command service - moved the plugin editor actions into the command service - the glue code no longer does the registry traversal, this is now done by the code that generates all interesting editor commands Since the basics of toolbars with nested menus/links and menus with submenus are now implemented, with navigators sharing commands, editor commands using keybindings, etc...I think we can consider this bug fixed. There is remaining work to do to pull the internally defined editor keybindings out of editorContainer but I think this work is more relevant to bug 337647 and I'll continue the work there. Additional enhancements and fixes to the command service should continue in specific bugs. marking fixed.
