Re: [rgui-dev] Jumping Right In

[Massimiliano Mirra]

On Fri, Aug 09, 2002 at 10:18:52PM -0600, Tom Sawyer wrote:
> 
>                  +------------+
>                  |   Model    |
>                  +------------+
>                     /\     |
>                     |     \/
>               +------------------+
>               |  Meta-Controller | (GUtopIa)
>               +------------------+  
>                 /\ .          /\
>                 / .            \
>                / .              \
>               / .                \
>              / \/                 \
>       +------------+ <------ +------------+
>       |    View    |         | Controller |  (Backend GUI)
>       +------------+ ......> +------------+
>  
> > Looks fine to me.
> great! so we have a MVC/MC or Meta-MVC ?

Uhm, I don't really know, but we've surely got a view that is not
coupled to the model, which is about enough to let me sigh in
relief. :-)

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

The case you quoted (getting an update event from a changed array) is,
well, a case, in a more general pattern (getting an update event) --
with the added task of cleanly injecting some basic intelligence into
a data item (the array) for the sake of visualization, even though it
was not planned in the model.  I cannot really say what the `root of
the problem' or even what `the problem' is...  and maybe it's best to
let it emerge from exploration of scenarios rather than speculating
about it.  (Yes, I've had lots of well designed speculations
demolished by a single new scenario...)

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

Yes, indeed.  I think we can safely restrict ourselves to just data
meaningful objects.

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

Could you point me to the code where you showed this?  I'm afraid I've
lost myself.  Conceptually, I can't say which method would be better.
And I'm quite curious about how you implemented an object monitor.



Massimiliano