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
stuff is where the model gets changed – or rather the “up” becomes “down” or vice versa.
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
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:
might be the angular triggered ui trick to accommodate that, by the
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
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
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
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,
field, but a different view still driven by
. 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).
Published at DZone with permission of Paul Hammant, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.