how to deal with controller mutations
- by Milovan Zogovic
During development process, things are constantly changing (especially in early phases). Requirements change, UI changes, everything changes. Pages that clearly belonged to specific controller, mutated to something completely different in the future.
For example. Lets say that we have website for managing Projects. One page of the website was dedicated to managing existing, and inviting new members of specific project. Naturally, I created members controller nested under projects which had proper responsibility.
Later in the development, it turned out that it was the only page that was "configuring the project" in some way, so additional functionalities were added to it:
editing project description
setting project as a default
...
In other words, this page changed its primary responsibility from managing project members to managing project itself. Ideally, this page should be moved to "edit" action of "projects" controller. That would mean that all request and controller specs need to refactored too. Is it worth the effort? Should it be done?
Personally, I am really starting to dislike the 1-1 relationship between views and controllers. Its common situation that we have 1 page (view) that handles 2 or more different resources. I think we should have views completely decoupled from controllers, but rails is giving us hard time to achieve this.
I know that AJAX can be used to solve this issue, but I consider it an improvisation. Is there some other kind of architecture (other than MVC) that decouples views from controllers?
