[Mindwrapper] issues update (Sun 04/20)

[Donnal W. <don...@ya...>]

In ten days (04/30) I will be leaving town for a few days, and the
day after I return (05/05) I go back "on service", so I'd like to
work through as many issues this week (and early next) as possible.

==============
Today's topics
  1. Notifying observers
  2. Passing references to presenters
  3. Revised (or new) Tree presenter
  4. Revising wx.TextCtrl-based presenters
  5. MultiColumnList presenter
  6. Models and composite presenters

==============
1. Notifying observers

The current version of MW uses a "pull" technique for notifying
observers that a change has occurred in an abstraction layer (AL)
node (especially a cell). The notification code sends no direct
information to the observers, so each observer must pull the
information it needs from the relevant nodes (cells). IMO this has
worked fine for dependent cells and component observers in the
presentation layer (PL), but we have had some recent discussions
regarding presenters such as ListBox and Tree needing more
information about the initiating node.

Except for breaking MW notation written up to now (and it is still
early), I don't see much disadvantage in modifying the observer
notification code so that the initiating node is passed to the
observer. The observer is free to ignore this information, of
course, but it would be available if needed.

    def _notifyObservers(self):
        for w in self._observers:
            w().Update(self)
                       ^^^^
                       "self" here is the initiating node.

Then the Update signature becomes:

    def Update(self, node):
        pass

The main motivation for considering this change is not that I think
the pull technique is inadequate for individual nodes, but Tree
presenter, for example, might need to know when a given node is
changed in order to update its display state. This requires sending
the notification (including the identity of the originating node)
down the tree toward the root. I plan to integrate the _smudge()
method into the implementation.

As I said above, this would break existing code, but since we are
still pre-alpha I would rather do it now.

==============
2. Passing references to presenters

I won't repeat yesterday's posting about this topic, but I am
adding it to the active issues list. Having slept on it, however, I
now see that sending the event as well as the list of references
should be a given. It will often be ignored, but it is easier to
disregard unneeded information than to manufacture unknown
information.

    def _onEvent(self, event):
        self.OnEvent(event, *self._ref)
        event.Skip()

    def OnEvent(self, event, model, arg1, arg2):
        # this method overridden to do something
        #   with model, arguments and event

==============
3. Revised (or new) Tree presenter

The original Tree presenter was designed to traverse the AL object
tree for easy display. That is why the node names were given. But
in all likelihood, the MW user will rarely use the Tree presenter
for this purpose. We need to think about the actual use cases for
this presenter and come up with a notation that will best
facilitate this use. In particular, I am interested in whether this
presenter needs an Assemble() method or not. Then, of course, we
will implement the notation that we decide upon, whatever that is.

It is not clear to me whether or not we can get by with a single
presenter for this purpose (with different input parameters) or
whether it might not be desirable to have separate presenters for
different purposes.

This brings up the whole philosophical debate of when to use
special purpose presenters of any kind versus adding specialization
parameters for general presenters. TextField and NumberField are
natural, for example, but is TextArea necessary or could we simply
let TextField know that it is supposed to be mulit-line? More to
the point, is TextReader a good idea, or should we simply use the
READONLY style?

==============
4. Revising wx.TextCtrl-based presenters

All of which brings up the task of revising the presenters based on
wx.TextCtrl. I plan to keep TextField, NumberField, TimeField, and
DateField, but I am inclined to drop TextReader and add a
mw.READONLY style parameter. OTOH, I believe that TextArea
(*without* adding a mw.MULTILINE parameter) would still be
appropriate.

==============
5. MultiColumnList presenter

The MultiColumnList MCL is supposed to wrap the wx.ListCtrl.
Although I may not try to implement it this week, the reason I
bring it up here is to bring up the possibility of folding it into
the ListBox presenter. What if MCL could be a ListBox with cols =
n, for example. Just something to think about while working on
ListBox.

==============
6. Models and composite presenters

In the "traditional MVC architecture" (if there is such a thing)
the models are supposed to be "pluggable", meaning that you can
remove a given model (instance) from its view and replace it with a
different instance. In MW's MVP architecture it would be feasible
to do the same for Text cells and TextFields, for example, but a
major feature of the MW approach is creating composite presenters
(Panels, for example) with complex underlying data models. The
relationships between presenters and models are defined in the
nested Assemble() methods, and created during initialization. This
powerful technique of establishing intricate interconnections
between presenters and models promotes an evolutionary development
strategy and simplifies code maintenance. IOW it is intended to
make design-time tasks easier. The weakness of this approach,
however, is that *at runtime* the connections are rather "tightly
coupled". This means that there is no easy way to plug a new
instance of a complex model into an existing composite presenter.

My way of thinking about this issue has been to accept the fact
that after initialization the model is a permanent fixture in the
presenter and simply move the data to and from persistent data
objects using the Inform() method. It has now occurred to me that
either I need to formalize this mechanism to make it more obvious,
or perhaps reconsider the whole MVP architecture (which I am
somewhat loathe to do).

==============
Active Issues:
  - Notifying observers
      - 2003-04-20 Topic 1
  - Passing references to presenters
      - 2003-04-20 Topic 2
  - Revised (or new) Tree presenter
      - 2003-04-20 Topic 3
  - Revising wx.TextCtrl-based presenters
      - 2003-04-20 Topic 4
  - MultiColumnList presenter
      - 2003-04-20 Topic 5
  - Models and composite presenters
      - 2003-04-20 Topic 6

Regards,

=====
Donnal Walter
Arkansas Children's Hospital