I need to round out the application cache in my fork of Mr Doob's code editor. I have been doing all my coding in the gamingjs branch since this will be the source of the code-editor used for Gaming JavaScript. Even though the branch is named "gamingjs" and Mr Doob is not ready to accept contributions, I have done my best to keep changes that are specific to Gaming JavaScript out of this branch.
That needs to change tonight. The code-editor is an appcache application so that it can be used offline. It only make sense for a code editor to be available offline. But what about the libraries used in the book?
I have been going back and forth between referencing libraries directly on the root URL:
<body></body> <script src="http://gamingJS.com/Three.js"></script> <script src="http://gamingJS.com/Detector.js"></script> <script src="http://gamingJS.com/physi.js"></script> <script src="http://gamingJS.com/ChromeFixes.js"></script> <script> // Code goes here... </script>Or referencing them in a versioned URL-space:
<body></body> <script src="http://gamingJS.com/52/Three.js"></script> <script src="http://gamingJS.com/52/Detector.js"></script> <script src="http://gamingJS.com/52/physi.js"></script> <script src="http://gamingJS.com/52/ChromeFixes.js"></script> <script> // Code goes here... </script>Obviously the latter is the more future proof of the two. If I were making this for a "real" site, I would probably opt for it. But since this is for a book (and a kids book at that), I think that conceptual simplicity has to win.
Along those same lines, I do not think that I can bundle the 3D libraries as part of the code editor. On the Gaming JavaScript site, the code editor resides under the gamingJS.com/ice URL space. If I were to bundle the 3D libraries with the code-editor, they would end up with URLs like:
http://gamingJS.com/ice/Three.js. That would allow me to write <script> tags like:<script src="Three.js"></script>That has some appeal—especially from a simplicity standpoint. Although it is short, I think it is actually less conceptually simple. At some point in the book, I need to explain what these tags do. It's far easier to explain a URL than a relative URL.
So, after all of that, I am left with the web site proper holding the 3D libraries (
http://gamingJS.com/Three.js) and the embedded code-editor referencing them in the appcache manifest, editor.appchache:CACHE MANIFEST # 2012-10-22 CACHE: /favicon.ico /Three.js /Tween.js /Detector.js /physi.js /ChromeFixes.js /ammo.js /physijs_worker.js editor.css files/inconsolata.woff js/editor.js js/appcache.js js/rawdeflate.js js/rawinflate.js js/ace/mode-css.js js/ace/ace.js js/ace/theme-chrome.js js/ace/mode-html.js js/ace/worker-javascript.js js/ace/keybinding-emacs.js js/ace/mode-javascript.js NETWORK: *It is a pretty severe drawback to this approach that I will need to update the manifest in the code editor repository every time I want to update the JavaScript libraries in the host site. Given all the considerations, I see no better option.
Once I push that out to gamingJS.com, I see the manifest pull in everything—even the libraries from the URL-space above the ICE editor (gamingJS.com/ice):
And, more importantly, I can use the editor offline:
So this seems to work fairly well. Even for the stuff that would otherwise be outside of the appcache application.
Day #547
No comments:
Post a Comment