How Do You Populate Shared Views In A Complex Layout Using MVC?

I'm subscribing to this because I have the same exact question. I have a feeling it revolves around controller event chaining, meaning you have one event for primary and one for secondary and a third that chains the two together for output.

Dunno if that actually helps you, but Symfony2 adds the "render" function to the Twig template renderer. "Render" refers to an action from a controller, which itself can render another template. So the MVC pattern is still applied and you have quality code.
Maybe you should have a look at it.

@Ben,

Since you and I have the same types of questions, I'm just going to let you post since you have the blog and I don't, :). I'll just follow the answers, :)

I seem to remember the way that Model Glue works is really helpful for this kind of problem.

There is a config layer that maps to various controller methods. A single request action can trigger calls to multiple controller methods and render multiple views.

The net result is that, by the time your first bit of view is to be rendered, all the data is available.

It's been a few years since I've had the chance to work with MG. If you aren't familiar with it, I'd check out the docs - sounds like it might be what you're after.

Ben, I think that you should abandon MVC, it is a fad concept that will die out as you have to twist and contort just to do what you want to do.

That is just my opinion. :-)

I have this kind of thing going on in one of my sites. The layout event-handler has its own controller notification, which populates the sidebar. Mach-II has the built-in ability to specify caching of content, which simplifies this. Example:

<event-handler event="home" access="public">
<cache aliases="homePage">
<notify listener="adminListener" method="getNews" resultArg="results"/>
<view-page name="home" contentArg="content"/>
</cache>
<execute subroutine="page.build.main"/>
</event-handler>

where the caching is defined in the configuration:

<property name="Caching" type="MachII.caching.CachingProperty">
<parameters>
<parameter name="defaultCacheName" value="default"/>
<parameter name="default">
<struct>
<key name="type" value="MachII.caching.strategies.TimeSpanCache"/>
<key name="scope" value="application"/>
<key name="timespan" value="0,1,0,0"/>
<key name="cleanupIntervalInMinutes" value="3"/>
</struct>
</parameter>
</parameters>
</property>

The subroutine in the "home" event-handler wraps the rendered page content in the layout html.

Shouldn't the controller handle getting the data from the request for both the primary and secondary areas before passing it to your view? Hence using two models. Looking around i have not seen a way around it other then big capitals saying a view SHOULD NEVER directly call a controller.

In cfWheels, I'd use a filter() in the controller's init() function, which gets the data required for the sub sections. i.e getSidebar()

Then use includePartial() to include the sidebar; the joy of this is this can be cached seperately to the main content in cfwheels :)

@Ben, in ModelGlue, the config layer is absolutely part of the Controller. It defines how requests are handled and manages the routing.

@Ben,

Yes, but you have the option of doing it once in the master controller.cfc (which all other controllers extend) and using super.init() OR, using it in each controller's own init(). With filters you can specific 'except' or 'only' if you only want to specify a subset of views.

@ben
This "render" function only calls a controller method and renders the returned result. So no, it doesn't always entirely render the layout, but sometimes only a small part of it (for example, a dynamic list).
I don't really see a problem with that, and I can't see a more better solution, but I'd be pleased to be proven wrong :)

Using ColdBox, you can have the Controller render a view or you can have a view call the Controller.

Actually, you have two concepts in presentation: Views and Viewlets. A View is a content container and a Viewlet is reusable bits of content.

So your controller function contains event.setView('path/to/view'), which renders view.cfm. In view.cfm, you can have content and/or you can render viewlets.

You do this is two ways: you either run a controller method that renders the viewlet or you render the viewlet that call the controller method.

I prefer to render a viewlet and let it call the controller method. This way, the viewlet know how to get the data it needs to render itself. You can do the same thing in the controller method, call the data, then render the viewlet, but I'd prefer the other process. It seems cleaner.

So view.cfm would contain:

#renderView( view: "path/to/viewlet" )#

and viewlet.cfm would start:

<cfset runEvent("module:handler.method") />

This makes for very lean controller methods and presentation code.

Ben, I'm not sure that I totally understand your question, but generally, if the layout needs to use content that is common to all views and is not supplied by any particular event-handler, then I'd have the layout event notify the listener to retrieve the content, caching it as necessary.

http://www.mach-ii.com/

I've been using Mach-II for years, I can't imagine building an application of any complexity without it.

I would normally use a helper class/function shared across controllers if i was using multiple controllers or a this->loadsecondmodelcall method in a singular controller then return the data as a named key array to the view ['primary_data']['secondary_data'].

I guess my world/take is different as i use CodeIgniter/PHP, sorry.

@Adrian

> <cfset runEvent("module:handler.method") />

I think this is the thing that Ben is wanting not to do. This works great, but if you want to keep your views agnostic, it doesn't work so well. ColdBox introduces a fair amount of coupling between Model, View and Controller - it works nicely, but the coupling is there all the same.

Adrian Moreno seems to have the same method as me.

In FW/1, I would create a separate view for the twitter widget that can then be included in the primary view. Then in your controller, call a service method that loads all of the data necessary for the widget. It helps to separate your view and logic necessary for the widget.

@Dominic So you want multiple controller methods that can get different data to render the same view? That should be done in the Service Layer. You shouldn't need multiple controller methods unless there's something else going on. Even with that, you can override Controller methods using Routing and Modules. You can even use Modules to override Views and Viewlets.

So is it coupled? Sure. But it's still reusable.

@Ben,

Your service method would load the data for the twitter view. Your primary view controller would invoke a call to your service method to include it in your view. FW/1 also has a before method for controllers that can be useful in these scenarios if your twitter view is going to be included on every view within a particular section.

@Adrian, I'm not saying it's bad, just coupled. A decoupled approach *is* doable though. Model Glue (which I believe is based on Mach II), achieves it very well.

Ben, this is an excellent question you bring up and something I've also questioned myself.

You mentioned the possibility of having a different kind of controller like a "Layout Controller". Would you agree that JavaScript is your layout controller? It would seem to be capable of accomplishing everything a controller could but with the ability to change the rendering of the page. You can even interact with your services layer through ajax calls to get the data you need for that widget.

Personally, I've always considered JavaScript to be like a view controller.

@Ben,
Unfortunately I dont have time to answer this in detail now ...but I cover this tonight on the cfmeetup.

I actually use this concept on my website for my tweet stream...which is cached as well. I guess I'll have to open my personal site code for ridicule :-)

There is nothing wrong with views knowing about the model. The model should not know about views, or controllers, or users, but views are ok to know about the model.

Also, my understanding is that a controller is there to do job associated with a request, that is anything that is not specific to that request does not need to go into the controller.

For this specific problem, I would simply bypass the controller and call the twitter service from the view. Yes, just like that, simple and efficient.

Simplify.

See here.
http://screencast.com/t/NvpDqdAY

In this scenario we're in the controller for the site (index.cfm), on the "checkout" page.

As you might imaging, we need a shipping address, billing address, and other checkout information to display. We want to reuse the shipping/billing address logic and form because they are the same.

We render our first view (billing form) and save it into a variable via a simple reusable includeIT function. (http://screencast.com/t/KfDAcMBGM4)

We then render our second view (shipping form) and save it into another variable.

Then we render our third view and save it into another variable. This third view contains information displayed on the page, and also outputs our first 2 views where we want them displayed on the page inside of it.

The mainTemplate is setup to always output the "request.theContent" variable. Basically:
header
request.theContent
footer

This means that on a site wide scale you can render as many views as you want and include them in each other, but it's all setup and rendered in the main site controller for organization and ease of use.

This is basically what most of the frameworks out there do, but without the overkill of needing an entire framework.

@Joe, possible an Ajax call via JavaScript to the same controller with a different parameter? So simulating a second user request.

@Kirill, wouldn't that make it mvcvm? model-control-view-model. I think the point of the mvc is to seperate concerns so the view never has to know about the model and only interacts with the controller.

@David

That is a possibility, but having a controller function perform two different operations might not be the best approach for every situation.

I know with ColdSpring you can expose part of your services layer as a web service and you could talk to that via an ajax call from your JavasScript.

@Ben,

The actual back-end data logic to get or prep the data I do in my model (cfcs). Those always return objects, or arrays of objects .
(always being like 95% of the time)

All of the actual calls to get this data or save new data come from my "controller".
Which for me is my index.cfm.

Every page on the site goes through this index.cfm controller. The index.cfm file calls all of the data up from the model and all of the view pages to display said data.

If there was something that always exists on every page I have outside of my case statement figuring out what page I'm on.

Sometimes there are pages that I don't want to get this information, (say ajax calls). So I do common naming patterns on URLs, or whatever other logic you need.

example: http://screencast.com/t/YM6k9ZUo

By doing this, you can literally open up the index.cfm file for a project, and get a solid high level view of what everything is your project is doing. It also gives you an ease of use to reuse variables modules of your code.

Ben,

The simplest way to do this is to have the controller request the data for each content area from the service layer (using 2 method calls) and then pass it on to the view in a struct. If the data for the secondary content area is to be cached, then that can be handled by the service.

If you need a renderer in the mix, then the controller could pass the data to the renderer cfc after the service call, which would pass the rendered content back to the controller, and then the controller would pass the rendered content plus the data in a struct off to the view.

I don't concern myself with whether using a renderer violates MVC principles. If somebody would argue with me that it does, then my reply is simply that a renderer IS part of the view.

There's no need of another controller. What you need is something like Zend_View_Helper design pattern. See
http://www.javaworld.com/javaworld/jw-11-2004/jw-1101-viewhelper.html

This pattern provides the way to present content dinamically and can be put everywhere in the view.

It's like a shortcut from the model to the view without calling controller methods

The book you mentioned last week says we use different programming paradigms to prevent code duplication.
From that standpoint having the same code in two (or more) different controllers would not be optimal.

just my 2 cents ...

@Bugli, you also have view helpers in Codeigniter (they probably borrowed it from Zend ;) ) but it always seemed a little messy to me as it involves injecting more server side markup in to the view rather then just foreachs() or JSON via Javascript.

By the way, I've been using MVC in CF for many years as part and parcel of the Fusebox, ModelGlue and FW/1 frameworks. I've tried some of the more complex variations to architecture that folks have recommended over time, but when I have to come back to the code months or years later, I get _really_ irritated having to follow the "wiring" back to the code I actually need to edit.

So to me, in the case you've presented here, simplicity trumps being clever, which means in every controller method (reflecting a unique url/page request) where the [cached] secondary content is needed, I'll repeat the service call requesting it. That gives me maximum flexibility, so if the client comes along and asks "Can you please remove the secondary content on this specific page and replace it with XYZ", it's painlessly simple to do. It also makes it completely transparent to me when I go back in to change it months later. I don't have to recall the exotic architecture I used to get that secondary content to appear - it's right in front of my nose in the controller method for the page.

To me, FW/1 is ideal for learning MVC because it helps you to implement a simple, clean architecture.

@Kirill is right. The view is supposed to know about the model. That's how MVC works. (More precisely, it knows the model's interface -- and this may be where you got confused -- but not its implementation.)

When it comes to aggregation, the aggregate list of tweets is a model. It may have references to individual tweets (which are each instances of a Tweet model). Similarly, there would be a view that outputs a list of tweets and has a reference to the aggregate model. It may also delegate the printing of each tweet to instances of a tweet view. The tweet views in that case would each get a references its corresponding tweet model.

In practice, a simple data structure such as an array of structs will probably suffice for your model. The view would be responsible for both looping over the array and printing the appropriate HTML for each tweet.

Another thing you may be missing is there are other components in the system that aren't part of MVC. For example, there should be a component that talks to the API and gets the tweets (building and returning an instance of the model). The controller talks to that API component. There may also be filters and caching mechanisms between the API component and the controller.

Hope this helps.

If there are ansynchronous part to show the best way to implement is use a View_Helper

http://www.corej2eepatterns.com/Patterns2ndEd/images/VHMainClass.gif

It bypass controller and get data from the model to display it.

http://www.corej2eepatterns.com/Patterns2ndEd/ViewHelper.htm

@David,

yes it's true. I've the same opinion, but there are some cases (like this one) where this pattern helps more than the MVC.

It's wrong use it always in programming, but have few view_helpers helps a lot to me.

Ben,

Have you looked at Marionette? Here is an article that I think covers your question - http://lostechies.com/derickbailey/2011/12/12/composite-js-apps-regions-and-region-managers/.

Kianosh

Coming in a bit late here, but it's probably still worth pointing out that MVC as originally conceived actually proposed a hierarchy of controllers, related to a parallel hierarchy of views. In a multi-window desktop app you'd have a view hierarchy that looks something like control->pane->window->desktop, and a controller hierarchy that exactly parallels that. Similar kind of thing for an AJAX app. A web page with independent content areas is not conceptually all that different, even without AJAX. Sometimes the request-response nature of the web is seen as somehow fundamentally different, but the fact is that even the most multitasking asynchronous desktop GUI boils down to a single master event loop somewhere in the guts of the OS, and that basically corresponds to a front controller in web-speak.

So, no need to limit yourself to "the" controller. IMHO, view helpers are basically controllers with the typical controller decision-making behaviour reduced down to just a single case. If that works for you, fine, but for me it's conceptually cleaner to just call them controllers and plug them into the controller tree.

I would like to add a +1 for Mach-II handling this very elegantly. In a Mach-II app, your composite views are generally built by a piece of xml configuration called a "subroutine" which tells the system which files to render into your main layout.

For example, a subroutine called "renderLayout" may pull in your header.cfm file, pull in your footer.cfm, make any necessary controller calls to grab the data for your dynamic sidebar (socialController.getTweets), and then render your sidebar.cfm file using the results from your getTweets call and any other data you needed to grab.

As far as caching, Mach-II has built in caching capabilities which work simply by wrapping a cache tag around the parts of your subroutine which you want to have cached and specifying various attributes which tell Mach-II how long you want to cache the response for, etc.

Btw, I'm a big fan of InvisionApp and this blog Ben, thanks for all that you do!