Hello,
Can someone provide some clarification on the following statement
(from http://kogs-www.informatik.uni-hamburg.de/~moeller/uims-clim/clim-intro.html
). I've re-read it a dozen times and done some research on
CLIM and "clim versus mvc" on the web and in google groups, looked
at w3p etc., but still don't see the distinction being made. I
understand the MVC part, but don't follow the CLIM part. Why is
CLIM "top-down", how is this different from MVC, and what design
ideas can we get from CLIM that are different from MVC?
The statement below just seems to make a couple abstract statements
and then goes into all this caching stuff. The caching stuff may
be good to know (possibly relevant to edge-side includes) if it makes
a web app designed with these ideas easier to accomodate a cached
content
servers than an MVC web app.
Thanks,
-Rich
<quote>
Basically, there are two approaches to handle redrawing of application
panes. The bottom-up approach records changes to application objects
and redirects
these changes to update requests to associated graphical objects shown
in different panes. Smalltalk supports this process with its
Model-View-Controller
scheme [25] (other systems use similar approaches). An application
object is called a model which is associated with one or more views.
Controller objects
manage the manipulation of graphical objects and translate changes to
these into corresponding change messages sent to model objects
(application objects).
Though the bottom-up approach is not directly supported by the CLIM
framework, it could also be implemented with minimal effort. However,
the approach
requires that modification requests to application objects be
recordable (which is not alway the case for low-level data structures
necessary for some
appliations).
The other way to handle redrawing uses a top-down strategy. This is
the supported way of CLIM. Each pane of an application frame is
associated with a
drawing function (or drawing method). The drawing model of CLIM allows
elementary output (e.g. with draw-line, draw-rectangle, etc.) to be
recorded (in so-called output records). Recorded output is
automatically replayed (e.g. when a pane is scrolled by the user).
Output records may be
arranged into a part-of hierarchy (spatial decomposition). Specialized
output records can be used to cache previous output. CLIM
automatically computes
what has to be erased and what has to be redisplayed when cache values
change. This mechanism is called incremental output. The caches
contain
references to attributes of domain objects and, when these change, the
output record will be replayed. The part-of hierarchy of output
records can be used to
control the search space for cache-changes. Other user interface
management systems also provide a facility to arrange graphical output
using hierarchical
structures (e.g. ClassWorks).
</quote>
On 26 Feb 2002 07:40:10 -0800, itsjustafantasy <·······@hhmi.org> wrote:
>Hello,
>
>Can someone provide some clarification on the following statement
>(from http://kogs-www.informatik.uni-hamburg.de/~moeller/uims-clim/clim-intro.html
>). I've re-read it a dozen times and done some research on
>CLIM and "clim versus mvc" on the web and in google groups, looked
>at w3p etc., but still don't see the distinction being made. I
>understand the MVC part, but don't follow the CLIM part. Why is
>CLIM "top-down", how is this different from MVC, and what design
>ideas can we get from CLIM that are different from MVC?
I am certainly not a CLIM expert compared to some readers of this
group, but I'll take a shot. I'm not sure about the bottom-up
vs. top-down distinction either, but one of the differences between MVC and
CLIM is where the responsibility lies in maintaining the display and
how that is implemented. In CLIM most if not all graphical output is
recorded in display-list-like output records, so the display can be
refreshed or scrolled without any intervention from the user
application. Some output can be associated with program objects; CLIM
will determine if an object has changed (with help from the user
program) and if it has discard its old output records and generate new
ones for the current state.
There is also an assumption in the quote that in MVC modifications to
graphical state are translated by the controller into changes to
program state, whereas in CLIM program objects are modified and then
that change is reflected in the graphical state. I don't know if his
description of MVC is universally accepted or not.
Tim
>
>The statement below just seems to make a couple abstract statements
>and then goes into all this caching stuff. The caching stuff may
>be good to know (possibly relevant to edge-side includes) if it makes
>a web app designed with these ideas easier to accomodate a cached
>content
>servers than an MVC web app.
>
>Thanks,
>-Rich
>
><quote>
>Basically, there are two approaches to handle redrawing of application
>panes. The bottom-up approach records changes to application objects
>and redirects
>these changes to update requests to associated graphical objects shown
>in different panes. Smalltalk supports this process with its
>Model-View-Controller
>scheme [25] (other systems use similar approaches). An application
>object is called a model which is associated with one or more views.
>Controller objects
>manage the manipulation of graphical objects and translate changes to
>these into corresponding change messages sent to model objects
>(application objects).
>Though the bottom-up approach is not directly supported by the CLIM
>framework, it could also be implemented with minimal effort. However,
>the approach
>requires that modification requests to application objects be
>recordable (which is not alway the case for low-level data structures
>necessary for some
>appliations).
>
>The other way to handle redrawing uses a top-down strategy. This is
>the supported way of CLIM. Each pane of an application frame is
>associated with a
>drawing function (or drawing method). The drawing model of CLIM allows
>elementary output (e.g. with draw-line, draw-rectangle, etc.) to be
>recorded (in so-called output records). Recorded output is
>automatically replayed (e.g. when a pane is scrolled by the user).
>Output records may be
>arranged into a part-of hierarchy (spatial decomposition). Specialized
>output records can be used to cache previous output. CLIM
>automatically computes
>what has to be erased and what has to be redisplayed when cache values
>change. This mechanism is called incremental output. The caches
>contain
>references to attributes of domain objects and, when these change, the
>output record will be replayed. The part-of hierarchy of output
>records can be used to
>control the search space for cache-changes. Other user interface
>management systems also provide a facility to arrange graphical output
>using hierarchical
>structures (e.g. ClassWorks).
></quote>
"itsjustafantasy" <·······@hhmi.org> wrote in message
·································@posting.google.com...
>
> Can someone provide some clarification on the following statement
> (from
http://kogs-www.informatik.uni-hamburg.de/~moeller/uims-clim/clim-intro.html
> ). I've re-read it a dozen times and done some research on
> CLIM and "clim versus mvc" on the web and in google groups, looked
> at w3p etc., but still don't see the distinction being made. I
> understand the MVC part, but don't follow the CLIM part. Why is
> CLIM "top-down", how is this different from MVC, and what design
> ideas can we get from CLIM that are different from MVC?
>
> The statement below just seems to make a couple abstract statements
> and then goes into all this caching stuff. The caching stuff may
> be good to know (possibly relevant to edge-side includes) if it makes
> a web app designed with these ideas easier to accomodate a cached
> content servers than an MVC web app.
>
OK, in classical MVC, the "model" is application objects, the "view"
is UI objects -- often built entirely of toolkit classes -- and the
controller
is "glue" which mediates the model and the view. You usually have to
write most of the controller code yourself.
In CLIM, the model classes are you application classes. There really
aren't view classes -- the view is created by writing "display" methods
on the model classes. At a low level, there are CLIM output records
that display the view, but it's not really accurate to think of output
records as the view; they are really a *rendering* of the view. Finally,
the controller is mostly CLIM itself (*); CLIM's controller is driven
by the *semantic* operations in the application. That is, the types of
the model objects plus "command" methods plus an organization into
"command tables" gives CLIM enough information to do most of what
you would do by hand in a classical MVC architecture.
(*) The exception is multiple views, where you have to write the glue
between multiple views of model objects. The mainly entails adding the
usual "notification" methods:
- model objects track what view they have been put into
- when a command updates a model object, it notifies the other views
The reason CLIM doesn't directly support the multiple view stuff is that
it's so simple, it didn't seem worth the effort.
Does this help?
On Sat, 2 Mar 2002, Scott McKay wrote:
[snip]
> OK, in classical MVC, the "model" is application objects, the "view"
> is UI objects -- often built entirely of toolkit classes -- and the
> controller
> is "glue" which mediates the model and the view. You usually have to
> write most of the controller code yourself.
[snip]
This doesn't sound like classic MVC to me, at least not from the Smalltalk
perspective. Controllers "control" the human interaction with the system,
and in a classic smalltalk system are relatively rarely dorked around
with. Models are perfectly capable of interacting with views on their own
(via #update: messages).
Here's a reference:
http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html
which says:
"In the MVC paradigm the user input, the modeling of the external
world, and the visual feedback to the user are explicitly separated and
handled by three types of object, each specialized for its task. The view
manages the graphical and/or textual output to the portion of the
bitmapped display that is allocated to its application. The controller
interprets the mouse and keyboard inputs from the user, commanding the
model and/or the view to change as appropriate. Finally, the model manages
the behavior and data of the application domain, responds to requests for
information about its state (usually from the view), and responds to
instructions to change state (usually from the controller)."
Can't say anything about the CLIM bits.
Cheers,
Bijan Parsia.
Scott McKay wrote:
> In CLIM, the model classes are you application classes. There really
> aren't view classes
OK, no views.
> -- the view is created...
hang on, we said no views. Did you mean "the model is drawn..."
> ...by writing "display" methods
> on the model classes.
OK, methods, not views.
> At a low level, there are CLIM output records
> that display the view,
Views are back! Do you mean "display the model"?
What determines where and with what background color (amongst other
display parameters) the model gets displayed? I am starting to suspect
this information exists on the stack just long enough to generate an
output record, which gets used ever after until the model changes in
some way requiring its appearance to change.
> (*) The exception is multiple views, where you have to write the glue
> between multiple views of model objects.
Ok, now we definitely have views, but we started with "no view classes".
> The mainly entails adding the
> usual "notification" methods:
> - model objects track what view they have been put into
> - when a command updates a model object, it notifies the other views
Yup, sounds like we got view classes.
Sorry, I do not mean to be a pain in the *ss, just trying to make clear
my points of confusion. I am close to finishing up mop-less cells and am
trying to figure out if I want to do a common lisp gui atop CLIM, CLX or
(?). I've looked at the CLIM doc and did not get too far; your quick
overview was much more approachable.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Be the ball...be the ball...you're not being the ball, Danny."
- Ty, Caddy Shack
Thanks to all for your responses so far.
"Scott McKay" <···@attbi.com> wrote in message news:<························@typhoon.ne.ipsvc.net>...
> "itsjustafantasy" <·······@hhmi.org> wrote in message
> ·································@posting.google.com...
> >
> > Can someone provide some clarification on the following statement
> > (from
> http://kogs-www.informatik.uni-hamburg.de/~moeller/uims-clim/clim-intro.html
> > ). [...]
> OK, in classical MVC, the "model" is application objects, the "view"
> is UI objects -- often built entirely of toolkit classes -- and the
> controller
> is "glue" which mediates the model and the view. You usually have to
> write most of the controller code yourself.
>
> In CLIM, the model classes are you application classes. There really
> aren't view classes -- the view is created by writing "display" methods
> on the model classes.
That doesn't surprise me, looking over the API, seeing all those
(with-output-as ... functions. It's all built-in.
I've also read that "every object is really presentation types" and
also something to the effect of "typically you don't write presentation types
but they're all just the same as the model"...which I take to mean that since
there is a one-to-one correspondence of model class to its presentation type
(which has methods for every type of view supported) you just combine the two.
[...]
>
> (*) The exception is multiple views, where you have to write the glue
> between multiple views of model objects. The mainly entails adding the
> usual "notification" methods:
> - model objects track what view they have been put into
> - when a command updates a model object, it notifies the other views
> The reason CLIM doesn't directly support the multiple view stuff is that
> it's so simple, it didn't seem worth the effort.
>
My impression so far is that CLIM is like
MVC on steroids in terms of the vogue j2ee problem of "separating business
content/objects from presentation".
Does it make any sense to use the term "presentation_adapter"
in place of "presentation_type"? Probably not, I'd be "presenting
an adapter(for a model) to a view", when we already know the adapter
was written for the view. But what if the adapter is supposed
to contain all the methods for every type of view for a given
model, then it might make sense, especially if it's considered
bad form to attach the adapter to the object and "present the object".
Just some related confusion.
-Rich
As for "top-down" and model differences, some more excerpts might
help/provide something to comment on:
<QUOTE>
Smalltalk adopts the MVC model whereby the dependency mechanisms govern
the interaction between the model,view and controller. In ISE EiffelVision,
there is the notion of a Context-Event-Command-State model. The relationship
here is that an event occurs within a specific context thus triggering a
specific command. These commands are laid out via the setting up of callbacks.
(I stand to be corrected) The question however is this, What are the perceived
benefits of the later(evision model) compared to the mvc inherent in smalltalk,
specifically in the context of user interface construction?
Tks.
Calvin
<QUOTE>
> To: Peter Paine <··@enterprise.net>,
> ·······@informatik.uni-hamburg.de (Ralf Moeller)
> From: ·······@informatik.uni-hamburg.de (Ralf Moeller)
> Date: Mon, 17 Feb 1997 17:53:34 +0100
>
> [...]
>
> CLIM already provides a generic function highlight-presentation for
> mouse-sensitivity indication. What about adding a protocol for "marking the
> current object"?
>
>This is a fine idea, but I see little benefit in CLIM providing it.
>Reason: I think a typical user would end up specializing the entire
>protocol, making the CLIM standard-methods just more code-bloat.
>
>Such a protocol would consist of (1) the (graphical) marking method,
>and (2) the container that would hold the selected object or set of
>selected objects. I believe most users would end up writing
>application-specific versions of both of these.
This is a fine idea, but I see little problems in CLIM providing it.
Reason: MVC in smalltalk does just this: specify a framework and
let the programmer fill in the parts. The point is that the programmer
is being provided with a skeleton, i.e. the parts to be changed are clearly
identified. Your argumentation sounds to me that we better have no
protocol when there is a danger that all default parts might be overwritten
in some situation.
>Note: I strongly recommend that you do NOT confuse
>(a) highlighting that indicates that a translator is available from
>the pointed-to object to the current input-context; and
>(b) highlighting that indicates that the pointed-to object is
>(b1) selected or (b2) a member of the selected set.
Thank you for your recommendations.
<QUOTE, ISN'T THIS A MISTAKEN IDEA OF MVC (date of this message is Oct 2000)>
>> This all mean that apps should be implemented in Model/View/Controller
>> manner, where the GUI is kept as a separate component in the application,
>
>I have heard of this before, but have never seen a reference to it
>outside of conversation or Usenet. Are there good books on this?
>Maybe it's known by other names and I'm just missing the connection.
Look for the literature on Smalltalk or NeXTStep.
The approach where you separate things out to:
a) An underlying Model, which is what actually Does Stuff,
b) Viewers, that can connect to the Model to provide you ways
of looking at Whatever is Going On, and
c) Controllers, widgets that can connect to the Model to manipulate
whatever it does.
Smalltalk was where this was developed and made useful. NeXTStep
also used it. CLIM (Common Lisp Interface Manager) also provides
something rather like this.
<END QUOTES>