Model View Controller 
Author Message
 Model View Controller

Some questions I hope someone can answer:

1. Is it possible to get Smalltalk 80 for Windows? I have heard that this
was made only for UNIX......

2. What is Model View Controller? It is referred to in lots of
places, but no one tells exactly what it is... Any articles, books, people
who has knowledge about this???

--

          \|||/
          (o o)
----oOOo---(_)---oOOo----

Kurt Helge Stoerseth


URL   ==>> http://www.*-*-*.com/ ~kurt/index.html



Fri, 11 Jul 1997 21:47:35 GMT  
 Model View Controller

: 1. Is it possible to get Smalltalk 80 for Windows? I have heard that this
: was made only for UNIX......

Smalltalk-80 is the name of the original language. There is no product
called Smalltalk-80. The most direct successors of Smalltalk-80 are the
ParcPlace products ObjectWorks\Smalltalk and, more recently,
VisualWorks. These products are available for a large number of
platforms, including Windows. There are other flavors of Smalltalk,
some of which also run on Windows (most notably Digitalk). Check out
the FAQ and stay tuned to this group for discussion of the differences
between the dialects.

: 2. What is Model View Controller? It is referred to in lots of
: places, but no one tells exactly what it is... Any articles, books, people
: who has knowledge about this???

Model View Controller (MVC) is a framework for user interfaces. It is
based on the idea that there is data (the Model), a representation of
that data (the View) and interaction (the Controller). A key point is
that one Model can be operated on by a number of View/Controller pairs.
The model takes care of the synchronization of the updates.

MVC is in use in the ParcPlace products. I'm not sure about the other
products, but I get the impression that Digitalk has a different
approach to the user interface framework. A nice treatment of MVC,
including an example (that needs a bit of work for use with the latest
versions of VisualWorks) is presented in:

G.E. Krasner and S.T. Pope, "A cookbook for using the Model-View-
    Controller user interface paradigm in Smalltalk-80", J. Object
    Oriented Programming, August/September 1988, 26-49.

 __________________________________________________________________

|------------------------------------------------------------------|
|                           Arno Breunese                          |
|                         Control Laboratory                       |
|               Department of Electrical Engineering               |
|                        University of Twente                      |
|                       Enschede, Netherlands                      |
|__________________________________________________________________|
|  phone +31 53 892806                          fax +31 53 340045  |
 ------------------------------------------------------------------



Sat, 12 Jul 1997 16:37:04 GMT  
 Model View Controller

Quote:

>Subject: Model View Controller
>Date: 23 Jan 1995 13:47:35 GMT
>Some questions I hope someone can answer:
>1. Is it possible to get Smalltalk 80 for Windows? I have heard that this
>was made only for UNIX......
>2. What is Model View Controller? It is referred to in lots of
>places, but no one tells exactly what it is... Any articles, books, people
>who has knowledge about this???
>--
>          \|||/
>          (o o)
>----oOOo---(_)---oOOo----
>Kurt Helge Stoerseth

Answer 1: PC version of Smalltalk is available from different vendors. One I
know details about is from ParcPlace Inc. The educational price is $300.00 (
you have to be a student, a certificate from your prof. is required). The price
for the professional version is around 10 times of this. For detail contact
ParcPlace.

Answer 2: MVC (Model View Control) is an object-oriented paradigm which ST
strictly follows. Basic goal of MVC is to minimize the inter-dependency
between interface (View and Control) and processing (Model). In simple words
we can relate the Control to user i/p, Model to process and View to the o/p.
The best use of MVC to design the Classes and protocols will provide an
opportunity to re-use the interface or model for other similar applications.
However, it is important to note at this point is "re-use" is not the only
goals of OOD (obj. oriented analysis).

Regarding books for this topic: I think the best books are the ParcPlace
manuals for VisualWorks and Smalltalk.

I hope this will be of help for you to start. Good luck.

Kiran K. Kanakadandila



Sat, 12 Jul 1997 17:57:55 GMT  
 Model View Controller

Quote:
> Regarding books for this topic: I think the best books are the ParcPlace
> manuals for VisualWorks and Smalltalk.

Can you get these at bookstores, or without buying the products?
I have only once seen a book that discussed MVC - and that was in
a tutorial that came with a Smalltalk.  Ie, can MVC info be obtained
cheaply?  If it's a manual, I want to peruse it before shelling out
my $50.  At least I have money now, when I was a student, this would
have been out of the question (much less Smalltalk itself).
Any books that could be found in a library or in common journals?
--
Darin Johnson

  - Luxury!  In MY day, we had to make do with 5 bytes of swap...


Mon, 14 Jul 1997 03:25:48 GMT  
 Model View Controller

|> : 2. What is Model View Controller? It is referred to in lots of
|> : places, but no one tells exactly what it is... Any articles, books, people
|> : who has knowledge about this???
|>
|> Model View Controller (MVC) is a framework for user interfaces. It is
|> based on the idea that there is data (the Model), a representation of
|> that data (the View) and interaction (the Controller). A key point is
|> that one Model can be operated on by a number of View/Controller pairs.
|> The model takes care of the synchronization of the updates.
|>
|> MVC is in use in the ParcPlace products. I'm not sure about the other
|> products, but I get the impression that Digitalk has a different

It is also used in a "language" called Oberon/F, made by N. Wirth. A short
article on it appeared in this month's Byte Magazine.

Chris.
---
Christian Peper      aka Dreams * graduate student Computer Science

"Nooo, that's not a *bug*, that's a feature!!!"



Mon, 14 Jul 1997 18:15:51 GMT  
 Model View Controller

Quote:

>|> MVC is in use in the ParcPlace products. I'm not sure about the other
>|> products, but I get the impression that Digitalk has a different

Even the current ParcPlace products implement MVC differently from the
original ST-80 at Xerox.

MVC is most useful these days as a general description of the kind of
separation of concerns and benefits thereof. Every GUI "framework" I've seen
for any language has a kind of MVC.

Uninteresting aside: I was in a meeting in December with some folks from
another company. They were explaining their software architecture and how they
used MVC. The Controller in their architecture was not an input controller,
but something completely unrelated to GUIs. It was just something that
controlled something else. Hence they had a Model and View for GUIs, and a
Controller for something else, which made them very proud to have a
Model/View/Controller!


Intel/Personal Conferencing Division
(503) 264-9309 FAX: (503) 263-3375

"What I envision may be impossible, but it isn't impractical."
-Wendell Berry



Tue, 15 Jul 1997 22:48:18 GMT  
 Model View Controller
Quote:



[...]
> >2. What is Model View Controller? It is referred to in lots of
[...]

> Regarding books for this topic: I think the best books are the ParcPlace
> manuals for VisualWorks and Smalltalk.

[...]

Kurt, you may also want to read an article in the latest Smalltalk
Report, "Making MVC More Reuseable" (At least I think that's the title,
I don't have a copy in front of me at the moment:-), written by
Bobby Woolf.

Doug
--
Knowledge Systems Corporation



Thu, 17 Jul 1997 11:01:12 GMT  
 Model View Controller

Quote:




>[...]
>> >2. What is Model View Controller? It is referred to in lots of
>[...]
>> I believe Easel Corp. has a FREE White paper on MVC you should be able to get it from Easel Fax

617-221-2400.

Mike Young



Thu, 17 Jul 1997 23:51:26 GMT  
 Model View Controller

Quote:


>>Digitalk Smalltalk V Windows(ST/V) uses an "event-driven" framework which,
>>to quote Dan Shafer, "replaced an earlier design approach, known as
>>Model-Pane-Despatcher, or MPD,that many people found confusing and
>>confining."

<snip>

Quote:
>> E.g., say a pane
>>obtains "Text" from the application when it opens (note it automatically
>>generates an event #opened);

>>aPane #opened perform: #obtainText:.

>>#obtainText is an event handler, a standard smalltalk method, which must
>>have exactly one paramater - the pane in which the event was generated.
>>The
>>application must have a method

>>obtainText: aPane
>>   "code to respond to event #obtainText"

<snip>

Quote:
>>If two panes have the same application as their owner, they can both use
>>"perform: #obtainText", therefore the "event-driven" framework can perform
>>the same function as MVC or MPD in a much simpler and convenient way.

>Now comes the fun. Note that #obtainText: assumes a certain knowledge about
>the pane passed to it as an argument, since it sends #setText: (or whatever)
>to it.

I wanted to note that Digitalk's V/Win32 and Visual Smalltalk offerings
no longer force usage of panes as parameters, so the ensuing discussion
that I deleted is outdated so to speak. (Of course, one can still pass
panes as parameters if you desire.)  The old way of doing things in V
was as stated above. More correctly it would be:

    aViewManager addSubpane: aPane.
    aPane when: #opened perform: #obtainText:.

where the parameter to obtainText: was aPane, and #obtainText: was
always sent to the owner of aPane (i.e. aViewManager).

The equivalent way of doing this in V/Win32 or VisualSmalltalk is:

    aViewManager addSubpane: aPane.
    aPane when: #opened send: #obtainText to: aViewManager.

(The #when:perform: method is obsolete and doesn't even appear in the
{*filter*} VisualSmalltalk image.) There is also the #when:send:to:with:
message as well. Note some significant differences from the old way:

1. The #obtainText message does not take a parameter (it must match the
   number of parameters the #opened event will pass, which is zero).
2. You can specify the receiver of the #obtainText message.
3. If an #opened: event passed a parameter, you can override this by
   using the #when:send:to:with: message.
4. (Not obvious): the event behavior is available to all objects, not
   just visual entities.  I have used this feature for some non-visual
   objects in a project I wrote.

Quote:
>In MVC, on the contrary, the model knows *nothing* about the view(s)
>displaying its value.

The preceding features (especially number 4) in V/Win32 and VST allow
you to create models that can generate events which can be "caught" by
other "model" objects or by "view" objects. Hence one can completely
disconnect models from all knowledge of views. I don't think this was
possible with prior releases of V.

BTW, it strikes me that with the advent of VisualWorks Parcplace has
moved closer to Digitalk's approach.  I haven't done much work with the
visual aspects of VisualWorks (I usually work in the "model" area of
things); but I believe VisualWorks applications are subclassed from
ApplicationModel, which seems to be sort of equivalent to Digitalk's
ViewManager.

Regards,
Chris
==============================================================

Disclaimer: I do not speak for TI.
==============================================================



Mon, 28 Jul 1997 03:44:00 GMT  
 Model View Controller

Quote:

>Digitalk Smalltalk V Windows(ST/V) uses an "event-driven" framework which,
>to quote Dan Shafer, "replaced an earlier design approach, known as
>Model-Pane-Despatcher, or MPD,that many people found confusing and
>confining."
>I am one of those that found it confusing and confining!

About half a year ago I posted an article here comparing MVC and ST/V
frameworks. I'm not sure it is worth reposting, however drop me a note if you
want to have a look at it, and I'll try to find it then.

But my opinion was exactly opposite to you: I find ST/V framework confining,
however easier to understand. (And actually I think people who find MVC
confining just don't understand it).

MVC succeded to separate (well, maybe not completely, but at least more than
other frameworks) data storage and data representation. (Yes, it is probably
this separation that makes it harder to understand). Speaking of the example
you've given below:

Quote:
> E.g., say a pane
>obtains "Text" from the application when it opens (note it automatically
>generates an event #opened);
>aPane #opened perform: #obtainText:.
>#obtainText is an event handler, a standard smalltalk method, which must
>have exactly one paramater - the pane in which the event was generated.
>The
>application must have a method
>obtainText: aPane
>   "code to respond to event #obtainText"

Here goes an analog (just one of the possible implementations, actually)
for this in MVC. By the way, note that MVC was enhanced as compared to its
original, pre-release-4 form, with introduction of ValueModels--data model is
their ultimate sense.

OK, back to the example. The text you want to show is placed into a
ValueHolder. Then the ValueHolder is passed as a model to ComposedTextView.
This is all. The code is like that:

    ComposedTextView new model: (textModel := 'Hi there' asValue)

then, if you want to change the text, you just say (provided you still have
'textModel'

    textModel value: 'Hi again'

Quote:
>If two panes have the same application as their owner, they can both use
>"perform: #obtainText", therefore the "event-driven" framework can perform
>the same function as MVC or MPD in a much simpler and convenient way.

Now comes the fun. Note that #obtainText: assumes a certain knowledge about
the pane passed to it as an argument, since it sends #setText: (or whatever)
to it. In MVC, on the contrary, the model knows *nothing* about the view(s)
displaying its value. Speaking of the two panes of the same application: most
probably, those panes would be different--I mean, they would present the data
in different ways. Indeed, having two text panes showing the same text does
not look like anything useful. Hence, with ST/V framework, the panes are
*forced* to have a protocol compatible with the model: they should respond
properly to the messages sent to them in #obtainText:, and a model is
forced to know about the protocol of the panes representing its contents. What
is so bad about it? First, the functionality of such an application is harder
to understand, since too much of it lies "in between", in the interaction of a
model and its presentation. Second, model knows too much of the panes. That
is, if you want to represent a model in a different way (say, show a
numerical value as a position of a slider instead of as a number in a text
box), your slider is forced to have the same sub-protocol used by the model as
the one your text box does. In the worst case, this is simply not a case and
you're stuck with ugly and hardly-maintanable workarounds. Or if you're lucky,
you can do this. But then imagine you create a second application, and you
want to use the same slider there in place of something else, with a different
protocol for setting values in it....

With MVC, the only thing the model is obliged to fo is to notify its
dependents when its contents changes. It is the duty of the model to represent
the data it obtains from the model. Thus, speaking of the the above slider and
text box, text box will obtain a number from the value model and display it as
a string. A slider will obtain the number and represent it as a position of
the thumb. If later you want to use a dial as well, the dial should be able to
retrieve the number from the model and represent it in its own way. And what
is important, it *will* most likely be able to do that--just because the
iteraction between a model and its representations is very simple: model
notifies about the changes in its value, representation retrieves the value
(most often as an answer to #value message), and the widgets do it the same
way.

Thinking of an application framework as of plugging widgets into
sockets in data models, MVC offers you a small number of different types
of plugs and sockets. ST/V forces you to manufacture a special plug and socket
for almost every connection. The latter is easier because you don't have to
learn what you're allowed to plug where, and you cannot connect incompatible
thing together just because connectors fit. The former gives you more
flexibility and ease of connection. Choose for yourself what you  like more.

Quote:
>(A
>challenge to PP people: give code examples to do what I have just done in
>two lines of ST/V.)

No, I'm not from PPS. But the code example was given above and it was much
much simpler as the two lines of ST/V. Actually, it is not the number of lines
that counts. It is the collaboration (ease of undertaning) that is
important. In ST/V you create a *special* method in the data model (yuck!),
you register that method as an event handler, and elsewhere you say 'self
changed: #obtainText:' to force the pane to refresh (note that it is yet
another place in the model where you assume the existence of this pane).
In MVC you create a view, create a model, pass the model to the view, and save
the model for "future reference". That's it.  If the data in the model is
changed, it IS changed in the view. Or views, because you don't even have to
remember if there're any views displaying this data, how many of them you
have, and how each of them represents your data.

Quote:
>This also means that GUI builders for V can be much
>simpler than for PP - for instance WindowBuilder/V is much easier to use,
>and to understand then the latest VisualWorks product.

I never used WindowBuilder/V so I cannot compare it against VW. But again I
don't find VisualWorks hard to use--as soon as you *understand* it. But then,
this is true for any powerful tool. If you didn't learn how to use it, it is
your fault.

Take care,

Vassili



Wed, 23 Jul 1997 18:38:48 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. C++/Views: A Model-View-Controller Library for C++

2. Looking for implementation info on Composite Model-View-Controller architecture

3. Model View Controller

4. Looking for info about Model-View-Controller paradigm

5. Model View Controller and Ada 95

6. Model-View-Controller

7. The origin of Model-View-Controller

8. Model-View-Controller concepts...

9. model-view-controller info

10. Model-view-controller

11. Model-View-Controller

12. Is the Model-View-Controller concep

 

 
Powered by phpBB® Forum Software