Nick,
Thanks again for the reply.
I think I will probably go back to using either protected controller
methods or helper methods to fetch the reference data. I agree with
you 100% in that this type of logic simply has no place in the view.
As for my statement regarding the framework lacking a w
G'day Justin.
> That's a great suggestion. I would actually prefer using a helper
> method over putting the call to ModelObject#find in the view itself.
> Something about calling find directly from the view just doesn't feel
> right to me. The only reason I'm not 100% opposed to it is because a
>
Nick,
That's a great suggestion. I would actually prefer using a helper
method over putting the call to ModelObject#find in the view itself.
Something about calling find directly from the view just doesn't feel
right to me. The only reason I'm not 100% opposed to it is because a
call to find is u
Elias Orozco wrote:
> Hey Justin,
>
> I'll recommend that every data used to load drop down lists on the
> views should be loaded on the views, that avoids repetition on the
> controllers. For example a list of post categories you can load it
> like this:
>
> <%= collection_select(:post, :post_c
Hey Justin,
I'll recommend that every data used to load drop down lists on the
views should be loaded on the views, that avoids repetition on the
controllers. For example a list of post categories you can load it
like this:
<%= collection_select(:post, :post_category_id,
PostCategory.find(:all),
ck.>
> Anyhow, my current ideas for solutions, none of which I really like,
> are as follows:
> 1. In the "create" and "update" actions, call the filter methods
> prior to rendering the new/edit views (don't like this, since if
> additional reference data is added later, I will have to add/remov
6 matches
Mail list logo
