I came across some posts which postulate that it's undesirable to share helper methods across controller and views because UI code (designed to render HTML) should be separate from controller code (designed for handling requests). That makes sense but there are times, a good example is filtering, when it only makes sense to create a reusable method to query against the params hash from both controller and view. For example, I created some custom filtering and sorting. When a http request is initially made, my controller must be able to query the database for results without user input.
# controller layer (query a default without user input) helper_method :sort_column, :sort_direction, :for_selected_month, :for_selected_year def driver_reports_table @drivers = Driver.select("drivers.*, #{sort_column}").joins([:reports, :driving_habits]).by_month(for_selected_month.to_i, for_selected_year.to_i).order(sort_column + " " + sort_direction).page(params[:page]).per(10) @unit = current_unit respond_to do |format| format.html { render :partial => '/home/reports/ driver_reports_table', :layout => false, :locals => { :drivers => @drivers, :unit => @unit } } format.json { render :json => @drivers} end end
private
def sort_column if legal_attributes.include? params[:order] params[:order] else "drivers.id" end end
def sort_direction %w[asc desc].include?(params[:direction]) ? params[:direction] : "asc" end
def for_selected_month (params[:date] && params[:date][:month]) || Time.now.month end
def for_selected_year (params[:date] && params[:date][:year]) || Time.now.year end
def legal_attributes @columns ||= Driver.column_names + DrivingHabit.column_names end
In my view layer, the user will interact with form elements and links to modify the values of the params hash In one situation, I have a form tag where the user will set the date and date and month/year attributes of the params hash: #view = form_tag driver_reports_path, :method => 'get', :id => 'drivers_filter' do %fieldset.filter_tab = select_month(Date.today) = select_year(Date.today, :start_year => 2012, :end_year => Time.now.year) = submit_tag "Filter Date" = render '/home/reports/driver_reports_table'
In another situation, I have links where the user will set the sort and direction attributes of the params hash, depending on which link they click: #partial = hidden_field_tag :sort, params[:sort] = hidden_field_tag :direction, params[:direction] ... %table.sortable %tr = sortable "id", :order => "drivers.id"
#helper def sortable(column, query_string={}) title ||= column.titleize query_string[:order] = query_string[:order] || column css_class = 'driver_refresh' css_class << (column == sort_column.gsub("driving_habits.","").gsub("drivers.","") ? " current #{sort_direction}" : "") query_string[:direction] = column == sort_column.gsub("driving_habits.","").gsub("drivers.","") && sort_direction == "asc" ? "desc" : "asc" query_string[:page] = nil
content_tag :th, link_to(title, driver_reports_path(params.merge(query_string)), {:class => css_class }) end
Each of the situations compensate for the other. If the user selects an option from the select tag and thus populates the date attributes, when they click a link, it will merge the date attributes from the form with the link attributes that were selected and thus send them together to the server. Conversely, when the form is submitted, because of the hidden field tags with the current value of the sort and direction attributes stored in them, those attributes will be send with the form attributes.
As you can see, my view helper makes use of the sort_column and sort_direction methods to check the current values in the params hash to determine how to render the links. So those methods have importance both in the controller and view layer. So it would make sense to define the methods once and reuse them in both layers. So what is wrong with this technique and how else could it be done so as not to violate the MVC structure and separation of concerns?
