[<<][softarch][>>][..]
Sun Sep 23 23:21:49 EDT 2018

Presentation models

So, when do these make sense?

Let's illustrate according to the task, which is to set one of a
number of words to a particular color using imperative GUI commands.


There are two approaches to this:

A. Redo:
   - reset everything to no color (loop)
   - set the element to the desired color

B. Update:
   - reset the previous element's color (needs bookkeeping!)
   - set the new element's color

The former is conceptually simpler, as it does not require keeping
track of the previous state.


This can be done by sending the appropriate commands to the GUI.

However, it is possible that the loop in A is inefficient.  If it is
not efficient, we're done.

If it is inefficient (e.g. it would require a reflow in a Browser), an
alternative approach is to model the GUI, perform the operations on
the model, and then use the difference between the previous model and
the new one to generate update commands.

This is still conceptually simple (the generation of the update
commands can be automated), but has the advantage of being efficient
at the GUI target end: only minimal edits are applied.




Essentially, a presentation model ensures constraints are satisfied
implicitly, by re-rendering instead of trying to invent transactions
that preserve constraints.





[Reply][About]
[<<][softarch][>>][..]