Re: Presentation Model GUI Arch and Presenter to View sync

On Apr 6, 1:04 pm, "H. S. Lahman" <h.lah...@xxxxxxxxxxx> wrote:
Responding to Zabroski...



On Apr 4, 1:37 pm, "H. S. Lahman" <h.lah...@xxxxxxxxxxx> wrote:
So what about the display? All we need is some more relationships for
[Node].

        1 used at  R3  responds to *
[Node] ----------------------------- [Control]
    | 1
    | displayed at
    |
    | R4
    |
    | 0..1
[View]
+ isUpdated

The 0..1 multiplicity on [View] captures the fact that on the first
visit to a Node (or if the cache has been flushed), one may have to
initialize the view.

As a separate matter, I couldn't understand you here.  "All we need is
more relationships" kind of confused me.  Where do you want to explain
what a Control and what a View are/do in the system?  For instance,
you say the View is responsible for display, but it has an isUpdated
flag???  This boolean really just highlights the need for a more
elaborate object model, to better discover the problem domain's name-
space relationships.  I think you'd even alter your navigation
relationships as a consequence.

You're right, I could have been clearer. What I meant by "more
relationships" was that the [Node] in this diagram was the same one as
in the previous (tree) diagram. The navigational node in the tree just
needs to be related to specific artifacts that capture the business
semantics for that particular node. [For example, in a POS catalog, a
node for men's shoes will have different values that a node for books.
Thus [View] is likely to be subclassed and Node may be as well.]

I envision the [View] here as a data holder for the values that need to
be displayed. Unless the user actually navigates to that node, there is
no need to instantiate anything so the R4 association would be
conditional since the navigation tree needs to be defined up front for
the "walker" algorithm in [Tree]. When the node is actually accessed
without the relationship instantitated, the <default> View could be
loaded from the DB or whatever.

If the user descends to a lower Node in the tree, then one probably
wants to preserve the View locally because coming back to it is likely
when the user backtracks up the tree. But if one is optimizing local
resources, one might not want to preserve the View once the user has
backtracked up the tree since the user probably won't be back. (One can
always reload it if the user decides to walk back down the tree again.)

The problem with that optimization is that if the user modified the
values without committing them one wants to preserve the View no matter
where the user is in the tree subsequently. Presumably managing that is
someone else's responsibility (e.g., a garbage collector)and they need
to know if they can delete the View, hence the isUpdated flag.

I threw in the [Control] because somebody has to know when the user has
committed to saving any values for that particular Node and I wanted to
talk about that synchronization with preserving the View via isUpdated.
However, that just confused things because the tree is the business view
while a Control is a display artifact. IOW, when the user clicks the
Submit button, a message from the UI will be sent back to notify the
Tree and it can set the isUpdated flag for the Node identified in the
message.

--
Life is the only flaw in an otherwise perfect nonexistence
    -- Schopenhauer

H. S. Lahman
H.lah...@xxxxxxxxxxx
software blog:http://pathfinderpeople.blogs.com/hslahman/index.html

I find this complicated. Sorry.
.