Jim
Don Lapre James
webmaster@katesoriginals.com
http://www.katesoriginals.com  

I wanted to let you know that I released a new version of my RESTful Rails plugin on RubyForge yesterday. I took your suggestions, remixed them with my own ideas and I’m pretty happy with the results.

Here’s the announcement on the Microformats list:

http://microformats.org/discuss/mail/microformats-rest/2006-March/000158.html

You may also be interested to note that Rails 1.1 will have something similar to your idea of sending different variants depending on what the client asks for. This process is called Content Negotiation, and it looks pretty cool:

http://www.loudthinking.com/arc/000572.html

What I was suggesting was that I like the concept of Helper system on a per-representation basis. All it is is a class where you define methods that your view/representation code can access, allowing you to extract complex logic from a view into a reusable component. Helper systems should not be shared between different representations.

Perhaps some convenient for template naming could work, like “++”. But when I write that down it looks overly complicated. On the other hand shared behavior is well understood at the controller/action level, you just have a private method that does the shared work. Handling different content types at the controller/action definition level is not quite correct conceptually but it might be workable, pragmatic choice. Of course I think you would just be pushing the complexity to the app developer (because they would probably end up need to explicity specify what template to use) which is probably a Bad Thing.

Anyway, it is not clear to me what the best answer is but if something occurs to me I will post it here or microformats-rest.

The .rhtml template can contain simpler logic, like if statements and variable interpolation, but complex logic can be placed into Helper classes and invoked with a simple method call.

If you were going to design a view module for some other representation you could decide to either include all the presentational logic inside the templates themselves, or invoke a method from an outside class. After seeing Rails’ approach work successfully in practice I’d probably design any views modules in a similar way.

I agree that it would work along side of the current routing system. I think it is vital that RPC style controllers continue to function as they currently do.

As for content-type… I think you are right. It is important to provide a way to easily support multiple content types but it should not be handled at the action definition level. That code should be able to be shared by all the representations of that resource. However, I am not sure exactly how it shoule be handled instead.

I really like your idea of putting a way of specifying the URI a controller observes inside the controller itself. Keeps everything together in one place nice and neat. For this to work I think it should work side by side with the
current routing system rather than replacing it. I think I might take a stab at this in the next week.

I also like the way you define handlers for each of the methods. I’ll probably borrow that in my next iteration of RestController.

The one thing I disagree with is that I don’t think its a good idea to specify the content-type of the response in the action. The same base instance variables should be made available for all supported views, so the same code should be used to gather together the data. There may be slighly different presentational logic based on the type of view, but I think that logic should be pushed to the view and its helpers rather than existing inside the controller.