Question

I’m using the Yii framework to develop a site that uses a 2-column layout. One column is the actual content, while the other is a menu with site links, some information about the logged in user and a list of the latest posts. The menu is present on all the pages, but it has no information that is related to the current page (or route).

Every time I render the menu I need to retrieve the list of latest posts and user-related data from the database. I’m not sure how it would be best to render this menu so that I don’t repeat the code that fetches the data in every action on the site.

I have thought of a few approaches and I would like to know which one of them (if any) is the right way to handle this situation.

• Fetch the data in the Controller::beforeRender method, then render the menu in a partial view which displays the data in a CClipWidget block. Then, in the layout view, display the block where the menu is supposed to be. This method works, but I feel that it’s quite clunky because of the beforeRender. If I ever add a page that doesn’t have the menu on it, I need to include a check for that. Also, after reading the Yii documentation, I don’t understand if beforeRender() is called for renderPartial() as well, or just for render().

• Keep a partial view of the menu and render it from the layout view. The data is fetched in the menu view from a static method placed somewhere else (possibly in a model). This involves writing very little code, but I’m not sure if it’s good practice for the MVC paradigm. Fetching the data in the view makes me cringe a little, even though it’s just calling a static function.

• Turn the menu into a widget. The data is fetched in the run() method and rendered from a widget view. However, using a widget imposes a few additional restrictions. If I want to use the view that renders the latest posts in a controller, I would run into issues. Widgets cannot use renderPartial() and are forced to use render() all the time. I could work around this if I figure out how to check what is rendering the view (widget or controller) and call render() or renderPartial() appropriately. Also, the widget views have to be separate from the site views, but I could work around that by specifying the full view path, like application.views.controller.view, as clunky as it may be. Furthermore, I’m still not sure if widgets should fetch database data by themselves.

All of these methods work, but they all come with a few catches. I’m sure many sites are in the same situation and I’d like to see what the best option is.

Answer 1

You should be able to avoid most of the performance hit for re-requesting this data by simply caching the database results (either in memory or in files it’s up to you and your set up). Here’s a small, simple example:

$posts = Post::model()->cache(600)->with('comments')->findAll(array('blah=blahdyblah'));

This will cache the data returned for 10 minutes.

Here’s a link to the Yii caching guide again only for completeness:
Caching Guide

To actual get this data on every page, you would better off placing the code in your own widget, and having it called somewhere in the layout file.

The widget restrictions you list can be dealt with:

• Firstly when the widget renders it will only render(), but without a layout. This is fine for most cases, but if you do want a page with just that on, say you want a real render(), then do exactly that, just create a view that only calls that widget.

• Secondly, There’s no reason widgets have to be entirely abstracted from your application and not use its data + models. Yes it is a very nice feature that they can be ‘pluggable’, but it doesn’t mean they have to be, you’re just using them to separate code.

• Lastly, if you do want to use ‘some’ of the data from the widget but not all, or change it slightly, the methods and views you use within the widget should be built with just enough abstraction that you can use the pieces you need separately. A good way to do this is to make good use of scopes on ActiveRecords, mini view files, and using components for larger chunks of non-data logic.

Of course if you’re running really on the limit of performance and need to trim thousandths of a second off your request time then you should be looking into view caching and using fragment caching of views: