Designing routes for different parts of a model

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.

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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs