MVC = "Model/View/Controller" - is a GUI design pattern that
originated in the Smalltalk world and has a bunch of variants in
most OO environments these days. A more popular variant in Java
and C++ is "Document/View", which merges the Controller in with
the View - this is often still called "MVC", though. Swing uses
the Document/View variant.
The basic idea is that you have an abstract data model that has
no (intrinsic) visible representation. A separate View
abstraction provides one (of possibly several) UI for the model.
In a word processor, for example, the MVC-model (or DV-document)
is the data structure representing the content of the document.
The view is the wysiwyg presentation of the document. The view
keeps track of which part of the document is visible and makes
calls into the document to get the actual data to display. The
Controller is the processor that translates mouse and keyboard
events into calls to modify the document.
In Nic's discussion, he's opposing MVC apparentlyspecifically for
web-based development using JSP (though his arguments apply
equally well to ASP). He complains that MVC (or really, DV) in
JSP makes it harder to understand what a page really does.
In this scenario, the Model is the content for the site.
Typically the database. The View is the JSP that formats and
presents the data. The
Controller is the servlet that the JSP calls.
I disagree, though. I think Nic's looking at it from the wrong
angle (and I privately asked him to explicate his reasoning to me
in case I am missing something here). While it's true that you
often can't tell what a form does by looking at the form, who
cares? It's like saying you can't figure out the story of a movie
by listening to the soundtrack. If you want to know what a form
does, look at the servlet that supports it! I suspect his
complaints may stem more from a weak business-layer than from MVC
issues.
The JSP filter stuff is a new feature where you can chain pages.
Basically, the inbound request is handed to the first filter in a
chain, which decides what to forward to the next filter in the
chain, and so on. Eventually, the last filter in the chain
forwards the data to the real target, which sends the response
back through the filters in the reverse order. Typical uses
include things like adding the header and footer to each page, or
URL rewriting to get session state without cookies. I just don't
see the advantage.
Cheers!
Mark
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
