I see in the new Agile Rails 2nd edition that components are going out of style? Is this so? has anybody abandoned the idea of components for helpers? Specifically I''m considering a menu sytem for a website that depends heavily on the users permissions to decide which menu options a user would need to see. I thought that components, since they have the logic in the controller and view in another file would be a good use of components. any input? -- Posted via http://www.ruby-forum.com/.
On 5/24/06, Nola Stowe <nstowe@thorntontomasetti.com> wrote:> > > Specifically I''m considering a menu sytem for a website that depends > heavily on the users permissions to decide which menu options a user > would need to see. I thought that components, since they have the logic > in the controller and view in another file would be a good use of > components.That may be a good seperation of concerns but it would be really slow. Components are performance hogs, apparently. I''ve heard plugins proposed as a replacement, but I don''t know how plugins implement views and routing. Anyone? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060524/85ba5a23/attachment.html
> I see in the new Agile Rails 2nd edition that components are going out > of style?The problem with components is that they''ve never actually _been_ in style. We just forgot to tell people that. Our bad, now being rectified.> Is this so? has anybody abandoned the idea of components for helpers? > > Specifically I''m considering a menu sytem for a website that depends > heavily on the users permissions to decide which menu options a user > would need to see. I thought that components, since they have the logic > in the controller and view in another file would be a good use of > components.I''d just make a helper that depends on an interface of a user model, but is not bundled with it. So you rely on the fact that the user model will have user.have_access_to?(section) or similar. Optionally, you wrap it in a plugin that also includes a permissions include, so you can do class User; include Permissions; end to get the methods you need. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
> I''ve heard plugins proposed as a replacement, but I don''t know how plugins > implement views and routing. Anyone?In general, the position is that trying to make components with views is not recommended. Instead, try to abstract the logic behind the views into easy-to-use plugins such that using custom views will be easy as pie. If you for some reason can''t come to terms with this, I believe the engine guys are there to help you out. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
I can see the logic behind moving away from components, but seeing as i''ve been using them for a while, i''d be grateful for quick example of the alternative. If I have a shopping basket view that is shared in 2 places - say the basket view page and a confirm order page. I would (normally) create a controller action with an associated view and call it in the respective basket/checkout views. What would be the correct way to implement this without using the component? Advice and/or api/site links would be mucho appreciated :0) Steve David Heinemeier Hansson wrote:>> I see in the new Agile Rails 2nd edition that components are going out >> of style? > > > The problem with components is that they''ve never actually _been_ in > style. We just forgot to tell people that. Our bad, now being > rectified. > >> Is this so? has anybody abandoned the idea of components for helpers? >> >> Specifically I''m considering a menu sytem for a website that depends >> heavily on the users permissions to decide which menu options a user >> would need to see. I thought that components, since they have the logic >> in the controller and view in another file would be a good use of >> components. > > > I''d just make a helper that depends on an interface of a user model, > but is not bundled with it. So you rely on the fact that the user > model will have user.have_access_to?(section) or similar. Optionally, > you wrap it in a plugin that also includes a permissions include, so > you can do class User; include Permissions; end to get the methods you > need.
On Wednesday, May 24, 2006, at 5:28 PM, Nola Stowe wrote:>I see in the new Agile Rails 2nd edition that components are going out >of style? > >Is this so? has anybody abandoned the idea of components for helpers? > >Specifically I''m considering a menu sytem for a website that depends >heavily on the users permissions to decide which menu options a user >would need to see. I thought that components, since they have the logic >in the controller and view in another file would be a good use of >components. > >any input? > >-- >Posted via http://www.ruby-forum.com/. >_______________________________________________ >Rails mailing list >Rails@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/railsI recently implemented something like this with a partial. In my case, I am also using the user/login engine combo, so I can do a ''link_if_authorized'' or ''authorized?'' block around sections of the menu html. It seems to work reasonably well, but I haven''t tested it for performance. _Kevin -- Posted with http://DevLists.com. Sign up and save your mailbox.
> I can see the logic behind moving away from components, but seeing as > i''ve been using them for a while, i''d be grateful for quick example of > the alternative.I''ll post the code here: class ShopController < ActionController::Base before_filter :set_cart def index @products = Product.find(:all) end def buy @cart << Product.find(1) redirect_to :action => "index" end private def set_cart @cart = Cart.find(session[:cart_id]) end end ...and here''s the index.rhtml view: <h1>My Magic Shop!</h1> <div id="products"> <%= render :partial => "product", :collection => @products %> </div> <div id="cart"> <%= render :partial => "cart" %> </div> The new Rails book has the full argument and justification as to why this is the recommended approach instead of components. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
Oh right - that''s much better :0) I''ve been using a mix of partials and components but now i think about it there isn''t really a need to. My romantic attachement to paper books has stopped me upgrading my ''Agile'' book but it''s looking more of a necessity now :0) Cheers, Steve David Heinemeier Hansson wrote:>> I can see the logic behind moving away from components, but seeing as >> i''ve been using them for a while, i''d be grateful for quick example of >> the alternative. > > > I''ll post the code here: > > class ShopController < ActionController::Base > before_filter :set_cart > > def index > @products = Product.find(:all) > end > > def buy > @cart << Product.find(1) > redirect_to :action => "index" > end > > private > def set_cart > @cart = Cart.find(session[:cart_id]) > end > end > > ...and here''s the index.rhtml view: > > <h1>My Magic Shop!</h1> > > <div id="products"> > <%= render :partial => "product", :collection => @products %> > </div> > > <div id="cart"> > <%= render :partial => "cart" %> > </div> > > The new Rails book has the full argument and justification as to why > this is the recommended approach instead of components.
On 5/24/06, Stephen Bartholomew <sb@2404.co.uk> wrote:> My romantic attachement to paper books has stopped me upgrading my > ''Agile'' book but it''s looking more of a necessity now :0)Noooooo! That''s the dark side talking to you, don''t listen. I got my email about the update for 2nd Edition last night. Due to my position in the queue I had to wait an entire 16 minutes for the gerbils to pump out my copy, but...damn... It was worth the wait... I''m not far enough into 2nd Edition yet, so I appreciate DHH dropping the code here (since I''ve been struggling with this issue as well--in relation to multiple apps sharing the same user tables and "user dashboard" view). I look forward to reading more in the book though. :) I see now that it would be best to render the user dashboard via a partial that just gets dumped into the view. Maybe even in the layout... It''s on nearly every page...and if it shouldn''t be I could even utilize "display:none" for the user dashboard div... Probably not perfectly clean...but...meh... I''m curious to see how the menu gets rendered, I would imagine that''s in the form of a partial called from the layout, but I could be wrong. That may be an alternative way to do it. Perhaps some code that checks for the existance of a hash object and renders a partial if it''s there, or skips it if not (that could even be part of the partial too, I suppose, so you wouldn''t have to recode that in every view that *might* use it). Faster than components, and flexible enough if it''s not needed (just ensure it''s null in the controller).
> Noooooo! That''s the dark side talking to you, don''t listen.Well i''ve got over it and just bought the PDF of the 2nd edition. I''m not waiting until september for the paper version :0) Oddly enough, i can''t actually find any reference to the deprecation of components - the section on using components is still there. The section at the beginning about sharing the cart view across with the checkout however is not - i''ll have to have full read through i think. I did however, realise (i think) what i should be doing. If i want to display a list of links pages stored in the db for example, i create a method in app/helpers/application_helper.rb called page_menu: application_helper.rb ... def page_menu @pages = Page.find(:all) end ... Then i create a partial: _page_menu.rhtml ... <% page_menu %> <ul> <% @page.each do |page| %> <li><%= page.url %></li> <% end %> </ul> ... This partial can then be used in other templates ... <%= render :partial => ''page_menu'' %> ... Now this seems kinda cool because it would mean that i can use the helper method in different partials that use the same data (say, two cart view partials, one with form elements, the other a straight display). However, i don''t trust my own solution so it would be great if someone could clarify this for me :0) Cheers Steve Curtis wrote:> On 5/24/06, Stephen Bartholomew <sb@2404.co.uk> wrote: > >> My romantic attachement to paper books has stopped me upgrading my >> ''Agile'' book but it''s looking more of a necessity now :0) > > > Noooooo! That''s the dark side talking to you, don''t listen. I got my > email about the update for 2nd Edition last night. Due to my position > in the queue I had to wait an entire 16 minutes for the gerbils to > pump out my copy, but...damn... It was worth the wait... > > I''m not far enough into 2nd Edition yet, so I appreciate DHH dropping > the code here (since I''ve been struggling with this issue as well--in > relation to multiple apps sharing the same user tables and "user > dashboard" view). I look forward to reading more in the book though. > :) > > I see now that it would be best to render the user dashboard via a > partial that just gets dumped into the view. Maybe even in the > layout... It''s on nearly every page...and if it shouldn''t be I could > even utilize "display:none" for the user dashboard div... Probably > not perfectly clean...but...meh... > > I''m curious to see how the menu gets rendered, I would imagine that''s > in the form of a partial called from the layout, but I could be wrong. > That may be an alternative way to do it. Perhaps some code that > checks for the existance of a hash object and renders a partial if > it''s there, or skips it if not (that could even be part of the partial > too, I suppose, so you wouldn''t have to recode that in every view that > *might* use it). Faster than components, and flexible enough if it''s > not needed (just ensure it''s null in the controller). > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
Stephen Bartholomew wrote:> Well i''ve got over it and just bought the PDF of the 2nd edition. I''m > not waiting until september for the paper version :0) > > Oddly enough, i can''t actually find any reference to the deprecation > of components - the section on using components is still there. The > section at the beginning about sharing the cart view across with the > checkout however is not - i''ll have to have full read through i think.I haven''t actually gotten to that part in the full book yet, and maybe part of it is still being rewritten, but in the Intro portion it does have a "Change Log" section which highlights the new Depot application and some of its changes. One of the bulleted portions reads: ? It uses partials, rather than components (as components seem to be on their way out). So... There you go! Heehee... Seriously though, I honestly expect that the code DHH posted earlier (I think to this thread even, but my brain may be playing tricks on me) was probably taken straight from the book. :) I''m liking the new book so far...several code snippets seem to do pretty much exactly what you typed in the previous message. Also, I selfishly downloaded the code from the FamilyConnection project (mentioned in another thread). It runs through some similar things in the main layouts. It goes even further though. It has a custom method "render_partials_array()" (or such) which loops through an array of partials and renders them. This is set during various aspects of a page''s living (typically in the controller, from what I''ve seen) and very elegantly (in my opinion) resolves the side-menu content depending on the role of the current user (guest, user, admin, etc)... For anyone confused about partials, I recommend checking it out. It seems a good way to do it. :) -Curtis
Yeah - i''ve got through the partials section the new depot app. It doesn''t address the issue i had but generally i''m loving the updates to the 2nd edition so far - worth the re-investment :0) The problem (with regards to the issue i had) with the example in the depot app, is that it doesn''t seem to explain how logic code can be used in partials (not a problem for the example obviously, but it''s a sticking point if you want to do anything more complex). For example: You have a cart display on the cart page and the same thing repeated on the order confirm page. This was in the 1st Agile book implemented using a component, but is not in the 2nd edition. In the 2nd edition, a cart preview is implemented using a partial: --- views/store/index <%= render :partial => ''cart'', :object => @cart %> --- controllers/store_controller def index @cart = session[:cart] end --- views/store/_cart.rhtml <% @cart.items.each do |item| %> --- This is fine for this example. But if you try and do the ''cart displayed on order confirm'' i mentioned above, it gets a little messy: --- views/checkout/confirm_order.rhtml / views/cart/view.rhtml <%= render :partial => ''cart/cart'' %> --- views/basket/_cart.rhtml <% @cart.items.each do |item| %> --- In order for this to work, we would need to pass the @cart object to the partial in each respective view, like this: --- views/checkout/confirm_order.rhtml / views/cart/view.rhtml <%= render :partial => ''cart/cart'', :object => @cart %> In order for @cart to be available in the views, it would need to be assigned in both the CartController::view and CheckoutController::confirm_order actions - this seems at risk of repetition. I''ve implemented it by creating a helper method that the partial uses (mentioned in my last post) - but that seems a bit un-rails-y and i found it had an issue when i tried to assign something from the session. I guess you could also create a method that the controllers could use globally to assign this kind of thing: --- cart controller def view get_cart_view end --- checkout controller def confirm_order get_cart_view # other stuff end --- application controller def get_cart_view @cart = session[:cart] end ... but again something about that isn''t right :0) Man, that was a bit of a ramble - think i''ll have to write this all up in a difinitive tutorial when i discover the ''right'' way :0) I have a slight feeling of ''barking up the wrong tree'' though... Cheers, Steve Curtis Spendlove wrote:> Stephen Bartholomew wrote: > >> Well i''ve got over it and just bought the PDF of the 2nd edition. I''m >> not waiting until september for the paper version :0) >> >> Oddly enough, i can''t actually find any reference to the deprecation >> of components - the section on using components is still there. The >> section at the beginning about sharing the cart view across with the >> checkout however is not - i''ll have to have full read through i think. > > I haven''t actually gotten to that part in the full book yet, and maybe > part of it is still being rewritten, but in the Intro portion it does > have a "Change Log" section which highlights the new Depot application > and some of its changes. One of the bulleted portions reads: > > ? It uses partials, rather than components (as components seem to be > on their way out). > > So... There you go! Heehee... Seriously though, I honestly expect that > the code DHH posted earlier (I think to this thread even, but my brain > may be playing tricks on me) was probably taken straight from the book. > :) I''m liking the new book so far...several code snippets seem to do > pretty much exactly what you typed in the previous message. > > Also, I selfishly downloaded the code from the FamilyConnection project > (mentioned in another thread). It runs through some similar things in > the main layouts. It goes even further though. It has a custom method > "render_partials_array()" (or such) which loops through an array of > partials and renders them. This is set during various aspects of a > page''s living (typically in the controller, from what I''ve seen) and > very elegantly (in my opinion) resolves the side-menu content depending > on the role of the current user (guest, user, admin, etc)... For anyone > confused about partials, I recommend checking it out. It seems a good > way to do it. :) > > -Curtis > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >
> In order for @cart to be available in the views, it would need to be > assigned in both the CartController::view and > CheckoutController::confirm_order actions - this seems at risk of > repetition.That''s where the wonders of filters come in. Abstract to something like set_cart, just like the code example I had showed. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
Ah right - i getcha. Cheers, Steve David Heinemeier Hansson wrote:>> In order for @cart to be available in the views, it would need to be >> assigned in both the CartController::view and >> CheckoutController::confirm_order actions - this seems at risk of >> repetition. > > > That''s where the wonders of filters come in. Abstract to something > like set_cart, just like the code example I had showed.
Stephen Bartholomew wrote:> Well i''ve got over it and just bought the PDF of the 2nd edition. I''m > not waiting until september for the paper version :0) > > Oddly enough, i can''t actually find any reference to the deprecation of > components - the section on using components is still there. The > section at the beginning about sharing the cart view across with the > checkout however is not - i''ll have to have full read through i think.Be aware that the book is being revised incrementally, so what you have at present is a mixture of second edition pages (with red headers) and first edition pages (with grey headers). Section 19.9, Layouts and Controllers, hasn''t been revised yet. regards Justin
David, I understand that components are going out, but I still think they result in cleaner code than what you''re proposing here and clean and easy to understand code is what rails is all about isn''t it? For example I personally find: 1. Extracting the set_cart out and then mixing it in to all controllers that need it, calling it via a before_filter, and then rendering a partial in all views that need it to be a lot more complicated than: 2. Calling render component in the views that need the component For example, say I want to include a database driven web poll on certain pages. Using the approach you describe would create both controller and view dependencies on my web poll (even though say an article controller really has nothing to do with a web poll). From a pure code perspective, only needing to include the poll via render component just seems so much cleaner. -Todd http://gabrito.com David Heinemeier Hansson wrote:>> In order for @cart to be available in the views, it would need to be >> assigned in both the CartController::view and >> CheckoutController::confirm_order actions - this seems at risk of >> repetition. > > That''s where the wonders of filters come in. Abstract to something > like set_cart, just like the code example I had showed. > -- > David Heinemeier Hansson > http://www.loudthinking.com -- Broadcasting Brain > http://www.basecamphq.com -- Online project management > http://www.backpackit.com -- Personal information manager > http://www.rubyonrails.com -- Web-application framework-- 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 -~----------~----~----~----~------~----~------~--~---
> For example, say I want to include a database driven web poll on certain > pages. Using the approach you describe would create both controller and > view dependencies on my web poll (even though say an article controller > really has nothing to do with a web poll). From a pure code perspective, > only needing to include the poll via render component just seems so much > cleaner.For components where the content is completely unrelated to the rest of the page and operates on different base objects, components of some form may be advantageous. The cart example plays of the fact that in a shop, the prime directive is to buy stuff. Thus, its not a tangential concern, so its very natural that the cart is available most every where. And that''s been the far most common use of components I''ve seen. Where essential pieces of the application, which uses data that the majority of actions operate on (or which uses data that can be fetched from an object which should be available always, like @person.preferences or something), are chopped up. Components unnecessarily complicates such a design and partials are usually a better fit. But when you truly do have a case like the web poll, which is kind of like a portlet, then the problem with render_component is mostly one of implementation. Sounds like Ezra is exploring a way to deal with that doing cells and I''ve even had thoughts of doing something like another, internal HTTP request. In any case, I consider components to be a rare specialty tool. Not a general purpose architect-my-app-after-it kind of tool. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
petermichaux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
2006-Sep-02 16:04 UTC
Re: Components going out of style?
Todd Huss wrote:> David, I understand that components are going out, but I still think > they result in cleaner code than what you''re proposing here and clean > and easy to understand code is what rails is all about isn''t it? > > For example I personally find: > > 1. Extracting the set_cart out and then mixing it in to all controllers > that need it, calling it via a before_filter, and then rendering a > partial in all views that need itIt isn''t complex to use the filters... def ApplicationController private def set_cart @cart end end def CartController < ApplicationController before_filter :set_cart :only=>[:show] def show end end def CheckoutController < ApplicationController before_filter :set_cart :only=>[:confirm_order] def confirm_order end end - Peter --~--~---------~--~----~------------~-------~--~----~ 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 Sat, Sep 02, 2006 at 03:59:17PM -0000, DHH wrote: [...]> But when you truly do have a case like the web poll, which is kind of > like a portlet, then the problem with render_component is mostly one of > implementation. Sounds like Ezra is exploring a way to deal with that > doing cells and I''ve even had thoughts of doing something like another, > internal HTTP request. > > In any case, I consider components to be a rare specialty tool. Not a > general purpose architect-my-app-after-it kind of tool.Last time I investigated this, it looked like everything I wanted out of a component could be obtained by exposing render_component_as_string, but I couldn''t figure out how to do that. Is there a reason that''s a bad idea? -- - Adam ** Expert Technical Project and Business Management **** System Performance Analysis and Architecture ****** [ http://www.adamfields.com ] [ http://www.aquick.org/blog ] ............ Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.aquicki.com/wiki ].............Wiki --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> Last time I investigated this, it looked like everything I wanted out > of a component could be obtained by exposing > render_component_as_string, but I couldn''t figure out how to do > that. > > Is there a reason that''s a bad idea?Currently, I believe components just have some performance issues. I''d encourage you to benchmark with and without to see whether it matters in your case. And then be on the lookout for other/better ideas that we could possibly do this. As well as keeping in mind that components are not a general strategy for compartmentalizing things in Rails, unless they have this portlet-type flavor we''re discussing. --~--~---------~--~----~------------~-------~--~----~ 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 Sat, Sep 02, 2006 at 05:34:08PM -0000, DHH wrote: [...]> Currently, I believe components just have some performance issues. I''d > encourage you to benchmark with and without to see whether it matters > in your case. And then be on the lookout for other/better ideas that we > could possibly do this. As well as keeping in mind that components are > not a general strategy for compartmentalizing things in Rails, unless > they have this portlet-type flavor we''re discussing.Components have had performance issues in EVERY web platform I''ve used, but usually that''s related to the overhead of an additional request/ssi, instantiating the execution stack, or something related. I suspect (but haven''t dug into the code to confirm) that the right way to approach this might be to stick a continuation somewhere in the rendering path to save all of that setup and use it later to execute an additional action/view pair. -- - Adam ** Expert Technical Project and Business Management **** System Performance Analysis and Architecture ****** [ http://www.adamfields.com ] [ http://www.aquick.org/blog ] ............ Blog [ http://www.adamfields.com/resume.html ].. Experience [ http://www.flickr.com/photos/fields ] ... Photos [ http://www.aquicki.com/wiki ].............Wiki --~--~---------~--~----~------------~-------~--~----~ 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 understand why partials should be used instead of components, but how can you set clever instance variables that will be used by the partial? The thing is, I prefer not putting business logic into RHTML Basically, instead of writing the following in a view : <% if(@product.categories.includes?(some_category)) %> <div>blablabla</div> <% end %> I prefer to keep the view clueless about the model relationships and write something like that instead : <% if(@display_some_section) %> <div>blablabla</div> <% end %> With components, you can execute logic and create any instance variables you need before the view gets rendered. That''s what I liked about them. Is there a way to do the same with partials? By the way, what''s your take about writing code like "if(@product.categories.includes?(some_category))" in a view? Do you think it is bad design or is it ok as long as you don''t access the model directly (Product.find(...)) ? -- 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?hl=en -~----------~----~----~----~------~----~------~--~---
You can pass vars to a partial using a render option called :locals which points to a hash of names/values to be available as local vars in the partial. http://api.rubyonrails.org/classes/ActionController/Base.html#M000267 b Frank wrote:> I understand why partials should be used instead of components, but how > can you set clever instance variables that will be used by the partial? > > The thing is, I prefer not putting business logic into RHTML > > Basically, instead of writing the following in a view : > > <% if(@product.categories.includes?(some_category)) %> > <div>blablabla</div> > <% end %> > > I prefer to keep the view clueless about the model relationships and > write something like that instead : > > <% if(@display_some_section) %> > <div>blablabla</div> > <% end %> > > With components, you can execute logic and create any instance variables > you need before the view gets rendered. That''s what I liked about them. > Is there a way to do the same with partials? > > By the way, what''s your take about writing code like > "if(@product.categories.includes?(some_category))" in a view? Do you > think it is bad design or is it ok as long as you don''t access the model > directly (Product.find(...)) ? >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---