REST - Some doubts

rubyonrails-talk
1

Hi,

I recently started using rest for building some new rails apps. I find it great and clean, but when I started a big project some days ago some doubts come to my mind.

First of all, after implementing the user management and authentication system (which in my case is quite complex) I noticed my routes.rb file was already fairly big. It seemed to be reasonable to me since I have to perform lot of operations on the users of my app, especially form the admin namespace, but the fact that I just started the project and I already have this huge routing files scares me.

Moreover, I'm used to have a lot of helper actions to handle calls to link_to_remote (used for example to dynamically change form fields based on user input). Some of these calls can be handled by the classic REST actions with respond_to, but for others it just makes sense to have a custom action, and this forces me to insert a custom route every time in my routes.rb file. The same applies to small actions like "activate" or "block" for users. I know that in the REST way of doing things this could be done by creating separate controllers, but this seems stupid to me (especially in my case, I'll be force to create one such controller for each user type, with subsequent route definition).

I hope someone can help me clarify those doubts.

Thank you in advance (and sorry for the english, it's not my native language)

2

Hi Simone,

In your "activate" and "block" actions can't you just use the common "update" action, just passing the necessary parameters?

It would be as simple as receiving an "user[ativated] = false" from the request and you could probably reuse the already implemented "update" action in your controller. I've killed many unecessary named routes by using the already implemented actions and parameters.

3

Hi Maurício, thanks for your reply. In fact I can't just reuse another action because it's not just a matter of changing a field in the database (which in that case update could be ok), I also perform some background operations like sending emails and updating other protected fields of the model (like date of activation or removing activation code). To do that I need to call a model method like user.activate or user.block, and it would be a mess probably to integrate this behaviour inside the update method.

4

You don't need to integrated it at the update_attributes method, here's an example:

class User

  def activate( save = true )     ##do activate stuff and save the model if save == true   end

  def activated=( new_value )     selc.ativate(true) if new_value == true and self.read_attribute(:ativated) == false   end

end

You would just pass the activated attribute value and "activate" or deactivate the user as required and without writting a new action.

But if something like this doesn't work for your model, i guess you're out of luck.

5

Not out of luck I'll say, that's a good idea, thanks for the tip. As for the routes file becoming big, do you have some idea about it?

6

Well, mine is already big, 264 lines and counting.

The first thing that i did was to group as many controllers with only the default routes as possible, as in:

map.resources :users, :clients, :products

They used to be in separate places and where making the file bigger for no reason.

Another thing was to move the "admin" controllers basic config to a block, and just call the block when i needed to configure an admin controller, here's a sample:

  admin_configurer = Proc.new do |resource_name, options |     options ||= {}     map.resources resource_name, { :path_prefix => '/manage', :name_prefix => 'manage_', :controller => "manage/#{resource_name}" }.merge( options )   end

  admin_configurer.call :deactivated_users, :member => {:define => :put}   admin_configurer.call :products

I removed a lot of uneeded lines with this, but I still got a big routes file, i guess it's something we'll need to live with. My next idea was to separate the routes in "areas" and then get each of those areas in a separate file and eval it at the routes.rb "draw" call, but I haven't really done that as i think it isn't needed, at least for now.

7

Sorry to butt in, and this is unconfirmed info, but I swear that I heard a rumor of Rails 3 (the new Rails/Merb combo powerhouse) support for Maurício's concept of routes "areas."

It would be a nice way to separate things out and lazy load only what you need at run time. Having a routes folder with specialized routes (even that dreaded default when needed) would be sweet. Routes do get rather large even on some simple apps and it would be nice to have a way to trim things down.

+1 for that idea, Maurício.