Controllers pass data to Views through assigns (and possibly other things like session, etc). In at least some cases, I am faced with a choice of passing one "large" object, which might require the view to have "more ruby code" to extract what data they really need (such as @foo.bar.color.code, @foo.title) [let''s call it ''heavy assigns''], or passing more "smaller" objects (such as @code, and @title) [let''s call it "light assigns"] The latter obviously means more work in the controller, and possibly more flexibility in the usage of the view. The former means a more complex view. I''m sure that there is no absolute answer, and there are different forces pulling in each direction. My questions are: 1) how do *you* make this decision? 2) what guidelines do you have/follow for this? 3) what *are* the forces that pull in one direction or the other. David
David Corbin wrote:> Controllers pass data to Views through assigns (and possibly other things like > session, etc). In at least some cases, I am faced with a choice of passing > one "large" object, which might require the view to have "more ruby code" to > extract what data they really need (such as @foo.bar.color.code, @foo.title) > [let''s call it ''heavy assigns''], or passing more "smaller" objects (such as > @code, and @title) [let''s call it "light assigns"] > > The latter obviously means more work in the controller, and possibly more > flexibility in the usage of the view. The former means a more complex view. > > I''m sure that there is no absolute answer, and there are different forces > pulling in each direction. My questions are: > 1) how do *you* make this decision? > 2) what guidelines do you have/follow for this? > 3) what *are* the forces that pull in one direction or the other. > > DavidIf the view is going to make extensive use of several object properties, what usually happens with ActiveRecord ones, by all means, pass the whole object, specially if the view presents data selectively. As for making views complex, sometimes presentation logic can be inherently complex and there''s little escape for that. As a general rule, factor all complicated presentation logic to the view helpers and keep the .rhtml templates really simple. Hope that helps. rgds Dema -- http://dema.ruby.com.br - Rails development from a .NET perspective
On Jun 1, 2005, at 2:57 AM, David Corbin wrote:> Controllers pass data to Views through assigns (and possibly other > things like > session, etc). In at least some cases, I am faced with a choice of > passing > one "large" object, which might require the view to have "more ruby > code" to > extract what data they really need (such as @foo.bar.color.code, > @foo.title) > [let''s call it ''heavy assigns''], or passing more "smaller" objects > (such as > @code, and @title) [let''s call it "light assigns"]Since I''m usually sending AR objects back and forth, and use the form helper tags, I''m in the habit of flattening out object hierarchies for the view. So if I have @user.profile, and I want the view to render an edit form, I assign @user and @profile to separate variables for the view. Then I can have form fields like <%= text_field ''user'', ''username'' %> and <%= text_field ''profile'', ''first_name'' %>. At first I thought it was tedious to have to pick the objects apart like that, but now I''m used to it and find myself doing the same for non-AR objects. For example, I have a search system where the search parameters are sent to the controller in @params[''search''][''first_name''], etc., and a Search class that can take a hash of parameters to initialize. Zach