At 01:10 PM 10/13/2005 -0700, John Anderson wrote:
>I don't think this issue is going to be resolved in an email exchange, so
>perhaps we need to tackle it off line.
Which is why I keep saying that concrete proposals and prototypes for
introducing MVC (or better still, MVP) to CPIA is really a matter for 0.7
and beyond, and I've been trying to avoid going into details. If you don't
have time to read or comment now, that's fine; this email is so that I can
capture what I'm thinking now, without having to think it out again
later. It's also so that people following the discussion here don't end up
with the wrong impression, as some might think based on your comments that
I'm somehow misunderstanding CPIA, rather than simply saying that there are
some modest changes we might make that could have significant beneficial
impact on our development process, the platform APIs, our back-end options,
testability, upgradeability, etc.
>At the heart of the disagreement might be what is code and what is data.
When I say "code" I simply mean that something is developer-defined and
part of the shipped application (even if end users can also define
something similar, or copy it to use as a basis for creating something
else). When I say "data", I mean the current logical state of a particular
installation of the application. It is a lot easier to say "code" and
"data" than to spell out those phrases all the time, but if you feel "code"
and "data" are distracting, we can invent new words for the concepts instead.
However, I don't think "disagreement" is an accurate description of the
conversation so far. You can't disagree with my position until you
understand it, and I've mostly been trying to avoid fully stating it in my
previous messages. :) I also don't disagree with you, it's just that your
position doesn't seem to relate to the things I'm saying.
In brief, my position is that it would be a good idea to investigate
implementing a more traditional separation of roles ala MVP or MVC. But as
far as I can tell, everything you've been saying has been of the form, "But
CPIA currently does something else". And on that point, how could I
possibly disagree with you? :)
>Traditional UI's use lots of code, CPIA moves a lot of what was code to data.
...and replaces it with code that creates the data, which is then
interpreted by other code to create the widgets, which is not necessarily
an improvement upon simply having helper functions or widget subclasses
that you invoke in the first place.
In any case, saying it's data rather than code isn't really a new
distinction for CPIA, as resource formats like XRC certainly exist, and
have the additional advantage of having editing tools that already exist as
well. (Note: I'm not saying we should use XRC, just pointing out an
example of a tool that exists.)
(By the way, having data in place of code to create controls in this way
goes back at *least* as far as Visual Basic and JavaBeans, and I imagine
somebody can probably give Lisp or Smalltalk examples going back much
further than that, so I don't think you can reasonably say that a
data-driven UI isn't "traditional". But this is a bit of a tangent.)
> I think of a CPIA block as the model and the widget as the view in an
> MVC world of the user interface.
You are certainly free to think of it that way, but it won't help you with
grasping any other ways of thinking about it, that might improve on things.
>Dividing that part of model, which describes behavior of the block, from
>that part of model which remembers user state seems very arbitrary,
...but only because you classified it as being a model in the first
place. The conclusion follows directly from your premise, so this doesn't
get us anywhere - it's just saying that the current architecture is what it
is, and CPIA does what it does. Entirely truthful, but not very helpful
for moving forward.
In a different architecture -- let's take MVP for example -- the
interaction state is part of the presenter, not the view. By contrast,
CPIA merges the view and presenter of MVP into a single kind of component:
blocks. This makes CPIA less flexible, more fragile, less testable, and
gives it a steeper learning curve than MVP.
If you'd like some background on MVP, here's a useful place to start:
http://www.object-arts.com/EducationCentre/Patterns/MVP.htm
It includes a simple tutorial of creating first the domain model, then the
presenters, and finally a view for a simple application in Smalltalk, using
the ValueModel pattern to implement presenters. You'll notice that the
presenters are entirely independent of their views, meaning they could be
used with *any* GUI backend, *or without a GUI at all*, which means that
application logic can also be unit tested without the GUI present or even
imported, allowing (for example) clear distinctions to be drawn between
logic bugs and view bugs.
It also means that the application logic developer doesn't need to be a GUI
designer or vice-versa, because different people can create or edit the
views and presenters without stepping on each others' toes. It means that
the UI can be "skinned" or "styled" without affecting application
logic. The view is simply a specification of the physical rendering, and
which aspects of the presenters map to what widget aspects.
These are all rather significant enhancements compared to the current state
of things. There are other benefits possible, if for example we align the
repository's notification systems with a ValueModel-based presenter layer,
but that's a detail that can be elaborated on later.
> especially since in the end they are both user editable, either by a GUI
> builder or by "driving" the UI itself. Of course this MVC UI view is
> distinct from the real model, that is content items and collections,
> which aren't part of CPIA, but are referred to by CPIA.
That's lumping the domain model together with the interaction model. The
domain model is the state of the data. The interaction model is the state
of the application. These are both distinct from the view, which is just a
transient visual representation.
>The MVC UI is also distinct from user preferences. The selection is a bit
>in between, it is being moved out of the CPIA block and into a new
>collection which is feed by the collection the user thinks of.
It's not "in between" at all. The selection is part of the interaction
model - it's part of the logical state of the application. In MVP, the
current selection would be an aspect of a presenter. If we were using MVP,
we would persist the presenter, but the only reason to persist a view would
be if we were creating a GUI builder. And there would be no need to copy
views as part of normal operation, because a view is just the specification
for widgets and how they hook up to the presenter.