Bugzilla – Full Text Bug Listing
| Summary: | [client] Clean up client-facing URL's | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Project Inbox <orion.client-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | mamacdon, simon_kaegi |
| Version: | 0.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Susan McCourt
This seems like the right bug for continuing the discussion about use of hash bang and our overall client/server split.
It's bothered me that in the editor we use the hash to get the most important content. I realize an ajax app is necessarily going to GET all kinds of info, but when it's the central data that it's getting, that feels weird to me.
Now, if we were to fetch only the visible part of the data (vs. the whole file) that would feel better.
The situation feels worse to me now that we're generating so much of the chrome content (banners, commands, footers) in JS. Given our current architecture, the only way I could share the banner code without copying it around or doing another GET for it was sticking HTML banner fragments in the JS!
So in our current state, we are downloading mostly javascript and a skeletal DOM, and then generating both chrome and content in JS.
After reading this lengthy but very thorough analysis of the hash bang situation, I find myself nodding my head to the guidelines proposed and in particular to this comment from Brian Gallagher
http://www.jenitennison.com/blog/node/154#comment-10620
I'm repeating the most important part of it here:
<brian>
From a user-experience, content-oriented framework, this entire architecture should be reversed. The URI should point to the content, not the presentation as it does with hashbang. The content should be served first, in a readable format, and then the JavaScript magic should kick in, download all the chrome in the background and then update the page once with all the other elements.
If you’re going to have your page do a secondary load anyway (as hashbang does now) you might as well make the content the front-and-center part.
</brian>
This would mean the server had to be smart enough to look for a resource in the server workspace and then serve up an HTML representation the javascript needed to turn it into a "task." With js turned off (I realize we don't have to care about that user group) you'd still see the code.
Then the JS could GET the html fragments for the chrome, install the editor, etc.
The hashes would still navigate things like line numbers, or search tokens, etc.
To be specific... http://localhost:8080/coding.html#/file/D/static/js/favorites.js?line=69 becomes http://localhost:8080/file/D/static/js/favorites.js?task=edit#!line=69 http://localhost:8080/navigate-table.html#/file/D/static/?depth=1 becomes http://localhost:8080/file/D/static?task=navigate&depth=1 http://localhost:8080/git-status.html#http://localhost:8080/git/status/file/D becomes http://localhost:8080/git/status/file/D?task=edit http://localhost:8080/searchResults.html#/search?q=BorderContainer becomes http://localhost:8080/search?q=BorderContainer&task=view I know there are pros and cons to both ways, and we may have different approaches for different tasks. For cases like the navigator where you stay on the same page a lot, changing small bits of data, you would probably rather keep it the way it is, so that you keep all your js around and just fetch the part you need. But for cases where we expect the user to work mostly with the same data on a page, like the editor, this seems more intuitive to me. If we expected users to keep reloading the same editor with different files, then again, maybe not a good idea. The problem I see with this approach is that (architecturally) we do not control the resource. e.g. how do I edit my external dropbox/webdav (etc.) resources Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html |