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!
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
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.
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.
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.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
