On Nov 17, 2007, at 12:03 PM, Tom Norian wrote:
> I can easily use if else conditions in a view.
>
> <% if condition_one %>
> <div class="editing_existing_object_form">
> ....
> </div>
>
> <% else %>
> <div class="form_for_new_object" >
> ....
> </div>
> The issues:
>
> 1: Not supposed to put too much logic in views?
With some guidelines, "too much" is up to you IMO. Seems like the
mood of the gurus these days is for short routines so that you can
have one master routine call a bunch of short routines. That way you
have one place to read a succinct description of the steps of the
logic flow, and you can go look at details one at a time. I find this
to be an effective pattern.
While that is often discussed for logic, I believe it applies to
views as well. I like my actual view file to be the description of
the logic flow of the view (if there is one) -- which means when it
is complex enough, it includes a bunch of partials. Not so much for
the reusability, just the ability to break the process or the overall
makeup of the view down into a simple story.
Sometimes a bunch of files feel annoying for sure when you''re doing
your first pass at the work, but when the app has been running for 6
months then you go back to it, a couple hundred lines of view code
intertwined with a bunch of logic which actually controls what shows
up and what does not -- its going to take you a while to deduce
what''s going on.
What I do is start by putting everything in one file, one action. I
don''t really know where it will make sense to break it up until I see
it closer to being finished. Plus as you say, it''s easier to work
with all in one place. So, I start with one file, and then when done,
I break it into pieces. You have to be aware that right now as you''re
writing the code, you have all your vars, logic, and decision
justifications in your head. You can see through all noise of the
code. In 3 months you won''t have that. It''s at that time that
you''ll
appreciate the breakdown of it into pieces.
> 2: My the action that calls the page creates instance variables for
> both the desired and undesired display items and has been getting a
> bit
> tricky assuring that I don''t do a find on a nil object ...
>
> Is it perfectly fine to use if/else clauses and complicated actions to
> create display pages or should I bite the bullet and create lots of
> clean html views and lots of separate actions, one for each
> contingency?
IMO, nothing wrong with conditional logic inside one action to
determine what needs to be displayed. but follow that pattern above.
Use the action method to outline the steps of what has to happen, and
put the details of the work into seperate (protected or priviate)
methods.
I build a lot of non-Ajax admin-type pages where editing a model
involves a series of on-screen forms. I use one action which handles
everything. The action method has a decision tree based on which
button was clicked in the UI -- that dictates what logic has to be
performed and which view pieces will be assembled.
For a simplistic illustration, let''s assume we have a series of three
forms: Signup, Details, Summary. Each form has a Save button, a
cancel button, and nav buttons to allow me to jump to any of the
three forms. Off the top of my head, so...
----------------------------------------------
def signup_manager # this is our :action
if params.has_key?(''btnViewSignup.x'')
@displayMode = ''showSignup''
self.prepSignup
elsif params.has_key?(''btnViewDetails.x'')
@displayMode = ''showDetails''
self.prepDetails
elsif params.has_key?(''btnViewSummary.x'')
@displayMode = ''showSummary''
self.prepSummary
elsif params.has_key?(''btnSave.x'')
@displayMode = ''showSummary''
self.saveForm
elsif params.has_key?(''btnCancel.x'')
@displayMode = ''showSignup''
else
@displayMode = ''showSignup''
end
end
protected
def showSignup
# do stuff to prep the view
# for showing the Signup form
end
def showDetails
end
def showSummary
end
def saveForm
use the
end
----------------------------------------------
In the view
<% form_for :thisUser, :url => {:action => :signup_manager} do |form|
%>
<%= render(:partial => "navTabs", :locals => {:thisUser
=>
@thisUser}) rescue nil %>
<%= render(:partial => "formControl", :locals =>
{:thisUser =>
@thisUser}) rescue nil %>
<%= render(:partial => @displayMode, :locals => {
:form => form,
:thisUser => @thisUser) rescue nil %>
<% end %>
----------------------------------------------
So, I don''t have the kinds of conditionals you''re talking
about in
the view, but see how the @displayMode variable can be used to
dictate which partial will be included in the view? All the
conditional logic is pushed into the controller. Keeps the view clean.
Also, even if I never reuse the navTabs or the formControl partials
elsewhere, but breaking the view into a series of partial renders,
it''s easy to geta glimpse of the display chunks.
Back up in the controller, the decision tree (which can be done
better for more complex abstracted cases, but this is just a
quickie), provides a wuick overview of the logic, and the details of
the tasks to be done as a result of clicking a button is pushed into
separate methods.
This isn''t the cleanest example, but maybe it gives you some ideas
how to break your stuff up.
Also, have a look at this article for ideas on dealing with views,
partials, and layots:
http://www.railsdev.ws/blog/3/modular-page-assembly-in-rails/
-- gw (www.railsdev.ws)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---