Topic: On performance and multiple controllers

When creating a webapp that involves multiple but logically distinct components, it is good design to keep the respective controller code separate from each other as well.  For example, it doesn't make sense to throw logic that deals with stock tickers into the same controller that deals with weather patterns and a forum, simply because you want to display these things together on the same aggregation page.  Given that premise, it makes sense for an aggregator viewer to assemble various pieces together for final display to the user.

To date, I've seen 2 approaches that deal with this, and I'm not entirely satisfied with either of them.

Approach 1: use render_component
Approach 2: use Ezra Zygmuntowicz's cells plug-in (svn co http://svn.devjavu.com/cells)

Approach 1
Is slow according to many, including Ezra:

Re: On performance and multiple controllers

There is approach 3. Share your "controller" code in the /lib directory and use partials.

And approach 4. Create an Engine. I hesitate to recommend this, as Rails Core occasionally does things like vary the load order of plugins, which can break Engines.

Right now, the self-contained widget with behavior ala .Net components is not a problem that is adequately addressed in Rails. In fact, I'm not sure it's on anybody's radar.

Re: On performance and multiple controllers

It is interesting to me that this isn't really on anyone's radar.  I'm not sure why this would be.  I know there are alot of "single function" websites out there.  You know:  "online store", "forums", "wiki-thingie", "share your picture", etc.  Then there are full-blown CMS-es (some written in ruby, some even on rails), but typically there is way to much stuff there for my taste, and I don't want all of it (or most of it).

I think I'll investigate approach 3 a bit more.  I'm guessing there is some reasonable code structure that can make a light-weight widget-set functionality possible that fits in with the typical rails way of thinking.  If so, I'll need more help than "use libs".  I see for example how acts as authenticated does things, but it still relies on code in the main controller to deal with request & response portion of user interaction. 

Like most people -- I'm new to ruby and rails (newbie on rails!), but I've done a lot of software architecture.  So I kind of know what I want (and why I want it), but not sure what the most sane way of going about it is.  I hope I can bounce some ideas off of people here.

Approach 3, sounds like a good idea, though I'll need to understand this a bit more.  It seems to me a controller is ultimately responsible for assembling the information together, and the view is responsible for formatting the information.  Partials, used via render :partial, can grab any information that the controller prepared for it (along with session and  the typical browser headers). 

The question then is how do you organize the interplay between partials and controller code residing in libs that grant me a reasonable level of isolation / abstraction, and how do you structure the "main" controller that decides which "widgets" will be getting displayed, and then run the respective widget controller code, which in turn interact with model code if required, to pull data together for eventual display (via render :partial).

The same question should be asked with the response side of things.  Controllers are responsible for responding to actions, and updating the views.

I'm not interested in complicating things too much.  I want to fully embrace the "rails way", and I want to ensure that I can pull in plug-ins or whatever else others come up with, without requiring adjustments simply to be able to use the components in a "widget".

At the same time, it seems completely silly to me to require all controller code to essentially reside in the same object, simply because it might be displayed in the same browser page.  If you're dealing with a "single application" per page style of website, that makes fine sense.  But the minute you want to mix it up, it makes very little sense.

People say (rails book rev2) that instead of using render_component, it's "cleaner" to use partials and before_filters.  I need to understand where the before_filters come in, and how that concept could be leveraged to clean things up I guess.  I know that code associated with a before_filter is run before any method of the controller is run, but I fail to see how that really improves anything from a clean architecture stand point.  I'm probably missing something.

So let's say I've got a set of widgets that may or may not need displaying on a page.  Would it make sense to have a master controller that first decides what content needs to be displayed, and then calls a subset of the widget controllers, each of which might call a render :partial?

If the user manipulated something on one of the widget, how would the ajax call (or normal post request) be made to the main-widget controller so that it would know which widget method to call?

Is this essentially what engines try to solve?  I hear engines are "not sanctioned" by the core team, though I'm not sure about that.  It's just the feeling I get from reading some articles on Rails Engine: http://rails-engines.org (http://rails-engines.org/news/2006/08/3 … till-evil/).

There is so much to love about rails.  But the website I want to implement does have many functional components that are logically seperate (they may have some underlying shared models / connections).  To give you an idea, it's a game related website, and it will have:

* forums
* wiki-like manual and player-guides
* community driven artwork collective
* top-10 / statistics listings across many different categories including: in-game stuff, advertising stuff, contribution stuff
* server-listings that you can launch the game from
* online chat area
* squad wars (admin, reminders, top-squads, etc)
* dueling stats and top-duelers

Most of the above can easily be handled in the typical main-application page per controller, but the sticky point is how can I throw in other information and "widgets" that really ought to reside on other main-application controllers?  For example, the forums will mostly just be about posting and replying to other posts.  But at the same time I may also want to mix-in other information.  Top-10 players, who is in the game servers, etc.  Or maybe if there is an outstanding request for duel.

I don't want to be limited with what information I can put up on a single page.  For example, I'd like to have an "ego" page, that is all about the player.  Say the user is already authenticated and they go to base URL of the website... I'd like to throw up a page that is just about them:  Where do they stand, what's their stats like?  But also, have a list of messages that got responded to in the forums, Also some quick-links to launch the game right away, and on the same page, maybe have a few top-10 lists of other players.

I don't want the architecture to limit how I can mix the information together to the end user.  If I wake up one morning, and want to add quick-links to launch the game from the forums page, why shouldn't I be able to just add a single line of code to get that "widget" in there?

Last edited by Slurpy (2006-11-18 15:14:03)

Re: On performance and multiple controllers

Typically "widgets" are feature poor but shared -- for example a horizontal menu. These are great for partials, and can rely in great measure on either controller code shared in application.rb or in the controller of your choice (remember, you can use :controller => in your link_to).

Feature-rich widgets can be difficult to set up and often cause subtle bugs or bloat stemming from trying to be all things to all people.

Re: On performance and multiple controllers

Look over http://wiki.rubyonrails.org/rails/pages/Rails+Widgets. You might find this approach more to your liking. Before you invest too much time in it, know that these Widgets haven't gotten much traction in the Rails community AFAIK.