Hmm, the mole image has some lasso artifacts after I reappropriated it from wikipedia. Damn you CorelPaint!

Now, look at the source (it’s in an iframe so you’ll see the minimum amount of HTML). Of if you trust me not to do some sleight of hand, you can look at the github source for that

Aside from the 2 × 2 JSON “moles” document with a not-so-random “up” versus “down” state, the angular magic is:

The thing I want folks to really grok right now, is that there are two images in the source apparently side by side within each of the TD elements. Specifically “mole up” and “mole down”. It is Angular that’s making one one of the two show at any one moment in time. Gecko and Webkit are fast enough to not make it apparent that there is momentarily two or none of the images visible for a cell. Perhaps Angular has no such tweening state, and is even in charge of the browser repaints. The ng:click stuff is where the model gets changed – or rather the “up” becomes “down” or vice versa. ng:click is attachable to any meaningful element of course.

Here is what the source looks like in DreamWeaver’s WYSIWYG mode for the single apparent cell before Angular re-does the DOM:

Yes that’s the mole both apparently alive and dead at the same time.

Here’s an alternate way of doing the same thing without the two image and ng:show & ng:hide trick, that I would count as a refactoring:

Whichever way you do it, the model drives the view (no JavaScript to shuttle back and forth values). And the view mutates the model – in this case via expressions co-located with HTML. The Angular guys suggest that these things are better done with real JavaScript functions that can touch the model, and they are right as far as testability is concerned. But there’s a preotyping community that’s really going to dig Angular. There’s also a the likes of User Experience (UX) and Business Analysts folks who may like to join in somewhat in the actual development of functionality.

It is interesting too, what Angular does to the DOM at runtime. Below is a screen-shot from Firebug. The ghosted lines are not visible in the browser frame. Thus it’s conformation (if you needed it) that only one image is visible at a time for one cell:

Business apps

You’re going to be able to compose larger applications fairly easily, and leverage plenty of model following UI changing activities. You’re principal duty is to keep the model supporting the view, and refactoring as appropriate to fit the growing vision. The hard stuff, you will still do in JavaScript, but I think that’s the exception rather than the rule, as the Angular makes it all pretty easy.

Consider a table of fruit in a page:

If clicked, a line could expand a little to accommodate more text:

HTML’s rowspan might be the Angular triggered UI trick to accommodate that, by the ng:click would trigger an 'expanded = true' model change for the fruit in question. As retrieved from the database the fruit never had a 'expanded = false' node, let alone 'expanded = true', but that does not matter as in the worse case scenario, your could ignore such properties when attempting to write the fruits back to the database (if they were editable in-situ). Your original JSON document to support the list of fruit might only have enough text to support the collapsed list of fruit. If that’s the case, you’d do an AJAX wire call to get the expanded fruit description, and populate an ‘expandedFruit’ object outside the ‘fruits’ model. Only one fruit is expanded at a time, so it could easily be a single field. Judicious use of ng:show again will make the right control of two show within the <td> .. </td> elements.

Or some form of overlay could happen:

The same backend model, AJAX fetch, and expandedText field, but a different view still driven by ng:show. You could refactor from one design to the other. Indeed the UX person could do so without developer help.

All of a sudden, web apps became simpler to make (again).

s