Bugzilla – Full Text Bug Listing
| Summary: | Client side includes and minification | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | John Arthorne <john.arthorne> |
| Component: | Client | Assignee: | Simon Kaegi <simon_kaegi> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | aniefer, backhous, simon_kaegi, susan |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
John Arthorne
See bug 341350 for another symptom of this problem. See also some discussion in bug 334211 comment 1. I think we should fix this for M7 in a "more real" way. (In reply to comment #0) > > - We pull out the header/footer definitions into a separate JS file, and always > exclude that file from minification This is a band-aid and still leaves us with the other problems. > - We use some other mechanism such as server side includes for this kind of > page customization. Ideally this is a server-side problem. Then things like "the foundation edits the common footer" really means editing one file which is included. The HTML fragment could bring along all the javascript needed for it to work. > - Other ideas? If we aren't ready to bite off something like server side includes, then all I can think of is putting the banner and footer in their own html files, and then doing a GET to place it into the dom. This solves the minify problem, but it still really bugs me because then it means that our static content is just a thin skeleton and we are going GETs for both the repeated content and the dynamic content. We should be able to use a variant on the RequireJS optimizer or similar build tool to some useful effect here. At dev time this would still be a client-side include but at runtime the optimizer should be able to write our html files out with headers and footers. Seems like standard fare to me. CC'ing Richard B. http://requirejs.org/docs/api.html#text This is not the complete solution but the idea here is that we can use requirejs to handle text (e.g. css, html, etc.) type dependencies. I'm a bit scared to suggest this but if we used a bit of templating... that at build time gets optimized down to in-lining (e.g. no templating in production) we might have something. here's some more thinking on this stuff - http://jquerysbestfriends.com/#slide1 Using something like the RequireJS text plugin is probably one of the better solutions. It should allow you in a dev env to have the html file be pulled in dynamically via an HTTP get and in a built version this file is inlined and wrapped with a "define" that allows modules to declare a dependency on it. Either way the resulting HTML module can be inserted into the DOM.
For example the dijit/_Templated module can use it for its template html. e.g
define([
'dojo',
'dijit/_Widget',
'dijit/_Templated',
'text!template.html',
], function (d, Widget, Templated, template) {
return d.declare([
Widget,
Templated
], {
templateString: template,
buildRendering: function () {
},
startup: function () {
}
});
});
I had been hoping that some kind soul would have done a bit more of the heavy-lifting here so that the optimizer would just write the fragment right into the html doc without having to do any work at runtime. Looking, but no luck so far... I really think there's lots of potential to do something interesting here in the optimizer for both HTML and CSS/LESS. The optimizer would have to be integrated into the server-side as part of some form of HTML generation. The RequireJS build tool provides no support here. However the work I have been doing for Zazl around AMD dynamic optimization does provide more potential. The key though I think is buying into some sort of server-side scripting or maybe a filter that scans the outgoing HTML and injects the HTML templates then. On the subject of CSS dependencies. There has been some good discussion going on on the RequireJS group concerning writing a plugin for this. Its not going to be as easy as supporting text dependencies though especially when the name "Internet Explorer" is mentioned :-) I can see benefit to doing some of the templating server-side only at dev-time but I'm having a hard time swallowing that particular pill. I'm imagining the use of this templating will be wide-spread and even though it is dev-time, I'm hoping we don't tie ourselves to anything but a fairly raw http server at this level. I'm still interested in what we could do client-side at dev-time (and optimize out at build time) ...wonder if we could do a micro client-side framework where we do the equivalent of a sync require (and sync xhr) and then document.write for the fragment to avoid having to wait for domcontentloaded before injecting the fragment and adding a new timing condition difference between dev and production. -- re:CSS at requireJS...great! I'll have a look. 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 |