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! -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Sep 1, 2006, at 4:14 AM, Stephen Bartholomew wrote:> >> 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, > > SteveHey 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
How do you think Ezra''s approach would compare to the following other two ways I can think of to do this: 1) Using a plugin with named_routes added in the init.rb (no example as yet) 2) Joining a plugin''s controller to your app directory and manually adding routes (http://blog.caboo.se/articles/2006/06/11/having-your-plugins-and-eating-them-too ) 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 On 9/1/06, Ezra Zygmuntowicz <ezmobius-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > > On Sep 1, 2006, at 4:14 AM, Stephen Bartholomew wrote: > > > > >> 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 > > 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 > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
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 On 9/2/06, Steve Longdo <steve.longdo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> How do you think Ezra''s approach would compare to the following other two > ways I can think of to do this: > > 1) Using a plugin with named_routes added in the init.rb (no example as yet) > 2) Joining a plugin''s controller to your app directory and manually adding > routes > (http://blog.caboo.se/articles/2006/06/11/having-your-plugins-and-eating-them-too > ) > > 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 > > > On 9/1/06, Ezra Zygmuntowicz <ezmobius-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > On Sep 1, 2006, at 4:14 AM, Stephen Bartholomew wrote: > > > > > > > >> 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 > > > > 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 > > > > > > > > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---