Ruby on Rails Tuesday, March 25, 2014

masta Blasta wrote in post #1140924:
> I have a model in my app called Report, that has a lot of fields.
>
> In the view we show these fields in tabbed sections, grouped by theme,
> to make it easier on the user. When these were first built, the
> developers at the time decided to treat these "themes" as resources and
> created separate routes, controllers and views to handle them.
>
> Lately this structure has started to bother me a lot. There are multiple
> controllers performing the same actions on the same Report instance.
> Moving things between the different tabs is a hassle, and adding new
> tabs is a even worse.
>
> To me the tabbed layout in the HTML represents different viewings of the
> same resource. The editing and updating of that resource should be
> handled in one place and not in the 4 different controllers we have
> currently.
>
> However i'm not sure how to arrange my routes and controller actions to
> unify the process. I would like the URLs to looks something like
>
> /reports/:report_id/:section
> /reports/:report_id/:section/edit
>
> but can't find a clean way of doing that.
>
> Another approach i've been looking at is to insert some intermediate
> POROs to handle the view management. Something not unlike the presenter
> pattern: http://blog.jayfields.com/2007/03/rails-presenter-pattern.html
>
> This would involve significant code changes, but it might be worth it if
> the final result is clean and decoupled.
>
> Any advice?
>
> Some of the tabs are - 'functional overview', 'technical overview',
> 'display layout'
>
> P.S.
> Splitting up the sections into new models is not an approach i want to
> take.
>
> P.S P.S
> I'm on Rails 2.3 but that shouldn't be important.

Well i discovered a potential routing solution. Now i can forward
everything to the same actions (again this is Rails 2.3)

map.resources :reports do |reports|
reports.technical_overview 'technical_overview',
:controller => 'reports',
:action => 'show_section',
:section_name=>'technical_overview',
:conditions => {:method=>:get}

reports.functional_overview 'functional_overview',
:controller => 'reports',
:action => 'show_section',
:section_name=>'functional_overview',
:conditions => {:method=>:get}

reports.update_technical_overview 'technical_overview',
:controller => 'reports',
:action => 'update_section',
:section_name=>'technical_overview',
:conditions => {:method=>:post}
end

This actually makes me quite happy. I found out that any unrecognized
options passed to the route mapper just get forwarded to the action
params. This allows the generated path helpers to be used without any
additional arguments, and is more backwards compatible with what i have
now.

The shorter alternative would be to do
reports.section ':section_name',
:controller => 'reports',
:action => 'show_section',
:conditions => {:method=>:get}

but then every time you call the path helper you would have to specify
the :section_name as an additional argument. Which is not as nice.

This gets me 90% of the way there, but I would still like to hear what
other solutions there are to this problem.

--
Posted via http://www.ruby-forum.com/.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/439c460c965d77a560949fe5162a7ac2%40ruby-forum.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment