@order = params[:order] || session[:order] || 'date'
orderby = case @order
when 'user' then 'user'
when 'score' then 'score DESC'
else 'updated_on DESC'
end
Don't use @ unless you are really passing a variable to other methods in this class.
@order = "date" #default@order = session[:order] if session[:order]
@order = params[:order] if params[:order]
order = session[:order] || params[:order] || 'date'
Note I use single 'ticks' because I don't need the special abilities of "". That represents a very important style rule - use the simplest code you can. Think of "" as "costing more" than ''.
orderby = "updated_on DESC" #default
orderby = "score DESC" if @order == "score"
orderby = "user" if @order == "user"
orderby = case @order
when 'user' then 'user'
when 'score' then 'score DESC'
else 'updated_on DESC'
end
That's better than mine by preserving the DESC.
But why the params and session themselves don't contain the real code - 'updated_on DESC'. The View could, for example, show 'date' to the user and set its value to 'updated_on DESC'. Then all this fun goes away!
> orderby = case @order
> when 'user' then 'user'
> when 'score' then 'score DESC'
> else 'updated_on DESC'
> end
That's better than mine by preserving the DESC.
But why the params and session themselves don't contain the real code -
'updated_on DESC'. The View could, for example, show 'date' to the user and set
its value to 'updated_on DESC'. Then all this fun goes away!
Agree. The only reason may be security - user would know your table
column name 'updated_on' if you use it directly in view.
But why the params and session themselves don't contain the real code - 'updated_on DESC'. The View could, for example, show 'date' to the user and set its value to 'updated_on DESC'. Then all this fun goes away!
Agree. The only reason may be security - user would know your table
column name 'updated_on' if you use it directly in view.
They also might hack the params and put in a SQL injection attack.