Paul Hammant's Blog: Client-Side-MVC applications : best practice (part 1)
I’ve made a quick game - “Whack a Mole - Angular Edition”. Try clicking on the moles or holes:
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 x 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:hide trick, that I would count as a refactoring:
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:
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).
Apr 17, 2012: This article was syndicated by DZone
blog comments powered by Disqus