# Best Practices for Views Noobie Q

**URL:** <https://www.ruby-forum.com/t/best-practices-for-views-noobie-q/120516>\
**Category:** Rails\
**Created:** [November 17, 2007, 9:03pm UTC](https://www.ruby-forum.com/t/best-practices-for-views-noobie-q/120516 "2007-11-17T21:03:17Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![tomn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c89c15/32.png) [@tomn](https://www.ruby-forum.com/u/tomn)\
**Post date:** [November 17, 2007, 9:03pm UTC](https://www.ruby-forum.com/t/best-practices-for-views-noobie-q/120516/1 "2007-11-17T21:03:17Z")

</div>

As I’m going along with my application I am realizing I really don’t  
like seperate pages to create and edit different models.

I prefer the user experience of pages with fields for a few related  
models displayed at once (forms for model1, model2, association  
add/remove lists for model1/model2).

The form box for model1 might either be “create new model1” or toggled  
via testing a session[:selected\_model1} to “edit selected model1”.

It seems to me I have two main choices.

Use the controller action to display different views according to  
“state” and create multiple html view pages. If there are two boxes  
with 2 options each I think I could get by with 4 pages. If there are  
3 boxes with 2 options each …er that starts to really add up doesnt  
it?)

I can easily use if else conditions in a view.

\<% if condition\_one %\>

....

\<% else %\>

....

rinse and repeat for other page segments.

This conditional way easier for me to understand and it saves me from  
creating lots of files.

The issues:

1: Not supposed to put too much logic in views?

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?

I sort of asked this question on a table display yesterday but I want to  
confirm the same applies in a bigger context.

---

<div class="post-metadata">

**Author:** ![tomn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c89c15/32.png) [@tomn](https://www.ruby-forum.com/u/tomn)\
**Post date:** [November 17, 2007, 9:58pm UTC](https://www.ruby-forum.com/t/best-practices-for-views-noobie-q/120516/2 "2007-11-17T21:58:58Z")

</div>

You can change layouts in the controller using the layout declaration.

class LoginController \< ApplicationController  
layout :choose\_layout  
…

```
private

def choose_layout
  User.is_admin? ? "admin_layout" : "enduser_layout"
end

```

end

---

<div class="post-metadata">

**Author:** ![tomn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c89c15/32.png) [@tomn](https://www.ruby-forum.com/u/tomn)\
**Post date:** [November 17, 2007, 10:06pm UTC](https://www.ruby-forum.com/t/best-practices-for-views-noobie-q/120516/3 "2007-11-17T22:06:56Z")

</div>

On Nov 17, 2007, at 12:03 PM, Tom N. wrote:

> 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/](http://www.railsdev.ws/blog/3/modular-page-assembly-in-rails/)

– gw (www.railsdev.ws)

---

<div class="post-metadata">

**Author:** ![tomn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c89c15/32.png) [@tomn](https://www.ruby-forum.com/u/tomn)\
**Post date:** [November 18, 2007, 4:58am UTC](https://www.ruby-forum.com/t/best-practices-for-views-noobie-q/120516/4 "2007-11-18T04:58:38Z")

</div>

On Nov 17, 2007, at 9:51 PM, Tom N. wrote:

> Its really kinda cool how someone completely new can use this Rails  
> and  
> get a database driven application starting to work.

It is pretty amazing.

> I need to remind  
> myself of that positive every time I spend an hour or so trying to  
> figure out why something I’m trying to do hangs up on a comma in the  
> wrong place or a nil variable.

That will go away over time, and soon you’ll actually know when to  
type =\> and why 🙂

---

<div class="post-metadata">

**Author:** ![tomn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c89c15/32.png) [@tomn](https://www.ruby-forum.com/u/tomn)\
**Post date:** [November 18, 2007, 4:51am UTC](https://www.ruby-forum.com/t/best-practices-for-views-noobie-q/120516/5 "2007-11-18T04:51:55Z")

</div>

Tom … thank you for the variable layout idea… I it makes sense for the  
UI experience to be slightly different for different users perhaps  
differentiating between users who have and have not yet to input stuff  
into a few models

Greg, Wow thats a lot there but exactly the sort of stuff I was hoping  
some people would be kind enough to share with me.

BTW I did read your layout pdf and learned a lot from it. I’ll learn  
even more the second time I read it after a — lol – after a week and  
a half of web ap programming under my belt! (other than months of  
struggling with the texts and follow alongs)

Its really kinda cool how someone completely new can use this Rails and  
get a database driven application starting to work. I need to remind  
myself of that positive every time I spend an hour or so trying to  
figure out why something I’m trying to do hangs up on a comma in the  
wrong place or a nil variable.

Thanks for the loads of specific tips and info on ways things could  
look. Lots of nuggets I will chew on. I’ll need to start moving to  
partials and will need to overcome the fear i have of effectively  
passing variables and parameters back and forth from them.