Re: Lua MVC web framework?

[Don Hopkins <dhopkins@...>]

I agree: there are lots of other great heuristics out there that you can 
combine with or use instead of (or in addition to) MVC.

Model/View/Controller was invented decades ago for Smalltalk interactive 
GUIs, not for distributed web servers. Why, even the SmallTalk people 
moved beyond MVC years ago.

If (like a lot of PHP programmers) you're not already factoring your 
code out into presentation and business logic, then MVC is a good step 
in the right direction, but only the first step of a long journey. But 
taking only one step and thinking you're done leads nowhere. The Java 
people have finally stopped foaming at the mouth about MVC, and now just 
use Models and Views. A well designed framework eliminates the need for 
a special purpose controller to mediate between every view and model, 
and also provides many other services. The Controller tends to be a 
dumping ground for all the miscellaneous stuff that doesn't fit in the 
model or the view, and ends up being quite brittle, gets in the way of 
everything, and increases the number of dependencies between the model 
and the view (and itself).

Controllers can be like having Gilbert Godfrey along as a third leg on a 
date.

Alternative approaches include constraints and data binding based on 
events and delegates (like OpenLaszlo), services with standard 
interfaces (like the NeWS and ScriptX tracking services), aspect 
oriented programming and inversion of control (like the Spring 
framework), and I'm sure lots more cool ways to write web servers and 
user interfaces will be invented in the future. MVC is not the final 
word in software architecture.

From a discussion of MVC in a Python mailing list, asking "Whatsa 
Controller Anyway?":
http://deirdre.org/pipermail/baypiggies/2005-April/000918.html

My two basic points about the different uses of the word "Controller":

1) Web frameworks: The term "Controller" has a completely different
meaning than in Smalltalk guis, and it's misleading to misuse the word
to suggest some similarity to Smalltalk, and bad Cargo Cult Design to
lump everything into one class named Controller just to ape Smalltalk
terminology.

2) GUI frameworks: Using controllers for interactive user interfaces
isn't a very good design for interactive guis, because it's not object
oriented, doesn't hide information, breaks encapsulation, is harder to
maintain, requires special purposes classes and brittle interfaces
between them, and doesn't solve any problems that can't be addressed by
simpler solutions.

   -Don

Don Hopkins  dhopkins@DonHopkins.com
Sun, 24 Apr 2005 20:05:37 -0700

   * Previous message: [Baypiggies] Whatsa Controller Anyway?
   * Next message: [Baypiggies] Whatsa Controller Anyway?
   * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

> From: Ilia Iourovitski [mailto:iiourov@yahoo.com]
>
> In year 2005 it doesn't matter what is the "true controller" means but
how easy to use it and how powerful web framework.
> In smalltalk land MVC was replaced with Morphic project.
> http://minnow.cc.gatech.edu/squeak/30

It's sad that in the year 2005 people are still repeating the mistakes
of the past, just because of confusions about terminology.

There's a huge architectural difference between an interactive real time
event driven GUI like Smalltalk, and a web based request/response based
transaction processing framework like Struts. 
Trying to shoehorn the same Model/View/Controller architecture from an
interactive gui into a web server framework is just confusing and
misleading.
People who first learned MVC in the context of web servers sometimes
don't realize that the things they call controllers are vastly different
that Smalltalk interactive gui controllers.

Sun's use of the term MVC to describe both use cases has blurred the
distinction, in the same way that Sun and Netscape purposefully created
widespread confusion by renaming LiveScript to JavaScript, even though
it was an extremely different language not at all based on or even
similar to Java (their object models take practically opposite
approaches). But Sun means for people to confuse the two different
languages by design, because that helps Sun's Java marketing campaign.
They overload and misuse the meaning of terms like MVC and JavaScript,
just to confuse people on purpose. It's pure marketing, not good
engineering.

With web transaction processing, there's only one event processed during
the lifetime of the View: the Request.
Sessions, Requests, Responses and Containers are just as important as
models and views for web transaction processing, so why don't they call
it the "Model/View/Session/Request/Response/Container" paradigm, to be
more accurate?
Why try to lump everything that's not a model or a view into the
Controller, just to make it seem like Smalltalk?
Using a vague ambiguous word like "Controller" to classify everything
that doesn't look like a model or view is just Fuzzy Logic Design, and
to compare it with SmallTalk's MVC is Cargo Cult Design.

The Morphic web page is interesting, but the links on "Event Handling"
and the "mouseDown event" were disappointing, leading to empty pages
that said "Edit <title> here."
The History of Morphic explains that its author Randy Smith originally
implemented it for Self, which is where I first experienced that gui
interface.
It was really cool, because you could click around nad explore
everything about the system!
Smalltalk's and Self's excellent exploratory programming interface was
much more important than the MVC paradigm, but much harder to imitate.
The Self project was revolutionary rethinking of Smalltalk, so it's no
surprise that they broke out of the old model-view-controller paradigm:

"In Squeak, MVC is available as one of the user interface environments
to work within, and is a direct descendent of the original Smalltalk-80
MVC. The other user interface environment is Morphic, which is somewhat
newer, originally developed for the language Self, and then ported to
Squeak."

Morphic is a classic (or should I say 'prototypical'?) example of
Smalltalk influencing another important language (Self), whose original
ideas later came back around to influence Smalltalk again (not just the
user interface, but also the compiler). What a tangled web of
inheritance!

Java Swing (which is an interactive gui, not a web server framework)
merges the view and the controller into one class, because they
recognized the problems with brittle Smalltalk controllers: "traditional
MVC architecture makes it very hard to create a generic controller that
doesn't know at design time what kind of view will eventually be used to
display it."

I'm not saying that there is this one "new thing" that's better than MVC
in all situations.
But I'm a Conscientious Objector to the fact that tired old MVC is still
being touted as the "new thing for all situations".
Many new and old alternative approaches exist, many of which are more
appropriate than MVC in the context of particular situations. 

My two basic points about the different uses of the word "Controller":

1) Web frameworks: The term "Controller" has a completely different
meaning than in Smalltalk guis, and it's misleading to misuse the word
to suggest some similarity to Smalltalk, and bad Cargo Cult Design to
lump everything into one class named Controller just to ape Smalltalk
terminology.

2) GUI frameworks: Using controllers for interactive user interfaces
isn't a very good design for interactive guis, because it's not object
oriented, doesn't hide information, breaks encapsulation, is harder to
maintain, requires special purposes classes and brittle interfaces
between them, and doesn't solve any problems that can't be addressed by
simpler solutions.

[The rest of the article gives examples and links to more information 
and api documentation. It describes the NeWS window system's tracking 
service, and the ScriptX tracking service, which use alternative more 
efficient approaches than MVC, that are less brittle and easier to reuse.]

http://deirdre.org/pipermail/baypiggies/2005-April/000918.html