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: "render_component does suck hard and is way slow because it has to instantiate a whole new request/response and controller object". Approach 2 I downloaded and tried, and it seems to work nicely. I do have several issues with it, though: The controller code that is associated with a cell goes into Cell::Base class, which in turn contains a reference to the widget controller via (@controller), but isn''t a controller object itself. The problem this creates is that other plug-ins (or generators) don''t play nicely with code in Cell::Base, because they often rely on being used in an ApplicationController object. So while I like the idea of cells, if I can''t easily pull in other functionality into my project without having to rewrite a lot of it. I have not tried it yet, but I''m guessing for example that if I wanted to throw in an ajaxscaffold (http://www.ajaxscaffold.com) into a cell, that would end up not working very well, but ajaxscaffold might sure fit the bill for some of the widgets I''d like to implment. The other issue with Approach 2 is that I don''t see it getting much notice, and don''t know if it will fall by the way-side. I may well be missing a third alternative. Please let me know if I am. I''m not looking for an argument about why I''d like to keep logically separate controller code in different controller objects. What I am looking for is some reasonable direction for me to go in. I''m not looking to write re-usable Components (code that would go into app/components), but I am looking for a framework that allows for a conceptually clean architecture that does not impose extra performance problems and will play nicely with most other generators or plugins). --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
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: "render_component does suck hard and is way slow because it has to instantiate a whole new request/response and controller object". Approach 2 I downloaded and tried, and it seems to work nicely. I do have several issues with it, though: The controller code that is associated with a cell goes into Cell::Base class, which in turn contains a reference to the widget controller via (@controller), but isn''t a controller object itself. The problem this creates is that other plug-ins (or generators) don''t play nicely with code in Cell::Base, because they often rely on being used in an ApplicationController object. So while I like the idea of cells, if I can''t easily pull in other functionality into my project without having to rewrite a lot of it. I have not tried it yet, but I''m guessing for example that if I wanted to throw in an ajaxscaffold (http://www.ajaxscaffold.com) into a cell, that would end up not working very well, but ajaxscaffold might sure fit the bill for some of the widgets I''d like to implment. The other issue with Approach 2 is that I don''t see it getting much notice, and don''t know if it will fall by the way-side. I may well be missing a third alternative. Please let me know if I am. I''m not looking for an argument about why I''d like to keep logically separate controller code in different controller objects. What I am looking for is some reasonable direction for me to go in. I''m not looking to write re-usable Components (code that would go into app/components), but I am looking for a framework that allows for a conceptually clean architecture that does not impose extra performance problems and will play nicely with most other generators or plugins). --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---