Bugzilla – Full Text Bug Listing
| Summary: | Implementing templates with Orion | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Nathan Gervais <nathan> |
| Component: | Client | Assignee: | Project Inbox <orion.client-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | antonm, eclipse, ken_walker, libingw, Mike_Wilson, simon_kaegi, susan |
| Version: | 0.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 395402 | ||
| Bug Blocks: | |||
|
Description
Nathan Gervais
I think we have a more general architectural issue in Orion with respect to server-side generation of pages vs. static content. Until/unless we change our approach, a good first step here would be to get more structured in our CSS/HTML so that someone can more easily change the theme today. The issues I see are: - we have a hodgepodge of CSS in ide.css, some styling is broken out into separate pages, but it's not organized. - much of our theming (light blue looking dialogs, etc.) currently comes from the dojo soria theme that's in place. Some of our styling intentionally overrides soria. We need to back up and decide how dojo theming fits in. How much dojo theming has to be done by someone deploying an Orion site who wants a different look. I'd like to start tackling this in M6 along with some visual reorg work (bug 334191). Nathan, do you have cycles to help on this? I'm planning to do work in M6 on declaration of commands, automated rendering of commands, cleanup of duplication, as well as looking at the primary navigation, etc. Part of this will be some cleanup of style sheets, but it would be really helpful to have someone else trying out different styles, pointing out where we need more CSS classes defined, where we make it difficult, how dojo themes fit in, etc. Sounds like a great place to start. Count me in. Please count me in for any further discusion. https://bugs.eclipse.org/bugs/show_bug.cgi?id=335888 will depend on this. (In reply to comment #1) > I think we have a more general architectural issue in Orion with respect to > server-side generation of pages vs. static content. > > Until/unless we change our approach, a good first step here would be to get > more structured in our CSS/HTML so that someone can more easily change the > theme today. Sounds like a great thing to look at for M6. I've been wondering if using something like http://lesscss.org might be helpful to give us a little more lifting power. LessCSS looks interesting I'll have to take a closer look. Cleaning up the CSS and classes in the HTML will help in terms of exposing the right places to modify for a themer, the elephant in the room here is still having the same code in multiple files. Is the goal to provide themers the ability to the layout of pages (HTML) or the ability to change the presentation of those pages (CSS), or is it both? (In reply to comment #1) >I think we have a more general architectural issue in Orion with respect to >server-side generation of pages vs. static content. > > Until/unless we change our approach... How can we spur more discussion on this issue? Since the server could be built in any language, are we hesitating to pick a solution for fear of compatibility issue(s)? Is there a backstory that i've missed somewhere? (In reply to comment #5) > LessCSS looks interesting I'll have to take a closer look. > > Cleaning up the CSS and classes in the HTML will help in terms of exposing the > right places to modify for a themer, the elephant in the room here is still > having the same code in multiple files. That is just an artifact of a lot of hodge-podge development. For M6 I plan to clean up the UI, both from a code duplication point of view, as well as simply going about the layout in a more methodical way (we've just kind of been hacking features in as we go). This also intersects with work going on in the command framework and rendering (since that will control look and placement of global and page-scoped actions). > > Is the goal to provide themers the ability to the layout of pages (HTML) or the > ability to change the presentation of those pages (CSS), or is it both? Initially (M6) I'd like to clean up the layout to something we like and make sure it's easy to change the CSS. Long term, we have a goal of letting end users change the layout of some things (such as adding views, etc). Having themers do it is something in between those two goals. I'd like to drive that by doing step 1, working with you on that, and see where it leads us. > > (In reply to comment #1) > >I think we have a more general architectural issue in Orion with respect to > >server-side generation of pages vs. static content. > > > > Until/unless we change our approach... > > How can we spur more discussion on this issue? Since the server could be built > in any language, are we hesitating to pick a solution for fear of compatibility > issue(s)? > > Is there a backstory that i've missed somewhere? There was some discussion on this a few months ago but I'd say the main reason that we aren't talking more about server side generation of pages is because we are still working out the use cases/functionality/scoping of the incubating release and it's just not clear yet how important it might be. This might be a good topic for the Orion summit. I've done what I wanted to do for M6 in this bug, which includes: - generate the banner in one place. My approach is "poor man's client-side templating." See globalCommands.js. We now just define a content pane for the banner and this code handles the rest with a common template and command generation into the toolbar. So now, all pages will have a common banner and commands appropriate for their page, and we can tweak the styling and layout of the banner in one spot. - I've done *some* cleanup of CSS but not a lot. Nathan was going to attempt to reskin Orion and I'd like to get his feedback about the organization here. Would it help to break up the CSS? rename some CSS classes? etc. - We could do the same "poor man's client-side templating" for the bottom area if we wish, so that any warning banners, etc. would only need to go into the template. - There remains the larger question of our HTML page structure, how smart the server could be in generating the pages vs. us copying these templates around, etc. This also affects our URL's, etc. Bigger architectural issues that won't change for M6. Nathan, please ping me if you need help from me in trying to skin the pages... I think we've done a decent job of using text!... type templates in 0.2. What I'd like to see now is if we can find a way to inline content in the html file as part of a build step so that we have something useful to display at the domcontentloaded event instead of having to wait to display stuff later. (In reply to comment #8) > I think we've done a decent job of using text!... type templates in 0.2. What > I'd like to see now is if we can find a way to inline content in the html file > as part of a build step so that we have something useful to display at the > domcontentloaded event instead of having to wait to display stuff later. I'd like to run some experiments along this line for our RC1 performance pass. What I'd like to do: - put the static banner and footer content into the page HTML. - turn dojo parse on load back on Ideally we'd see the page banner immediately and content would render in. We turned parse on load long ago because the page assembly was so jumpy, but if the main pieces are in the HTML then we could get a better result. If this makes a significant difference, then we could look at generating the header/footer into the HTML at build time. (In reply to comment #9) > I'd like to run some experiments along this line for our RC1 performance pass. > What I'd like to do: > - put the static banner and footer content into the page HTML. > - turn dojo parse on load back on > > Ideally we'd see the page banner immediately and content would render in. We > turned parse on load long ago because the page assembly was so jumpy, but if > the main pieces are in the HTML then we could get a better result. > > If this makes a significant difference, then we could look at generating the > header/footer into the HTML at build time. So here's the difference that I see: Without embedded header...you get 3-4 white page-itis and then the page fills in. With experiments for embedded header/footer...you get a header right away (without breadcrumb or links or interesting content) and then you wait that same amount of time as before. I changed only the navigator to embed the HTML header, parse on load, and show the page as it renders. I also added some instrumentation hooks to print elapsed time from page load to bootstrap to UI rendering. The numbers for a self hosting page show that bootstrap and UI population are inconsequential compared to just getting the page downloaded, but of course this is measuring the non-built pages, so the numbers are not realistic. Simon didn't want these changes in the nightly build, so I'm releasing now (after). I'd like us to compare the rendering effect of nav (instant) vs. white page, as well as look at the timing hooks in a built navigator. The early rendering is a slight win on a built site the first time you touch the page, less exciting after that. Talked to Simon and for now we'll leave the embedded header/live rendering on in navigator because it serves as a good comparison on the other pages. In 1.0, we have to look at building more content into the initial HTML and not relying on so much JS to build the part of the page that is not dependent on the page metadata and services. We removed the special case navigator code that embedded the banner directly in the page because: 1) hard to maintain 2) it was causing double paints when the user themed orion. You'd see the banner paint in the default theme followed by painting again in the chosen theme. The theme support relies on generating the banner after the theme is installed. Removing milestone as we aren't going to be changing our approach for 1.0. We think we have a solution for client-side templates that follow the require js module structure. It's described in bug 395402. This would allow us, for example, to describe the banner in a single HTML file and refer to it in the javascript code that adds the dynamic behavior. We could decide at build time to inline the HTML into the pages much the way we follow other dependencies and build into the page. I'm going to mark this bug M2. The goal would be that instead of our "poor man's javascript templating" (now done in commonHTMLFragments.js) we would instead have banner.html footer.html toolbar.html etc.... I did some cleanup of the header/footer to use data binding for NLS strings. This at least cleaned up the look of the js strings. As part of bug 393815 we are using this same technique in our dialogs. I don't imagine doing any better for 2.0. 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 |