Client-Side-MVC applications : Best Practice
Join the DZone community and get the full member experience.
Join For Free
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
Published at DZone with permission of Paul Hammant, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments