Monday, October 22, 2012

AppCache Stuff from Elsewhere on the Site

‹prev | My Chain | next›

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