| View previous topic :: View next topic |
| Author |
Message |
Jeff.M
Guest
|
 Posted: Tue Nov 04, 2008 1:15 am Post subject: MVC on the Web |
 |
|
It seems to me that most Web-related articles and frameworks have
misinterpreted MVC. I wanted to check with you folks to see if I'm
completely off base.
The job of the controller is to "process and respond to events,
typically user actions, and may invoke changes on the model." This
sounds like the domain of the Web browser. The browser processes mouse
clicks, keystrokes and other events, and it communicates information
(via an HTTP request) back to the model. The model would be the data
and code, and the view would be the HTML and CSS.
Web frameworks typically claim their code comprises all three
components. They refer to the data by itself as the model and the
business logic as the controller. But this seems a complete
contradiction of the definition of model, which is said to represent
both the data and the business rules.
Am I completely wrong here? Or does the majority of the Web have a
misunderstand of this pattern? |
|
| |
|
 Back to top |
Nick Keighley
Guest
|
| Posted: Tue Nov 04, 2008 11:17 am Post subject: Re: MVC on the Web |
|
|
On 4 Nov, 01:15, "Jeff.M" <Mott.J...@gmail.com> wrote:
| Quote: | It seems to me that most Web-related articles and frameworks have
misinterpreted MVC. I wanted to check with you folks to see if I'm
completely off base.
The job of the controller is to "process and respond to events,
typically user actions, and may invoke changes on the model."
|
This is not an answer to your question but a related question.
I often deal with systems that affect phyical hardware. Say for
instance it monitors physical plant for status ("it's on fire")
and takes appropriate action including informing the user. So is
such physical equipment also some sort of Controller? What about
configuring equipment is that a View?
Or do I just hide physical equipment behind abstractions
(in fact, is that the same as using MVC).
Can you have multiple Views. Eg. views that amount to GUIs
and views that ultimatly connect to real hardware.
| Quote: | This
sounds like the domain of the Web browser. The browser processes mouse
clicks, keystrokes and other events, and it communicates information
(via an HTTP request) back to the model. The model would be the data
and code, and the view would be the HTML and CSS.
Web frameworks typically claim their code comprises all three
components. They refer to the data by itself as the model and the
business logic as the controller. But this seems a complete
contradiction of the definition of model, which is said to represent
both the data and the business rules.
Am I completely wrong here? Or does the majority of the Web have a
misunderstand of this pattern?
|
Sounds all wrong to me. But I speak from ignorance.
--
Nick Keighley |
|
| |
|
| Back to top |
H. S. Lahman
Guest
|
| Posted: Tue Nov 04, 2008 10:07 pm Post subject: Re: MVC on the Web |
|
|
Responding to Jeff.M...
Caveat: I don't do CRUD/USER applications so I don't use MVC at all.
Consequently this is an Executive Summary response....
| Quote: | It seems to me that most Web-related articles and frameworks have
misinterpreted MVC. I wanted to check with you folks to see if I'm
completely off base.
The job of the controller is to "process and respond to events,
typically user actions, and may invoke changes on the model." This
sounds like the domain of the Web browser. The browser processes mouse
clicks, keystrokes and other events, and it communicates information
(via an HTTP request) back to the model. The model would be the data
and code, and the view would be the HTML and CSS.
|
The browser deals with a particular display paradigm. While it does
respond to keystrokes, etc., it only does so within the semantic
framework of HTML display (Page, Section, Field, etc.). The browser is
simply a mechanism for rendering the View. Thus the business semantics
is reflected in text strings used for labels, etc. that are supplied
with the HTML for rendering. The Model, View, and Controller all exist
on the application side.
The browser should not understand the business semantics of the display
content. That is the job of the Controller. [One of the reasons large
script-based browser-side applications tend to be unmaintainable is
because they do not honor this separation of concerns. They mix business
semantics into the scripts driving the rendering.] When the user does
something to a form in the browser, the browser simply relays that event
back to the Controller in its terms (e.g., "The user clicked the Save
control. Here's all the data from the form's Fields.").
The Controller interprets that event in business terms (e.g., "The user
has supplied Customer data.") and responds appropriately. Conversely,
when the business context requires the user to, say, provide Customer
data, the Controller creates a View in HTML for the browser to display
and ships it off to the browser for rendering. [The RAD IDEs tend to
automate a lot of that so that the actual form can be defined
parametrically using external configuration data. Then the Controller
just needs to provide the right data from the Model and identify the form.]
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| |
|
| Back to top |
|
