I could just move all the necessary code out of the blog controller (i.e. public-facing actions like index and list) and into the web pages controller, but that hardly seems elegant.
I would argue that you may have this about face. If a page *could* act like a blog article, that suggests that you should have just have one type of page - Page - that *can* have extended properties. In that case you would just have one Pages controller.
Components are considered bad practice and favourable alternative is using partials. If partials don't seem to be fitting your need, it's quite possible that something is awry in your application design, as discussed above. You shouldn't really need to have 2 controllers in the example you gave.
I am working on a plugin for this exact purpose. render_component does suck hard and is way slow because it has to instantiate a whole new request/response and controller object. But I do think there is a need for a light weight way of making small ajax applets or page parts that can get rendered in a view in a similar way to render_component without all the baggage but also need to be able to handle ajax callbackls in the controller. So I have a plugin called 'cells' that aims to solve this problem. I haven't released it anywhere yet but you can grab it form svn and see what you think.
It works by piggybacking off of ActionController::Base or ActionView::Base depending on whether its handling a request or whether it is being rendered within another view sort of like a component. Keep in mind that this plugin is not about sharable betweek apps reusable high level components that everyone hates. Cells are about encapsualting small page parts and giving them a way to remain independent from other controllers. Using this technique you can accomplish something akin to render_component in a view, only its around 21 times faster It also makes you add only one ActionController c lass to you app. This controller is a dispatcher for all your cell controllers. Each cell is a small MVC stack that lives in its own folder. So in your app you add a directory called RAILS_ROOT/app/cells. And in cells/ you can have your cell's views, models and mini controller.
Here is the svn url. It is a full rails app with a small todolist sample 'cell' included so you can see how it works. PLay with it and lt me know how it works for you. When i get some more time I will make a it a more genrally available plugin. I am getting a lot of good use out of it and I think it solves a problem that a lot of folk struggle to do in a clean way with rails.
Seems like Ezra’s method adds another place to keep track of versions outside of the plugins directory, but I imagine it has a smaller memory footprint overall.
I think it would be helpful for all of us that came from MVC frameworks
that happily support and even encourage component oriented design, to
better understand HOW we should be rewriting reusable components without
using render component. If there’s a good rails pattern for it, what is
it?
Indeed, I would like to know too. I’ve switched to partials instead of components a while ago, but it’s not really a component. A component was nice because you could just use a copy in a new project, effectively building your app from the needed components (and some extra).
Rock on, Ezra! I think this is perfect. It's exaclty what I've been
needing. I want to build a page of ajaxy modules that give status on
different sections of the site, and allow some interaction. I wanted
to be able to keep them somewhat self-contained, like a plugin, but
with controller functionality for the ajax calls. And Engines just
felt too heavy-weight. And course components are out.
I think you should go ahead and package it up into a plugin, and
release it. But thanks for giving the link to it now.
Honestly, I think plugins should grow up a little bit more to provide
this level of functionality. But that's just my opinion.
I don't buy the argument that there's a flaw in your application design
if you need to use render component,
I didn't mean that components are not useful - I just feel that quite often people jump to components to solve a problem when a simpler application design might be appropriate. I particularly felt this with the original posters problem. My suggestion was to rethink the page/blog post design as it sounded like the application would get unnecessarily messy.
When I first started using Rails, I used components where partials would be more than enough. As such my recommendation is always "is this really the best way to do it?". As has been said before, components were not extracted from a real-world need.
However, Ezra's solution is looking pretty cool. It'll be great to see it in wider use as these discussions have shown that there is a real-world need in certain cases.
It also makes you add only one ActionController c lass to you app. This controller is a dispatcher for all your cell controllers. Each cell is a small MVC stack that lives in its own folder. So in your app you add a directory called RAILS_ROOT/app/cells. And in cells/ you can have your cell's views, models and mini controller.