User:Aeric/HowTo:Build a Dynamic Web App

Very much in progress

Implementing a Dynamic Web App

Introduction

In this series of step-by-step guides, you'll use cutting edge, best-of breed technologies to create a dynamic front end for an application, starting from the very basics, and working up to the cool stuff.

For the backend, you'll use the LongJump platform, taking advantage of it's capacity for Object construction, and many other features.

For the front end, you'll use:

• [... CoffeeScript] - A terrific language for programming behavior into your web page. It's Ruby without the tricky syntax bits derived from "Perl". It's the good parts of JavaScript, with none of the evil. It compiles directly into JavaScript, so it can run in any browser, and often, it can be run without compiling, which speeds up testing.
• [... Knockout.js] - A splendid GUI language that gives you a declarative syntax for specifying event-driven semantics, so components are automatically updates when the user takes an action or the underlying data changes. It lets you specify page layouts using HTML and CSS, so you can create dynamic web pages quickly and maintain them easily.
• [... jQuery] - A terrific tool for programmatically accessing and modifying the (x)HTML content of the Web Page, in the form of the Document Object Model, or DOM. It also defines the GUI components that are wired together using Knockout.js

Explore the Technologies

Going to assume familiarity with the platform. If not, start at the Welcome page to find out what it can do. Here, we'll focus on the technologies you'll be using to build the front end.

1. Play with CoffeeScript

   --countdown alerts
   --run at CoffeeScript.org
   --more stuff? (if so, introduce FiddleJS here)

1. Set up a test harness for CoffeeScript

   --I don't know about you, but for me, unit testing is a way of "playing"
  --If you're like me, you'll find yourself falling in love with Unit Testing:
   --It's a fun way to experiment with a language and try out the 
     pieces you're building
  --Perhaps more importantly, it keeps the process fun. As the
    project grows and the complexity increases, it can be hard to
    keep track of all the interactions. And those interactions create
    bugs--which generally mean that some expectation was violated,
    somewhere along the line--an incoming value or stored value
    could be different than a routine expected, or a routine could 
    do something different than the calling code expected.
 --That sort of thing happens routinely, especially in well-designed
    code. You see, if you follow the DRY principle (Don't Repeat Yourself),
    you continually refactor your code so things are only done once.
    That means a routine will be called from many different places.
    But the modification you make to a routine so it works for the things
    you're doing today could easily break a long-forgotten expectation
    for something you were working on last month--or an expectation
    you were never aware of, in code someone else wrote.
 --When it happens, you can find yourself in "debugging hell", arduously
    stepping through code trying to find out what broke, and what 
    caused it to break.
 --Without unit testing, that is. With comprehensive unit testing, 
    those expectations are recorded in the form of a "spec" -- a spec you
    can read, as well as run. That spec records expectations you've long
    forgotten, or never knew about it. When any of those expectations is
    violated, you find out about it right away. And when you do,
    you have a very simple test that tells you what the expectation
    was, and right where the violation occurred.
 --As a result, Unit Testing keeps bugs shallow. It doesn't take a
   "deep dive" to find flaws. You go straight to the issue, see the
   problem practically at a glance, and then spend your time
   designing a solution that meets all current and past expectations.  
   And you'll know right away if it does, because any solution 
   that doesn't meet all of those expectations will trip another unit test!
 --Of course, all of those benefits depend on having a unit test 
   framework that makes easy to write tests, easy to run them, 
   and easy to read them. Enter the "Behavior Driven Development",
   or BDD test harness, which has those qualities.
 --Note: BDD is a slight misnomer, in my book. I prefer the term,
    "Spec Driven Development", where the Specs are both readable
    and runnable. Because those are the characteristics that make
    the process so much fun, and so effective.  (__reference Artima blog__)
--Most of the BDD frameworks have "Spec" in their name. The
   original version was RSpec--a BDD framework for Ruby. The one
   used for CoffeeScript is called CoffeeSpec.

1. Play with jQuery

   --show header for HTML page 
   --how to find the platform version (use that version)
   --run at fiddlejs.net
   --specify fiddlejs environment (page headers)
       --Can put in snippets of HTML, CSS, and CoffeeScript 
          and run them to see the results
       --Can link to that page to share with others
       --Can save versions of the code you're working on
       --One fellow created a series of tutorials to introduce
          CoffeeScript to his co-workers, saving each step in
          the tutorial as a different revision. (We might do the same!)
  --Access the DOM and put stuff into it

1. Play with Knockout.JS

  ?--Can it be used at Fiddle.js?

Build the App

..explain the app here... --ToDo list management (original CoffeeScript example) --mention ability to access it over the phone --use an email handler to add an entry to the list

To build the App:

1. Install CoffeeScript
2. Add jQuery to your HTML
3. Install Knockout.JS
4. Layout the Page
5. Add the Interaction Semantics
6. Wire it to the Platform
7. Try it out
8. Extend it further

  --write an email handler
       --add an entry to the list
       --get a response with the current list
       --replace the list