Re: [rgui-dev] Jumping Right In

[Tom Sawyer]

> It seems that you are considering the logic (Model in MVC) and the
> application as the same thing, when they're not.  The Model is *meant*
> to be accessed from code only.  Interactions with the outside world
> are the Controller's task.  Application is Model(s) plus Controller(s)
> plus View(s).
> 
> Believe me, the time to get this right is ASAP.  When three years ago
> I took Delphi programming seriously (which is not what 95% of Delphi
> `developers' do, and not even what the manuals encourage you to do), I
> spent *weeks* studying Observer and MVC during the day, and having
> nightmares about them at night.
> 
> I'm afraid that ruby's excellence in introspection and dynamism can be
> a drawback here.  A static language would help more in the basics.

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.

if so, then i'll continue... as for the View and the Controller. that's
seems a bit stickier when it comes to GUtopIa. if the View is the thing
the renders the data to a UI, well in part that is the job of GUtopIa's
component classes, but ultimately these are just passed off to the
backend, so it falls upon FOX, or GTk or what have you to be the View.
But the View must also refresh when the Model changes, which is handled
by GUtopIa's autobindings. And if Controller is the thing that handles
user interaction, well again that ultimatly falls upon the backend, but
these are also passed up to GUtopIa's autobindings. So if the backend
takes care of the View AND the Controller then what's GUtopIa's roll in
all this?

by the way i'm getting this from: http://ootips.org/mvc-pattern.html
where they give this architecture:

                 +------------+
                 |   Model    |
                 +------------+
                /\ .          /\
                / .            \
               / .              \
              / .                \
             / \/                 \
      +------------+ <------ +------------+
      |    View    |         | Controller |
      +------------+ ......> +------------+


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.

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?

whew, sorry this is so long. important to get this right, ASAP, as you
say, though.

thanks,
~trnsami