Bugzilla – Full Text Bug Listing
| Summary: | [client] Semantic definition of page title and current location | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Szymon Brandys <Szymon.Brandys> | ||||||
| Component: | Client | Assignee: | Susan McCourt <susan> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | antonm, ken_walker, libingw, malgorzata.tomczyk, simon_kaegi, susan | ||||||
| Version: | 0.2 | ||||||||
| Target Milestone: | 0.5 RC1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | 380434 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Szymon Brandys
Created attachment 198070 [details]
Header on Navigator
Created attachment 198072 [details]
Header on Installed Plug-ins
this is a side effect of their being no "location" to report in those pages. Note that the page title also appears further down. We definitely *do not* want to start managing pixel heights in the header or we'll start to affect the free wrapping of long names, etc., that we get from the browser, which we've finally gotten to where we like it. The only reliable thing I could think of to fix this would be to have the glue code of each of those pages install an invisible (background color) "location" in order to force the header layout to be the same. Linda and I looked at this yesterday. We talked about doing such in the common header code, but that would mean we'd have to make sure any other page inserting a location would be replacing content vs. adding content, and that seems risky, and could cause content to unintentionally shift right. talked to Boris. Not for 0.2.
Post 0.2 I think we should do the following:
- have semantic utility methods for pages to use when setting their location and their title. Rather than have them creating breadcrumbs and knowing those dom locations directly, they could just use the methods. Then we can do whatever secret magic is needed to stuff in invisible content to clean up the layout. For example:
setPageTitle("Git Status");
setResource(aResourceItem); --> creates the breadcrumb
setLocation(string); --> sets location (without breadcrumb)
etc....
Renaming bug to focus on the semantic part. We want to have pages say what their title and current location are, and have the rendering of that (title, breadcrumb, etc.) be handled commonly across them. See bug 359277. Along with having a location, we may want to have a menu that lets you go to other pages/tasks associated with that location. this won't happen for 0.4 even though the pieces are there. What we want to do is bring together in one place: - setting page target (setPageTarget, for related links) - setting breadcrumb - setting dimensions (branches, etc.) This would be done on the normal hash change/load processing of a page. We have most of the semantics in place for 0.4 but right now it's separate calls. So typically wherever you see breadcrumb setting, you also find setPageTarget, etc. This could be all put together in some kind of object that describes page context and the UI is handled commonly another thing that "setPageTarget" could do is help scope the search box. Then we'd have free scoping. For example, I would think on the git repo page, a search would be scoped to the selected repo. bug 370893 covers the "dimension" aspect. Git log page title.... We put a link to the repo and the branch name in the page title still. For 0.5: branch is a "dimension" and repo link in breadcrumb? Git status location Has a path looking location but you can't breadcrumb up. Consider. I don't think we are going to have time to arrive at the right answer for breadcrumb behavior given what's left for 0.5. But in this bug, we can minimally clean up all the code that sets page target to handle breadcrumb, metadata fetching, related pages, etc. in one swoop. At least then as we evolve the behavior of the breadcrumb we'll have the same place to look in the code for how it is set up. See also bug 380434. Now that page titles have been removed, there's discussion of (in some cases?) making the last segment of the breadcrumb the page title. For example, the sites page could be "sites" and the console page "console". So the promising "variables" that this API could take are
{task: "Status", location: someURL, name: fileName, relatedTarget:
someMetadata, documentTitle: "{name} - {task}"}
I'm working on this in a branch right now so we can get it in early in RC1. This is going to help in several ways: - consolidate the metadata-related banner pieces into one place - eliminate redundant/unneeded calls that are currently happening before we have metadata. For example, there is no need to render a toolbar and validate against no metadata and then render it again once you have metadata. - will make it easier to change the "basic rules" about breadcrumb and page tab content that we are trying to arrive at in bug 380434 The idea is that the page will describe its semantics and this method will use the information to build breadcrumbs, related pages, search box scoping, toolbars, etc. The simplest call (for a page without resources like Sites) would be mGlobalCommands.setPageTarget({task: "Sites"}); Then we have rules that set up the breadcrumb base, tab title, etc. For pages with metadata, it would become more complicated: mGlobalCommands.setPageTarget({task: "Pixlr Image Editing", target: myMetadata, a bunch of services.... If we address bug 337740 in the RC1 timeframe then this could become an even simpler API, right now we pass a handful of services and the registry to cover all the crazy cases discussed in bug 337740. Talked to Simon about bug 337740 and he doesn't see us tackling the service registration issues in 0.5. So this API is a bit more complex than is ideal. The API is setPageTarget documented in globalCommands. The only required thing a page should define is its "task" and that will get it the minimal breadcrumb and document title in the browser tab. Beyond that, the page can provide services, resources, etc. that will also cause the search to be scoped, or the breadcrumb to be filled in, etc. There is certainly room for improvement, but at least this takes all the manual breadcrumb manipulation and knowledge of dom id's and moves it into some common code. Fixed in http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=830c65223374c8520ca5dd767b5bd69a56cab04c |