Hy,
I was thinking that all my website will have use of cells, using the known plugin cell for rails, so this is my idea:
A table that contains 3 fields: id, view_name and layout. the layout will be a serialized hash.
When a request is made, the layout field is requested and then in the view, default layout, will be unserialized the layout var, that looks like this:
@layout[:sidecol][:gallery] = {… some params for it…};
@layout[:maincol][:comments] = {..params…};
In the <% #ruby code to render the cells in the @layout[:sidecol] %> will be some ruby code that will loop over the @layout[:sidecol] and render all cells in it. the same occurs in the maincol div.
What do you think?
Positive in my opinion:
More modular
controller is used only for post
easy change of structure
easier to implement some kind of traking to see diferences on what layout is better or not.
Negative:
not found yet
EDIT:
1) The request comes, is calculated the view name.
2) Load from the database the layout field that corresponds to the view name. (this will be cached, and will be updated only when changes are made. I intend to use this way, because I will need to test the layout. 33% layout1, 33% layout2 and 33% other layout. So will be used a random number to choose the view layout.)
3) The layout field contains: first subdivision is the name of the div to be created, then in each one will be more components, named cells in this case, that will be instanced in the application controller, because will be repeated for all get requests.
4) In the view will be created the divs and will be rendered in each one the cells defined.
5) The cell will make the request to the db and load the data.
6) The cell will then render the HTML and is ready to go!
So… in discussing MVC, you should understand that the controller layer is probably the most critical of any of the layers for actually accomplishing tasks. The controller layer is intended for actually getting any work done within your framework.
There are ways to abandon monolithic MVC as your primary pattern, for example, building a set of services which communicate with each other, but even there, that’s mainly abandoning monoliths, since you can push the MVC pattern down into each component.
With regard to your specific proposal, storing layout data, which seldom changes between requests, in your DB is an unnecessary performance hit. Having to drag the layout from your DB out, unserialize it and run it will require you either to set up a caching framework, or to do crazy DB scaling.
Incidentally Rails3 and Merb (and i think even Rails2) are sufficiently modular in the controller layer, that they don’t really care where your layout/templating/view stuff comes from. If you really want, you can just tell them to render a string.