I have a strong handle on when to use a helper -- at least I think so. A helper may include some logic (not enough to belong in the model) and it presents html as its output. So I have a conceptual problem about this solution that I've built:

#helpers/people_helper.rb
def person_roles
(%W(assistant author collector editor foreword illustrator interviewer introduction narrator notes translator) + Role.group('name').map(&:name)).uniq().sort
end

I use the output in a view, as part of a collection_select picker for a string-based attribute. This picker has a JavaScript "combobox" behavior added to it, so the editor can add new roles to the list at whim. But the output is an array. Does this invalidate my use of a helper method? Or am I thinking too much about the label "helper" here?

Thanks,

Walter

--
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@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

Search Discussions

  • Colin Law at Jan 26, 2012 at 2:38 pm

    On 26 January 2012 14:26, Walter Lee Davis wrote:
    I have a strong handle on when to use a helper -- at least I think so. A helper may include some logic (not enough to belong in the model) and it presents html as its output. So I have a conceptual problem about this solution that I've built:

    #helpers/people_helper.rb
    def person_roles
    (%W(assistant author collector editor foreword illustrator interviewer introduction narrator notes translator) + Role.group('name').map(&:name)).uniq().sort
    end

    I use the output in a view, as part of a collection_select picker for a string-based attribute. This picker has a JavaScript "combobox" behavior added to it, so the editor can add new roles to the list at whim. But the output is an array. Does this invalidate my use of a helper method? Or am I thinking too much about the label "helper" here?
    To me that looks more like something that should be called in the
    controller and go into an @ variable for use in the view. The general
    rule is setup data in the controller and display it in the view. The
    method itself could go in the Role model or in a module in lib

    Colin
    Thanks,

    Walter

    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.


    --
    gplus.to/clanlaw

    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Walter Lee Davis at Jan 26, 2012 at 2:48 pm

    On Jan 26, 2012, at 9:37 AM, Colin Law wrote:
    On 26 January 2012 14:26, Walter Lee Davis wrote:
    I have a strong handle on when to use a helper -- at least I think so. A helper may include some logic (not enough to belong in the model) and it presents html as its output. So I have a conceptual problem about this solution that I've built:

    #helpers/people_helper.rb
    def person_roles
    (%W(assistant author collector editor foreword illustrator interviewer introduction narrator notes translator) + Role.group('name').map(&:name)).uniq().sort
    end

    I use the output in a view, as part of a collection_select picker for a string-based attribute. This picker has a JavaScript "combobox" behavior added to it, so the editor can add new roles to the list at whim. But the output is an array. Does this invalidate my use of a helper method? Or am I thinking too much about the label "helper" here?
    To me that looks more like something that should be called in the
    controller and go into an @ variable for use in the view. The general
    rule is setup data in the controller and display it in the view. The
    method itself could go in the Role model or in a module in lib

    Colin
    I had it in the controller, but I didn't like the look of having to declare an instance variable inside each method that needed this (new and create and edit and update). The helper was there for the asking in each view, so it seemed DRYer. Is there a way to have my cake and eat it too?

    Thanks,

    Walter

    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Colin Law at Jan 26, 2012 at 2:51 pm

    On 26 January 2012 14:47, Walter Lee Davis wrote:
    On Jan 26, 2012, at 9:37 AM, Colin Law wrote:
    On 26 January 2012 14:26, Walter Lee Davis wrote:
    I have a strong handle on when to use a helper -- at least I think so. A helper may include some logic (not enough to belong in the model) and it presents html as its output. So I have a conceptual problem about this solution that I've built:

    #helpers/people_helper.rb
    def person_roles
    (%W(assistant author collector editor foreword illustrator interviewer introduction narrator notes translator) + Role.group('name').map(&:name)).uniq().sort
    end

    I use the output in a view, as part of a collection_select picker for a string-based attribute. This picker has a JavaScript "combobox" behavior added to it, so the editor can add new roles to the list at whim. But the output is an array. Does this invalidate my use of a helper method? Or am I thinking too much about the label "helper" here?
    To me that looks more like something that should be called in the
    controller and go into an @ variable for use in the view.  The general
    rule is setup data in the controller and display it in the view.  The
    method itself could go in the Role model or in a module in lib

    Colin
    I had it in the controller, but I didn't like the look of having to declare an instance variable inside each method that needed this (new and create and edit and update). The helper was there for the asking in each view, so it seemed DRYer. Is there a way to have my cake and eat it too?
    If it is the same code in each action then set the variable in a
    before_filter in the controller. Then it will be setup for each
    action that you specify. Bone dry.

    Colin
    Thanks,

    Walter

    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.


    --
    gplus.to/clanlaw

    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Michael Pavling at Jan 26, 2012 at 2:52 pm

    On 26 January 2012 14:47, Walter Lee Davis wrote:
    I had it in the controller, but I didn't like the look of having to declare an instance variable inside each method that needed this (new and create and edit and update). The helper was there for the asking in each view, so it seemed DRYer. Is there a way to have my cake and eat it too?
    helper_method :my_controller_method

    ?

    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Colin Law at Jan 26, 2012 at 3:04 pm

    On 26 January 2012 14:51, Michael Pavling wrote:
    On 26 January 2012 14:47, Walter Lee Davis wrote:
    I had it in the controller, but I didn't like the look of having to declare an instance variable inside each method that needed this (new and create and edit and update). The helper was there for the asking in each view, so it seemed DRYer. Is there a way to have my cake and eat it too?
    helper_method :my_controller_method
    Michael: I don't think that addresses the problem, unless I
    misunderstand. The OP doesn't need the method available in the
    controller *and* the view, he is just not sure about which it should
    be.

    Colin

    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Michael Pavling at Jan 26, 2012 at 3:16 pm

    On 26 January 2012 15:03, Colin Law wrote:
    Michael: I don't think that addresses the problem, unless I
    misunderstand.  The OP doesn't need the method available in the
    controller *and* the view, he is just not sure about which it should
    be.
    True... depending on where it's wanted will affect whether it should
    be a helper, helper_method or before_filter ;-)

    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Walter Lee Davis at Jan 26, 2012 at 3:04 pm

    On Jan 26, 2012, at 9:51 AM, Michael Pavling wrote:
    On 26 January 2012 14:47, Walter Lee Davis wrote:
    I had it in the controller, but I didn't like the look of having to declare an instance variable inside each method that needed this (new and create and edit and update). The helper was there for the asking in each view, so it seemed DRYer. Is there a way to have my cake and eat it too?
    helper_method :my_controller_method

    ?
    If it is the same code in each action then set the variable in a
    before_filter in the controller. Then it will be setup for each
    action that you specify. Bone dry.

    Colin
    Thanks to both of you.

    Walter
    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Peter Vandenabeele at Jan 26, 2012 at 4:38 pm
    On Thu, Jan 26, 2012 at 3:37 PM, Colin Law wrote:
    ...
    To me that looks more like something that should be called in the
    controller and go into an @ variable for use in the view. The general
    rule is setup data in the controller and display it in the view.

    TL;DR
    * controller only does "routing/decision" logic (render, error, redirect,
    ...)
    * views get their rich data from a presenter


    I feel less confident about this strategy.

    I have doubts over this code in the controller that is
    "pushing/pre-setting" data
    into e.g. a @user instance variable

    @user =
    User.include(:account).include(:address).include(:projects).find(params[:id])

    of which a large fraction may remain unused and the specific usage may
    change over time.

    Suppose that we initially show a list of all the projects of the user
    in the show view, but later decide to not show that list in the first
    "show" view anymore (it could e.g. be shown later with an AJAX
    request when the user opens a projects tab).

    Then we would be always populating the @user with too much data,
    unless we think about removing that from the controller.

    I would prefer a method where the view "pulls" (only) the data that it
    needs, when it needs it, from ... (a presenter ??).

    A helper (in my opinion) is purely an html/decorator thing (as was
    also the feeling of the OP, If I understood correctly).

    Of course, the ActiveRecord::Relation helps to delay the actual SQL
    in certain cases (e.g. in the index view). But it does not remove the
    code complexity and potential inefficiency from the controller.

    I start to feel more that the controller does some "routing/decision"
    logic (render, error, redirect, ...), but that it should not really prepare
    the data for later views. The views should "pull" their data from a
    presenter.

    Does this make sense? Would it address the initial question from the OP?

    Peter

    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Colin Law at Jan 26, 2012 at 4:53 pm

    On 26 January 2012 16:38, Peter Vandenabeele wrote:
    On Thu, Jan 26, 2012 at 3:37 PM, Colin Law wrote:
    ...
    To me that looks more like something that should be called in the
    controller and go into an @ variable for use in the view.  The general
    rule is setup data in the controller and display it in the view.

    TL;DR
    * controller only does "routing/decision" logic (render, error, redirect,
    ...)
    * views get their rich data from a presenter


    I feel less confident about this strategy.

    I have doubts over this code in the controller that is "pushing/pre-setting"
    data
    into e.g. a @user instance variable

    @user =
    User.include(:account).include(:address).include(:projects).find(params[:id])

    of which a large fraction may remain unused and the specific usage may
    change over time.

    Suppose that we initially show a list of all the projects of the user
    in the show view, but later decide to not show that list in the first
    "show" view anymore (it could e.g. be shown later with an AJAX
    request when the user opens a projects tab).

    Then we would be always populating the @user with too much data,
    unless we think about removing that from the controller.

    I would prefer a method where the view "pulls" (only) the data that it
    needs, when it needs it, from ... (a presenter ??).

    A helper (in my opinion) is purely an html/decorator thing (as was
    also the feeling of the OP, If I understood correctly).

    Of course, the ActiveRecord::Relation helps to delay the actual SQL
    in certain cases (e.g. in the index view). But it does not remove the
    code complexity and potential inefficiency from the controller.

    I start to feel more that the controller does some "routing/decision"
    logic (render, error, redirect, ...), but that it should not really prepare
    the data for later views. The views should "pull" their data from a
    presenter.

    Does this make sense? Would it address the initial question from the OP?
    I think the issue there is where there may be multiple ways of
    "viewing" the data. For example xml and html. In that case the
    conventional MVC concept is that the controller prepares the data then
    it goes off to an appropriate renderer which decides how to format it.
    In your example above with user projects, if only a subset of the
    projects is to be seen then it is up to the controller to make that
    subset available.

    Colin

    Colin

    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
  • Walter Lee Davis at Jan 26, 2012 at 5:44 pm

    On Jan 26, 2012, at 11:38 AM, Peter Vandenabeele wrote:

    On Thu, Jan 26, 2012 at 3:37 PM, Colin Law wrote:
    ...
    To me that looks more like something that should be called in the
    controller and go into an @ variable for use in the view. The general
    rule is setup data in the controller and display it in the view.

    TL;DR
    * controller only does "routing/decision" logic (render, error, redirect, ...)
    * views get their rich data from a presenter


    I feel less confident about this strategy.

    I have doubts over this code in the controller that is "pushing/pre-setting" data
    into e.g. a @user instance variable

    @user = User.include(:account).include(:address).include(:projects).find(params[:id])

    of which a large fraction may remain unused and the specific usage may
    change over time.

    Suppose that we initially show a list of all the projects of the user
    in the show view, but later decide to not show that list in the first
    "show" view anymore (it could e.g. be shown later with an AJAX
    request when the user opens a projects tab).

    Then we would be always populating the @user with too much data,
    unless we think about removing that from the controller.

    I would prefer a method where the view "pulls" (only) the data that it
    needs, when it needs it, from ... (a presenter ??).

    A helper (in my opinion) is purely an html/decorator thing (as was
    also the feeling of the OP, If I understood correctly).

    Of course, the ActiveRecord::Relation helps to delay the actual SQL
    in certain cases (e.g. in the index view). But it does not remove the
    code complexity and potential inefficiency from the controller.

    I start to feel more that the controller does some "routing/decision"
    logic (render, error, redirect, ...), but that it should not really prepare
    the data for later views. The views should "pull" their data from a
    presenter.

    Does this make sense? Would it address the initial question from the OP?
    Yes and yes. I agree with your analysis of my question, and I'd love to see more elucidation of how a presenter pattern could work in this case.

    Thanks,

    Walter
    Peter

    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
    --
    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@googlegroups.com.
    To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprubyonrails-talk @
categoriesrubyonrails
postedJan 26, '12 at 2:26p
activeJan 26, '12 at 5:44p
posts11
users4
websiterubyonrails.org
irc#RubyOnRails

People

Translate

site design / logo © 2021 Grokbase