Difference: BrowserSideMvc (2 vs. 3)

Revision 315 Nov 2003 - TobyCabot

  Introduction
-<
<
+Model-view-controller is a design pattern that defines a structure that works well for user interface programming.  It came out of the Smalltalk community and has since been adopted by the deisgn patterns folks [link].  The basic idea of MVC is to separate the data that the user is working with (the model) from the business logic (the controller) from the presentation (the view).  It's a nice idea and it works well in practice, too.
->
>
+Model-view-controller is a design pattern that defines a structure that works well for user interface programming.  It came out of the Smalltalk community and has since been adopted by the design patterns folks.  The basic idea of MVC is to separate the data that the user is working with (the model) from the business logic (the controller) from the presentation (the view).  It's a nice idea and it works well in practice, too.
 People have tried to apply MVC to web user interfaces but it's not as clean a fit.  The biggest issue is that the web is stateless so there's no persistent "model", what passes for a model is the data that will get displayed on the page that the view returns to the user.  So the breakdown is usually like so:
  model: the data that's built by the controller and passed to the view
  view: the code and data that format the model into a purty web page and return it to the browser.
-<
<
+The current "best practice" recommended by Sun is called "model 2 MVC" which has three parts: the controller is implemented by a servlet; it catches the request and puts the model data into a structure which it passes to a Java Server Page which renders HTML to the browser.  The components used are based on the idea that the controller will probably be coded by a programmer, who wants to write in Java, but the view will probably be written by a web deisgner, who will probably use a web page generation tool such as DreamWeaver.
->
>
+The current "best practice" recommended by Sun is called "model 2 MVC" which has three parts: the controller is implemented by a servlet; it catches the request and puts the model data into a structure which it passes to a Java Server Page which renders HTML to the browser.  The components used are based on the idea that the controller will probably be coded by a programmer, who wants to write in Java, but the view will probably be written by a web designer, who will probably use a web page generation tool such as DreamWeaver.
  Problem
-<
<
+This works well but has several problems.  First, it requires a lot of processing on the server to do the controller preocessing and model->view transformation.  Second, html is not always implemented consistently across different browsers so it's difficult to get pages which look similar on Netscape and IE.  Third, it's very easy to "cheat" and end up with html in the servlet or business logic in the jsp, especially if there's no clear organizational difference between web designers and programmers.  Fourth, sending HTML to the browser wastes bandwidth because the entire page must be re-sent even if one item changes.  Most of the HTML content (layout tags, static text, etc) doesn't change from page to page, just some of the data in the page, however there's no way to separate the two from each other.
->
>
+This works well but has several problems.  First, it requires a lot of processing on the server to do the controller preocessing and model->view transformation.  Second, html is not implemented consistently across different browsers so it's difficult to get pages which look similar on Netscape and IE.  Third, it's very easy to "cheat" and end up with html in the servlet, or business logic in the jsp, especially if there's no clear organizational difference between web designers and programmers.  Fourth, sending HTML to the browser wastes bandwidth because the entire page must be re-sent even if one item changes.  Most of the HTML content (layout tags, static text, etc) doesn't change from page to page, just some of the data in the page, however there's no way to separate the two from each other.
-<
<
+Modern browsers are capable of accepting XML instead of HTML, and they can apply XSLT transformations so we should be able to implement the "view" entirely in the browser.  In theory this should solve all three of the issues in the previous paragraph.  The issue is how to split the model, view, and controller so that each part is handled by the software component that makes the most sense.
->
>
+Modern browsers are capable of accepting XML instead of HTML, and they can apply XSLT transformations so we should be able to implement the "view" entirely in the browser.  In theory this should solve all three of the issues in the previous paragraph.  The issue is how to split the model, view, and controller so that each part is handled by the software component that makes the most sense.
  Proposed Approach 

At a high level, the MVC components look like:
-<
<
+ controller: implemented by a server-side technology, e.g. Servlets or CGI.
->
>
+ controller: implemented by a server-side technology, e.g. Java Servlets, Perl CGI, etc.
  model: the XML that the controller sends to the browser in response to a request.
-<
<
+ view: the XSL and CSS stylesheets that transform the XML into something that the browser can display to the user.
->
>
+ view: the XSLT and CSS stylesheets that transform the XML into something that the browser can display to the user.
  Controller
  Model
-<
<
+The model is an XML document which is sent from the controller to the browser.  While the model can be any valid XML it's important to follow a few guidelines.  First, the model must be pure data, no html or pseudo-html.  Second, it's likely that you'll want to define a standard XML DTD for the model, as this will make it easier to build modular view data.
->
>
+The model is an XML document that is sent from the controller to the browser.  While the model can be any valid XML it's important to follow a few guidelines.  First, the model should be pure data, no html or pseudo-html.  Second, it's likely that you'll want to define a standard XML DTD for the model, as this will make it easier to build modular view data.
 Each model page tells the browser how to get the view with a proceesing instruction like so:
 Browser-side MVC has many substantial advantages, and only one drawback, but that drawback is severe: it works only with new web browsers.  But if you're confident that your user community is using new browsers (corporate intranet applications, for example) then it's almost certainly the way to go.
->
>
+ Postscript 

I've written a couple of small experiments to demonstrate trivial examples of how browser-side MVC works.  First, XmlCssExperiment is an attempt at the most "pure" approach, where we apply CSS properties directly to XML documents.  It doesn't work well with Internet Explorer.  Second, XmlXslCssExperiment explores a different approach, where the browser is given instructions to transform the XML into HTML and then CSS is applied to the HTML.  Works well in newer IE and Mozilla.
 -- TobyCabot - 24 Nov 2002

View topic | History: r3 < r2 < r1 | More topic actions...