Re: [rgui-dev] Jumping Right In

[Massimiliano Mirra]

On Thu, Aug 08, 2002 at 10:10:22AM -0600, Tom Sawyer wrote:
> i'm all about ASAP. so lets pan this out. i think i have it right, i
> just think i haven't been perfectly clear. the Model in MVC is the thing
> one wishes to extract data from and "visualize", i.e. present via a gui.
> so i sometimes call the Model the core-application, like the fruitapp in
> the GUtopIa Preliminary examples --also often refered to as the Logic. i
> think that may be the source of the confusion. when i say
> core-application i mean Model. it is different from saying just
> application, which is the whole M+V+C. so first things first, are we on
> the same page here. do we both understand MVC the same thus far? do you
> see what i mean by core-application vs. application, i.e. Model vs.
> M+V+C? just a matter of terminology.

I admit it wasn't easy following you, but I did. :-)

By the way, I read my post again and I realize it might have sounded
pretentious.  Sorry if it did, it wasn't meant to.

> So if the backend takes care of the View AND the Controller then
> what's GUtopIa's roll in all this?

Taking care of backends?  Meta-backeding?

> by the way i'm getting this from: http://ootips.org/mvc-pattern.html
> where they give this architecture:
> 
>                  +------------+
>                  |   Model    |
>                  +------------+
>                 /\ .          /\
>                 / .            \
>                / .              \
>               / .                \
>              / \/                 \
>       +------------+ <------ +------------+
>       |    View    |         | Controller |
>       +------------+ ......> +------------+

Uh?  I haven't read the article, but to me it looks just plain wrong.
The View should *not* be coupled to the Model.  Anybody versed in
patterns cares to comment?

Your diagram below of the interaction between M, V, and C looks much
more like it.

> now i think there's something a tad off with these definitions. call me
> crazy, but i don't see where gutopia fits in the MVC, or perhaps i am
> introducing a non-traditional MVC design. because what seems most
> reasonable to me is that the backend IS the View and the GUtopIa IS the
> Controller. But with that understanding i end up with an architecture
> more like this:
> 
>     +------------+     +------------+     +--------+
>     |            | <-- |            | <-- |        |
>     |   Model    |     | Controller |     |  View  |
>     |            | --> |            | --> |        |
>     +------------+     +------------+     +--------+
>    core-application       GUtopIa          backend



> so i am a little unclear about this. with gutopia as Controller its
> intersting that it is not all in one place. It is partly scattered
> about, so to speak, by the use of the #bind method. but that should be
> unimportant. one can further break down GUtopIa, and thus the Controller
> as i see it like so:
> 
>       | <-- |   Auto   | <-- |  UI-model  | <-- | Platform | <-- |
> Model |     | Bindings |     | Components |     | Binding  |     | View
>       | --> |          | --> |            | --> |          | --> |
> 
> so that's the overall angle i'm coming from.

Looks fine to me.

> but to get back to the root of our problem. what needs to be addressed
> is how do you bind to an Array? if something were to casue that Array to
> change, say for instance a timer trigger within the Model. how is this
> going to be automatically reflected in the View? and without manually
> modifying the Model?

I think that is not the root of the problem, it is more likely a
subdomain.  In fact, we could label this matter as `updating
policies'.  Once we see that a widget update is always triggered by
some kind of event, the question becomes: who should trigger the
update event for a certain widget, and how?  It could be the user
clicking an `update' button, it could be a timer firing off each
second, and it could be a data backend as soon as one of each values
changes (in Delphi lingo we would have a `data aware widget').

In the case of the Array, the first thing that jumps to mind is a
Mixin that generates events each time a method of the Array is called
that changes its contents.

  ar = Array.new
  ar.extend Trigger


Massimiliano