spade 0.1.0 → 0.1.1.1

data/examples/todos/resources/templates/todos.handlebars

@@ -1,31 +0,0 @@
-<h1>Todos</h1>
-
-{{#view "Todos.CreateTodoView"}}
-  <input id="new-todo" type="text" placeholder="Wot?" >
-{{/view}}
-
-{{#view "Todos.statsView"}}
-  <div class="remaining">
-    {{#view "Todos.clearCompletedView"}}
-      <button>Clear Completed Todos</button>
-    {{/view}}
-    {{bind "displayRemaining"}} remaining.
-  </div>
-{{/view}}
-
-{{#view "Todos.markAllDoneView"}}
-  <label class='done-label'>
-    <input class="mark-all-done" type="checkbox"> Mark All as Done
-  </label>
-{{/view}}
-
-{{#collection "Todos.todoListView"}}
-  <label class='done'>
-    {{#view "Todos.CheckboxView"}}
-      <input class="check" type="checkbox">
-    {{/view}}
-    <div class="todo-content">{{content/title}}</div>
-  </label>
-{{/collection}}
-
-

data/examples/web-app/README.md

@@ -1,83 +0,0 @@
-This is a simple demo web app the shows how to use spade in web pages and 
-unit testing from CLI and web.
-
-# Quick Start
-
-_**Note:** these instructions assume you have not added any of the spade or 
-core-test bins to your path.  If you have then you can just use the spade or 
-cot commands directly._
-
-To test the web app, first you need to run spade-update to do one-time setup.
-This will link up all the necessary packages and create a spade-boot.js which
-is needed by the app to load:
-
-    ../../bin/spade update
-
-Anytime you add a new package dependency to the web app, you will need to run
-this command again for it to load in the browser.
-    
-To view the web app, you need to load your files through a server.
-This will get around some security restrictions on the file:// protocol in
-Chrome and Webkit.  You could technically use any web server you like.  
-However, spade comes with a simple one built in for quick testing.  To start
-the server:
-
-    ../../bin/spade preview
-    
-Now you can view the web app by visiting [http://localhost:4020/index.html]
-in your web browser.
-
-# Running Unit Tests
-
-You can run the unit tests from the command line using the core-test cot 
-command:
-
-    ../../packages/core-test/bin/cot
-    
-If you want to see detailed reports use the --verbose flag:
-
-    ../../packages/core-test/bin/cot --verbose
-    
-You can also run specific unit tests:
-
-    ../../packages/core-test/bin/cot ./tests/qunit-example-test.js
-    
-To run unit tests in the browser, you will need to first run a one-time setup 
-with core-test:
-
-    ../../packages/core-test/bin/cot update
-    
-This will create a file called tests/ct-runner.js that is used to bootstrap 
-the tests in the browser.  Anytime you add a new unit test file you need to
-run this command again.
-
-To view in the browser, you will need a web server again.  spade preview is 
-the easiest way to do this:
-
-    ../../bin/spade preview
-    
-Now you can load the tests by visiting [http://localhost:4020/tests.html]
-
-Note that the unit tests included in this demo use different personalities 
-on CoreTest.  This shows how you can use CoreTest to mix and match your 
-outputs.
-
-# Additional Notes
-
-In general, spade leaves it up to you to create your own HTML files for web-
-based projects.  The only requirement is that you need to load the spade-boot
-script at the top of the file.  You should also include a data-require 
-attribute which names the initial module you want to load when the HTML page
-is finished loading.
-
-For regular web apps, this is usually the default index module for the app
-itself.  For testing, you would instead load the ~tests/ct-runner module.  In
-both cases your app itself loads which means all the assets you care about are
-present.
-
-For unit testing, note that normally only files ending in '-test' or '-spec'
-or '\_test' or '\_spec' are automatically run.  To run all files in the tests
-directory use the --all option on cot.
-
-Finally, note that current core-test does not know how to load its own 
-stylesheets.  This means the tests will load unstyled.

data/examples/web-app/index.html

@@ -1,12 +0,0 @@
-<!DOCYTYPE HTML>
-<html>
-  <head>
-    <title>Demo App</title>
-    <script src="spade-boot.js" data-require="web-app"></script>
-  </head>
-  <body>
-    <h1>Loading...</h1>
-  </body>
-</html>
-
-

data/examples/web-app/lib/main.js

@@ -1,3 +0,0 @@
-require('jquery');
-$('h1').text('Hello Spade!');
-

data/examples/web-app/package.json

@@ -1,6 +0,0 @@
-{
-  "name": "web-app",
-  "dependencies": { 
-    "jquery": "1.4.3"
-  }
-}

data/examples/web-app/tests.html

@@ -1,12 +0,0 @@
-<!DOCYTYPE HTML>
-<html>
-  <head>
-    <title>Demo App</title>
-    <script src="spade-boot.js" data-require="web-app/~tests/ct-runner"></script>
-  </head>
-  <body>
-    <h1>Test Runner</h1>
-  </body>
-</html>
-
-

data/examples/web-app/tests/ct-example-test.js

@@ -1,39 +0,0 @@
-/*
-    This is an example of the same unit test written using the native CoreTest
-    API.  The big benefit of the native CoreTest API is that it is fully 
-    async so it is easy to test event driven code with it.  
-    
-    For a sync version of this same API (does not require invoking a callback
-    when )
-*/
-/*globals Ct */
-
-require('core-test');
-
-Ct.module('Qunit Example');
-
-// NOTE:  T is the test instance.  A new one is passed for each test which is
-// good since previous tests could impact future ones when running async
-Ct.setup(function(T, done) {
-  T.foo = 'foo';
-  done();
-});
-  
-Ct.teardown(function(T, done) {
-  T.foo = 'unfoo';
-  done();
-});
-
-Ct.test('T.foo should be foo', function(T, done) {
-  T.equal(T.foo, 'foo', 'T.foo should be set');
-  done();
-});
-
-Ct.test('async example', function(T, done) {
-  setTimeout(function() {
-    T.ok(true, 'async test did fire');
-    done(); // invoke when you are finished running this test
-  }, 100);
-});
-
-Ct.run();

data/examples/web-app/tests/qunit-test.js

@@ -1,23 +0,0 @@
-/*
-  This is an example of a unit test using the CoreTest Qunit personality. To
-  convert an existing Qunit test just add the core-test require to the top of 
-  the file.  
-*/
-
-require('core-test/qunit');
-
-var T = {};
-
-module('Qunit Example', {
-  setup: function() {
-    T.foo = 'foo';
-  },
-  
-  teardown: function() {
-    T.foo = 'unfoo';
-  }
-});
-
-test('T.foo should be foo', function() {
-  equals(T.foo, 'foo', 'T.foo should be set');
-});