Wille Faler is an experienced software developer, architect and agile coach with experience across a number of different industries as an independent consultant. Wille specializes in backend, integration, and Java technologies, but has more recently found a passion for Scala and text mining/analysis. Wille is a DZone MVB and is not an employee of DZone and has posted 39 posts at DZone. You can read more from them at their website. View Full User Profile

Decomposing the View in MVC - What’s In a View?

01.07.2011
| 7133 views |
  • submit to reddit

Model View Controller, it’s a simple concept, where the View is simply the front-end representation of what you want to represent, such as the template (or JSP, God forbid) for the web page you want to render, right?
But is it really that simple? Most web frameworks seem to assume it is, but I’m not entirely convinced.

Let me elaborate: Say you want to display a Widget, which you sensibly render at a HTTP GET URL of http://yourdomain/widgets/1, indicating you want to display the information of the Widget with ID 1.
In a typical web scenario using your browser, this would render not only the details of the Widget, but also a header, footer, navbar and various other pieces of information that you’d find in a base web page. In it’s purest sense, is this really relevant for a Widget View? I’d say that it’s not. We are interested in viewing the Widget, and possibly what we can do with said Widget if we adhere to HATEOAS principles.
In other words, in its purest sense we want a view of the Widget and possibly information about the various ways in which we can work with the widget. Everything else around it is effectively Layout Decoration, which could (should?) differ wildly depending on the client that is viewing the Widget: for instance, a full desktop browser might see a lot more layout decoration than a smartphone browser, whereas a client expecting a JSON response will see only a JSON representation of the model for the view.

Decomposing the View into Resource View & Layout
What I am suggesting here is decomposing the View into it’s two logical constituent parts given my rationale above (in the context of the Web):

  • A Resource View is a client specific HTTP representation of the Resource/Model we want to View.
  • A Layout is the client specific Decoration for the Resource View, containing common elements such as navbars, headers, footers, login prompts and whatnot.


Of course, most web frameworks already provide means of extracting common layout elements (though most of them do it rather poorly), but they rarely make much distinction between the two, nor do they give developers useful aid or “nudges” to make this distinction. In the language of most existing web frameworks, a View is a View which contains not only a rendered representation of the Model/Resource we are interested in but all the other things as well.

Decomposing the View is a Necessity for Multi Channel Delivery of Webapps
To summarize, I think the view (pun intended) that a View is simply a View is an approach that is too coarse grained to be suitable for the landscape of the modern web: duplicating effort by creating a browser experience, a mobile web experience, a tablet experience and a REST API is just not a feasible approach when time-to-market is of the essence, not to mention the wastage of money and resource in doing so. By consciously decomposing the View further as I have suggested, re-use can be much higher, re-work can be minimized and client specific layout decoration can easily be extracted, as can multiple Resource View Templates, as the scope of them are restricted to simply rendering a view for a specific resource in slightly different ways and nothing else.
I believe that View = Layout + Resource View is a necessity if you want to deliver a web experience to multiple channels/clients without running the risk of doing massive amounts of duplicate work and re-work.

References
Published at DZone with permission of Wille Faler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Andy Leung replied on Fri, 2011/01/07 - 9:16am

Nice article!

My own view of "view" in MVC is actually quite different than most of the web apps today. I think "View" should have its own logic, configurations, persistence of presentation and behavior, and also capturing how users are interacting with. In other words, it's like 3D games. In a 3D game, you develop your presentation layer as rendering pipelines. The graphics data draw more than just the grid (page), but also the view (layout) and details inside (HTML components). You can save the graphics data in some games because these data are dynamically generated based on either user inputs or algorithms. Game data itself is residing somewhere else and they translate some of the meanings to the graphics or vice versa. And I believe a very successful web app should have its own rendering engine and manipulation tool. The closest framework or webapp I have seen is Portal. Portals allow you to create dynamic pages and content details, except that some portals even allow you to change layout on the fly, which is more impressive but I believe as time goes on, we need something more than that.

Chris Knoll replied on Fri, 2011/01/07 - 9:20am

I guess the problem I have here is that your view of MVC is limited to a webapp context.  The power of the MVC architecture is 2-fold:  testing and flexability.

 For testing, you can separate the controller from the view in your test cases so that you can test the 'presentation rules and behavior' without actually having the element render.  This is attractive for automated unit tests.

For flexability, you can have different impelentations of your view so that your widget can be an HTML renderer,  or a swing componet, or swt, etc.  The controler and model is reused behind each of these views.

What you describe above where you have your Resource View and Layout is pretty much what you get with using template technolgoies such as asp.net, struts, and even XAML in the .net space and even JSPs (although i know you cringe at it, it's what libraries you put on top of JSPs make or break the use of JSPs).  The view implemntation in these cases understand how to translate the XML/template language into the desired output (html or physical UI components (in the case of XAML and .net)).  It provides some pretty powerful capabilities, and it's all thanks to MVC (and it's descendants such as MVP, M2 etc).

-Chris

 

Adam Davis replied on Fri, 2011/01/07 - 4:11pm

Wille, I believe that you are correct in most cases, but you may be making more out of this than you need to. Your controller should do some kind of processing to fit the resource view into the page 'template', but I don't think you need to have separate templates for desktop and smartphone browsers. Doing that would require you to do browser detection, and also to potentially update your detection code with every new device/browser combination. Instead your application server should try to return the resource data in the format that's requested. If the client requests HTML (in the Accept Request header) then that's what you should return. If it asks for JSON (or XML) you should return that. Trying to guess what the user wants based on the User-Agent string is a losing battle.

Please note that I'm not saying that your application pages should look the same in desktop and smartphone browsers; I just think you should try to do the styling differences by creating separate CSS for browsers which identify themselves as mobile browsers or which have limited screen dimensions. The differences you discussed above should be doable that way. A List Apart (http://www.alistapart.com/) has a few good articles for using CSS.

Wille Faler replied on Fri, 2011/01/07 - 4:59pm in response to: Adam Davis

Adam:
There are certainly multiple ways to skin the cat in this instance. :)

When it comes to the Accept header, you are on the money: I find that the actual HTTP spec is often overlooked and people instead use various homegrown solutions for providing REST API's, when just looking at the Accept header is sufficient to know what the client wants from you.

As for User-Agent tailoring: You can do this either server-side by User-Agent, or by JS and CSS client-side, or probably the best solution - a bit of both.
For instance, you may have the User-Agent deliver an initial "guess" at what CSS and JS files you want to load up, and then let the client-side do the rest (deciphering a User-Agent that contains the string "iPad" or "iPhone" really isn't that hard..).
lated post I wrote some time ago might be a good complimentary read on my take on this

Adam Davis replied on Sat, 2011/01/08 - 11:29pm

Thanks for the link. The article (and discussion) were very interesting. I liked 2 of your points towards the end of the discussion:
  • Use technologies for what they are meant for. UI tier consists of UI technologies.
  • ... the closest thing you might have is to enforce clean separation simply by the technologies you use and how you use them.

Although you're correct that checking the User-Agent for "iPad" or "iPhone" isn't hard, those might not be the only devices your customers are using. Eventually updating that code to handle yet another mobile device / browser combination might get old. Having said that, easily generating web front ends for multiple devices and browsers seems to be an unsolved problem, and its always good to see potential solutions.

Thank you for the article (and reply).

Wille Faler replied on Sun, 2011/01/09 - 3:16pm in response to: Adam Davis

Tailoring for all possible devices is clearly an impossible task, however you could have tiers of customizations, for instance:
  • Full customization for popular/"buzz-worthy" devices like iPhone/iPad
  • A tree of device capabilities as per "WURFL" where you tailor based on device lineage ("is it likely to be a Nokia Symbian phone with a screen like XYZ?")
  • Those not recognized, try to do it by means of JavaScript.
Full customization for all devices is an impossibility, but there are tricks of the trade to get it "sort of right" for 80% of the cases.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.