I’ve been reading the news that using components in Rails is less than
ideal, but I can’t seem to figure out a good alternative to my current
use of render_component. My situation is this:
I have a CMS setup so that web pages can be created and each is assigned
a pretty url by the admin (e.g. “about” or “services”). This is simple
enough using a web pages controller. However I also have special
functionality that can be assigned to each web page. For example, a web
page could be created and designated to have blog functionality. So in
addition to having the normal customizable attributes of a web page
(like title, headline, url, etc.), it now also displays time-stamped
articles, allows comments, etc. which would naturally be handled by the
blog controller. So this is where I turned to render_component…
The web page controller would find the appropriate web page record in
the database by looking at the url. Then check if that web page record
has any special functionality. If it does, then render_component would
be called to defer to the blog controller.
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.
Any suggestions? Thanks!
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.
Hope that helps,
Steve
On Sep 1, 2006, at 4:14 AM, Stephen B. wrote:
case
Steve
Hey there-
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.
svn co http://svn.devjavu.com/cells
Cheers-
-Ezra
How do you think Ezra’s approach would compare to the following other
two
ways I can think of to do this:
- Using a plugin with named_routes added in the init.rb (no example as
yet)
- Joining a plugin’s controller to your app directory and manually
adding
routes
(Parked at Loopia
)
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.
Thoughts, anyone?
–
Thanks,
-Steve
http://www.stevelongdo.com
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).
Best regards
Peter De Berdt
I don’t buy the argument that there’s a flaw in your application design
if you need to use render component, lots of MVC frameworks support
components specifically because they allow you to create a nice reusable
component that conists of both view and business logic. Partials simply
don’t solve that problem.
Take for example a website poll, if you had to use partials to include
it on certain pages you’d also want to use a before_filter on the
controller to fetch the poll question from the database. This would then
spread the dependency out into the view and controller which is
unnecessarily ugly. It’s much cleaner (from a pure coding perspective)
to simply call render component in the view to fetch and display the
website poll.
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?
-Todd
http://gabrito.com
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.
Cheers,
Brett
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.
Steve