Thursday, October 4, 2012

Appcache and Local Development

‹prev | My Chain | next›

With the Three.js retrograde motion simulation (which is amazing) complete, I believe that I am feature complete for Gaming JavaScript. That is, I think that I have enough games and simulations to produce a pretty cool book. So tonight, I take a step back to focus on an equally important aspect of the book: the code editor.

I am committed to using Mr Doob's incredible code editor. It has the right combination of code editor, syntax highlighting, and immediate feedback that will be perfect for kids learning to code:


Mr Doob is completely up front that this code editor is in a proof of concept state—not nearly ready for pull requests. But I need more than a few changes for use in Gaming JavaScript. So tonight I get started with the most pressing issue: a "New" dialog. This is pressing because I've got several chapters that tell kids to open an old project, then immediately save it, to create a new project. I even have screenshots of doing silly things like this.

But of course there is a better way.

First up, I need to figure out a workflow for editing the code editor. Currently, my code editor fork is a git submodule on the Gaming JavaScript site. Further complicating things is that the code editor is an appcache application. So I need a way to develop locally and to easily see changes immediately.

I stick with a jekyll for running the Gaming JavaScript locally (it's a GitHub pages site). It seems reasonable to stick close to the production environment. To see changes immediately, I add a symlink to my local repository:
➜  gamingjs git:(gh-pages) ln -s ../code-editor ice.local
➜  gamingjs git:(gh-pages) ✗ echo ice.local >> .gitignore
I am not going to use this ice.local path anywhere else, so I dot-git-ignore it. I am going to have to remember to update my submodule reference every time I update my code-editor fork, but such is the price of submodules.

To see immediate changes, I update the index.html page of code-editor, removing the manifest attribute:
<!DOCTYPE html>
<html manifest="editor.appcache">
 <head>
  <title>code editor</title>
...
Without the manifest attribute, I am just loading a normal page without have to worry about expiring the appcache:
<!DOCTYPE html>
<html>
 <head>
  <title>code editor</title>
...
I am going to have to make darn sure that I never commit changes to that index.html file that include the removal of that attribute, but I think I can do that.

With that, I am ready to start editing the code editor (that's going to be fun to say). I have most of the editing code in the editor.js file. To add a "New" menu option, I add a function to projectMenu():
var projectMenu = function() {
  menu(
    menuNew(),
    menuOpen(),
    menuSave(),
    menuShare(),
    menuDownload(),
    menuInfo()
  );
};
Where menuNew() is similar to the other menu functions, changed only for the label and the function that opens the corresponding dialog:
var menuNew = function() {
  var el = document.createElement( 'li' );
  el.textContent = 'new';
  el.addEventListener( 'click', function ( event ) {

    openNewDialog();

  }, false );
  return el;
};
It is certainly an interesting challenge doing this without jQuery.

Anyhow, I reload the page to find... a file not found. Ugh.

It seems that jekyll does not care for symbolic links. When it regenerates the site, it ignores symlinks (even if they are explicitly listed in the include directive of the configuration). If I manually restore that symlink, I can reload and see my "New" menu item:


It does not seem as though using a symlink to local development code is going to work. I will have to rethink this, but my best option may be to drop jekyll for local development and instead switch to a simple express.js server directly in the code-editor repository. I could still use jekyll for smoke tests -- especially right before I update the editor on Gaming JavaScript.

Day #528

No comments:

Post a Comment