Re: [rgui-dev] Jumping Right In

[Tom Sawyer]

good to hear from you!

On Fri, 2002-08-09 at 16:40, Massimiliano Mirra wrote:
> 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.

don't sweat it. good to get a kick in the ass sometimes anyway.

> Taking care of backends?  Meta-backeding?

meta meta everywhere! :-)

> 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.

am i glad to hear that. you know i tried readin some more on MVC and i
must admit that i'm not liking what i'm hearing. talk about
over-complexifying things. what ever you want to call gutopia's design
as i drew it in my last post, MVC or no, it sure seems like the right
way to do it to me. but i think i have it figured out: the VC in MVC is
really just the task of the backend GUI app. essentially we're just
sticking gutopia between it and the model as a meta-controller. like so:

                 +------------+
                 |   Model    |
                 +------------+
                    /\     |
                    |     \/
              +------------------+
              |  Meta-Controller | (GUtopIa)
              +------------------+  
                /\ .          /\
                / .            \
               / .              \
              / .                \
             / \/                 \
      +------------+ <------ +------------+
      |    View    |         | Controller |  (Backend GUI)
      +------------+ ......> +------------+
 
> Looks fine to me.

great! so we have a MVC/MC or Meta-MVC ?
 
> 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').

what do you see as the root of the problem?

could you elaborate on this some more?
 
> 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
> 

i was really just meaning the basic problem of how best to do the
automagic. i think you have a good idea here in that regard. i
"finished" up the code i recently posted. it is essentially an object
state montitor, that triggers off events based on specified changes to
the state of the object. but there's a problem. to do this requires
cloning the instance varaibles of an object. but not all object can be
cloned. this causes my code to die. very sad, since it also means my
object undo function goes down the drain. but that's not really
important.

on looking further into this, i realized that most objects just don't
make sense in this regard anyway. for example, you're not going to bind
a part of your gui to a to a Module object, right? so really only a
dozen or so objects are of any use for binding, like string, array, etc.

so we have two choices. i can modify the code i have written to only
monitor an objects state for these particular types of "sub-objects", or
i can refactor some and do as you suggest and create a module that we
use to extend the pertenant classes. we'll end up with pretty much the
same functionality. its just the matter of what level is better to
implent it at: at the level of an object monitoring all is sub-objects
or at the level of an object just monitoring itself. (of course the two
blur a little in ones mind, but if you look at my code you'll understand
what i mean by the first. your idea is of course the second)

~transami