> I think your comments were primarily targeted at his experiments with the > navigation, right? Or maybe it was both the navigation and the restyling of > the tables?
Right, my response was only about the "promotion" of some items that are always shown to the top bar, not about the client-side list view improvements. While we already have sorting, filtering might be really interesting if it performs well. I really only responded to the following: > [Gus Reiber:] As a possible remedy to that bit of awkwardness, I am looking > at pulling some of the 'action' link list items out and displaying them in a > global toolbar sort of context. Jenkins Management, in particular seems like > it really should be clearly separated as a global set of actions, and not > bound to any particular build or custom view. It also seems I misunderstood that part quite badly, I can no longer find where Gus wrote that the new "prominent items bar" should always contain the same items! > I wonder would it make sense to take a step back and draw a map of the > current navigation and how it changes depending on where you are in Jenkins? > Armed with that, then maybe we can make some proposals? Navigation is essentially the breadcrumbs bar and the sidepanel. The problem in understanding them probably results from how complex it is: Jelly allows including other Jelly fragments, Stapler decides what get loaded at all, Jenkins behaves as if some items are implied (the default view), and by overriding a Java class you can also override resources. Some resources: * http://stapler.kohsuke.org/what-is.html * http://stapler.kohsuke.org/reference.html Breadcrumbs are created by iterating over the items shown in the URL. If it's not in there, it's missing (except if on a config page, that can also show up there with its sections). Depending on which interfaces the items implement, you get a context menu (down arrow) and/or a children menu (right arrow). The sidepanel is entirely provided by the currently active item: * On the home page, it's the "Jenkins" object. * In a folder, it's the folder. * In a view, it's the view. * In a job, it's the job. * Other special pages, like plugin manager or security configuration, provide their own sidepanel. However, these implementations can reference other objects that may or may not show up in the URL, have optional items, etc. As an example, this is how the home page's sidepanel is built (# indicates a Jelly file being read, - an item created, * another remark) to give you an introduction in both reading these files, as well as what's involved in building the sidepanel for the home page: # core/src/main/resources/jenkins/model/Jenkins/sidepanel.jelly: * Jenkins just forwards to its primary view in determining the items to be shown # core/src/main/resources/jenkins/model/View/sidepanel.jelly: # Optional: Owner's tasks-top.jelly: If the view's owner/parent has a fragment for tasks to show at the top, include it. Not in the case of Jenkins. # Optional: Owner's tasks-new.jelly: Show the fragment of the 'owner' that shows the 'New Item' link. The included file can also be empty, removing the link. - If there's no such fragment provided by the owner, show the default 'New Item' link. Backwards compatibility if I had to guess. - Create the 'People' link (URL depending on whether it's the 'All' view or not: If it's not, add the view to the URL, resulting in .../view/Foo/asynchPeople). - 'Build History' link. * If the view is editable (the default 'All' view is not, but another view can be selected to be default): - Show 'Edit View' * Can the view be deleted (the default view cannot, but others usually can be unless the view's owner has some code that prevents it)? - If so, show 'Delete View' * Are there fingerprints recorded by Jenkins? If so: - Show 'Project Relationship' - Show 'Check File Fingerprint' # Optional subtype's sidepanel2.jelly: Subtypes of 'View' can provide additional items here without having to override this entire sidepanel.jelly they'd otherwise inherit. This is a bit like the strategy pattern if you know that from Java. - If you use Nested Views ("TreeView" in the code), this is where 'New View' is added. # core/src/main/resources/lib/hudson/actions.jelly: Display any actions associated with the current view * The view gets asked for actions to be displayed, and gathers actions to be shown in a view from its owner (jenkins.model.Jenkins#getViewActions()) and adds its own (hudson.model.View#getActions()). This is where plugins can just add arbitrary stuff by e.g. extending TransientViewActionFactory - If the action defines an icon, icon and display name are shown and link to the action's URL. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
