| 2012-11-14 21:32:30 |
Gary Poster |
description |
The Makefile should have a target to build a static, production-ready file deployment.
Planned approach follows, as discussed with Kapil, Thiago, Brad, and Benji. Some details have been discussed with only some, and discussion is welcome.
A new "build" target makes a build directory. This directory contains an index.html and a juju-ui directory. The juju-ui directory represents an effective namespace, enabling easier integration with other web applications (such as Horizon). It contains all necessary assets to run the application.
The application can be run by simply running "python -m SimpleHTTPServer" (or "python -m SimpleHTTPServer 8888" for the currently used port) within the build directory. Any other web server can serve these files as well: the juju-ui directory and its contained assets must be served from /juju-ui, but index.html can be served from any path.
The juju-ui directory contains a config.js file. This can be modified to point to different juju connections. It also contains, in nested locations as necessary, the following:
- the sprite file,
- the aggregated and minified javascript (minus the config.js but including the compiled handlebars templates),
- the aggregated and minified css,
- the svg assets,
- the manifest.appcache, and
- the full images directory, until we've converted everything to sprites.
This list intentionally excludes the templates, as well as the original css and js files. They should not be included.
A release of the application should simply be a tarball of the build directory. The staging site should serve the build directory using Apache or SimpleHTTPServer.
Minified files should *only* be placed in the build tree, not in the development tree ("app"). The lib/server.js code should return to only being used as a developer tool (serving from app), and should no longer have a "debug" flag and should no longer serve minified files. "make server" should start this code (note that another bug will be filed separately in regards to server.js, and yet another about the app tree). The "debug" target should be removed; if desired, it can temporarily be an alias for "server," but I vote -0 on that. A new target, perhaps "make run," should depend on the "build" target and then run "python -m SimpleHTTPServer 8888" within the build directory.
The index.html ideally is identical for both the build tree and the app tree. Here's one approach that might or might not work. The sources could be as follows.
<script src="/juju-ui/app.js"></script>
<script src="/juju-ui/modules.js"></script>
<script src="/juju-ui/config.js"></script>
In the app tree, app.js would be a symlink to assets/javascripts/yui/yui/yui-debug.js, modules would be the full development version of the modules.js file, and config.js would be as is. In the build tree, app.js would be the full minified application, modules.js would be the production modules.js (only the aliases), and config.js would be unchanged.
Alternatively, modules.js could be empty in production (with the true content collapsed into app.js); or, more with more fragility, that <script> line would be removed from index.html when it is copied over. |
The Makefile should have a target to build a static, production-ready file deployment.
Planned approach follows, as discussed with Kapil, Thiago, Brad, and Benji. Some details have been discussed with only some, and discussion is welcome.
A new "build" target makes a build directory. This directory contains an index.html and a juju-ui directory. The juju-ui directory represents an effective namespace, enabling easier integration with other web applications (such as Horizon). It contains all necessary assets to run the application.
The application can be run by simply running "python -m SimpleHTTPServer" (or "python -m SimpleHTTPServer 8888" for the currently used port) within the build directory. Any other web server can serve these files as well: the juju-ui directory and its contained assets must be served from /juju-ui, but index.html can be served from any path.
The juju-ui directory contains a config.js file. This can be modified to point to different juju connections. It also contains, in nested locations as necessary, the following:
- the sprite file,
- the aggregated and minified javascript (minus the config.js but including the compiled handlebars templates),
- the aggregated and minified css,
- the svg assets,
- the manifest.appcache, and
- the full images directory, until we've converted everything to sprites.
This list intentionally excludes the templates, as well as the original css and js files. They should not be included.
A release of the application should simply be a tarball of the build directory. The staging site should serve the build directory using Apache or SimpleHTTPServer.
Minified files should *only* be placed in the build tree, not in the development tree ("app"). The lib/server.js code should return to only being used as a developer tool (serving from app), and should no longer have a "debug" flag and should no longer serve minified files. "make server" should start this code (see also bug 1078910 for suggested separate follow-on changes to the development story). The "debug" target should be removed; if desired, it can temporarily be an alias for "server," but I vote -0 on that. A new target, perhaps "make run," should depend on the "build" target and then run "python -m SimpleHTTPServer 8888" within the build directory.
The index.html ideally is identical for both the build tree and the app tree. Here's one approach that might or might not work. The sources could be as follows.
<script src="/juju-ui/app.js"></script>
<script src="/juju-ui/modules.js"></script>
<script src="/juju-ui/config.js"></script>
In the app tree, app.js would be a symlink to assets/javascripts/yui/yui/yui-debug.js, modules would be the full development version of the modules.js file, and config.js would be as is. In the build tree, app.js would be the full minified application, modules.js would be the production modules.js (only the aliases), and config.js would be unchanged.
Alternatively, modules.js could be empty in production (with the true content collapsed into app.js); or, more with more fragility, that <script> line would be removed from index.html when it is copied over. |
|
