Forum: Ruby on Rails Best Practices question regarding views & controllers

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
77961c972c437d6801714f45c3f2cc3c?d=identicon&s=25 Raphael Schmid (rapha)
on 2006-03-03 11:02
Hi List!

I'm reading the Agile book, as many online articles as I can, but
there's still some things that are just too hard to answer for yourself.
In building my application, I often find myself putting code into my
views of which I am not quite certain it belongs there.

Where do you usually draw the line? Is it okay to, say, loop through an
array of hashes that represents table column names and whether they need
a certain colspan and build the table according to that?

Any advice that you might have would be greatly appreciated!

Best regards,
Raphael Schmid
0091f92762685860109bbcb02edfdf27?d=identicon&s=25 Alain Ravet (Guest)
on 2006-03-03 11:33
(Received via mailing list)
Raphael
    > Where do you usually draw the line? Is it okay to, say, loop
through an
    > array of hashes that represents table column names and whether
they need
> a certain colspan and build the table according to that?


If it - the code - has no impact on/is not impacted by/has nothing to do
with the model or the business rules, you can safely put it in the view
or helper.
I guess there may be exceptions :)

Alain
3319ab6fb19fcf97c8a3d66b8a9b68bf?d=identicon&s=25 Josh on Rails (Guest)
on 2006-03-03 14:16
(Received via mailing list)
I'm hardly an expert or anything, but - especially if you're still
learning - put it wherever you can make it work for now, and plan to
refactor later.

I find Ruby/Rails code easy to refactor, in general, so I don't think
this is a major chore. And the odds are good that much of what you
write when you're learning it (deity knows I am!) is going to want to
be refactored before too long.



-- Joshua
5d15c6821f3c3054c04b85471824ba7c?d=identicon&s=25 Kevin Olbrich (Guest)
on 2006-03-03 15:11
(Received via mailing list)
I tend to put code in views that only affects the display of the data
and which relates to the rendering of links, buttons, etc.

I will frequently take ugly code and turn it into a helper or model
method just to keep things clean and reusable.

_Kevin
C941170ba5ca038b89b8407c83fb23c2?d=identicon&s=25 Berin Loritsch (Guest)
on 2006-03-03 15:45
(Received via mailing list)
Raphael Schmid wrote:
>
> Any advice that you might have would be greatly appreciated!
>

My general rule of thumb is this:

* If we are modifying the model, or finding resources, it belongs in the
controller
* If we are iterating through a list to display items, it belongs in the
view

And for the fuzzy areas where we might have to filter the results, the
view should simply display the items in a set and the controller would
do all filtering.
89d967359903c639d31e4cad4569f537?d=identicon&s=25 Charlie Bowman (Guest)
on 2006-03-03 16:30
(Received via mailing list)
I agree.  If I have to do something more than once, it becomes a helper.

On Fri, 2006-03-03 at 14:11 +0000, Kevin Olbrich wrote:

> I tend to put code in views that only affects the display of the data
> and which relates to the rendering of links, buttons, etc.
>
> I will frequently take ugly code and turn it into a helper or model
> method just to keep things clean and reusable.
>
> _Kevin


Charlie Bowman
http://www.recentrambles.com
F59329dc91cba06600ff65c85fd3e93c?d=identicon&s=25 Anthony Green (acgreen)
on 2006-03-03 16:40

> Where do you usually draw the line? Is it okay to, say, loop through an
> array of hashes that represents table column names and whether they need
> a certain colspan and build the table according to that?

That would be fine, if the table headers were hardcode into the view it
wouldn't.

The way I understand it the view should contain as little 'control'
coding whilst still allowing for Agile development.

So iterating through a hash/array is fine but filtering out elemnts on
some basis isn't - that should be done in the controller or model.

I don't think the Agile book is the best place to learn about these
concepts. Tony Marstons written some easy intros to MVC. To progress
beyond the basics I'd look at some of the threads on Sitepoint.

_tony
C402e1150580c153c1368573f70e7e82?d=identicon&s=25 Cody Skidmore (cskidmore)
on 2006-03-03 16:45
As a rule, code in the view should only concern itself with rendering
the data.  Think about the code and ask yourself what the purpose of the
code is.  If its point is to render the model, it should be fine putting
it in the template.

If it manipulates the model in any way, take it out.  In MVC, the
application stack's visibility is downward only with each layer only
knowing about the one immeadiately below it.  Think about it this way:

  View
    |
    V
Controller
    |
    V
  Model
    |
    V
Data Store

This might be a bit simplistic, but the idea is the view should not see
the model or the data store.  It should only see the controller.
Furthermore, the none of the layers should see levels above them at all,
making it strictly top-down visible.
This topic is locked and can not be replied to.