Actually I have the same problem right now, I don’t want to use hard things like haml like style, argonaut or .json.erb. I want something simple, embedded in rails, but I think there aren’t anykind of possibility. What can I think it’s possible to create hash array in helper method, then add it into a format.json { render :json => json_generation_helper_method(@object) }

Anyway I will use plugin that I have told you in the beginning. It will be easier to move to the rails3 in the future, because rails3 now have easier api to add such kind of things, like template handlers.

Thanks,
Dmitry

Thanks for your thoughtful response to my post. I agree that the Controller’s primary role is to mediate interaction with the user, but in Rails the standard pattern is for the controller to pick out the URL params and find which model to act on and then render a specific view for that model.

The issue I was raising in the first code example was that there is no view if the controller simple calls .to_json on the model. You suggest that this is one viable option when we are creating machine-to-machine communication and we control both ends. You have a point that I think many would agree with. However, I believe that it is the better pattern to think of machine-to-machine communication as a user interface. In defining the ways in which machines communication, we define protocols. I would argue that it is never a good idea to directly expose an internal data structure in a protocol — that may be a starting point, but at minimum you will want to add a version field! By exposing the internal data structures of one subsystem, it can make it easy to accidentally break another subsystem when you optimize the implementation and make other non-functional changes.

That said, in thinking about this further, I wonder if the right approach to the problem I describe above would be to have the model define a custom to_json implementation with an optional version argument, so it can maintain multiple representations of its data.

Sarah

MVC was designed to be appropriate for creating end-user applications in the 70s. It was not designed with inter-process communication in mind, and so it’s not surprising that the concept doesn’t fit well. Therefore there are two appropriate ways to deal with this. The first is to consider the machine requesting data as a user, and give it a response as a view designed to represent its expected representation of the data. This is appropriate for example when you need to conform to an arbitrary xml doctype that is not well represented by the internal state of your model. For example, if you need to manipulate the data from the model to represent new things that are only useful to the consumer.

When you have control over the consumer or are defining your own API, it’s more appropriate to expect that the internal representations of the model are/will be the same on both ends. With this in mind, when a consumer makes a REST API request the controller receives this event and understands it as a request for a machine-representation of the data. This is the model’s job, so it’s entirely appropriate for the controller to respond by returning the model. JSON or XML is just your chosen text-serialized representation of the internal data of your model, it’s not a “view” in this case.

Note also, that the concept of a RESTful interface favors the second option when your resources are well represented by you models, which they are in most Rails apps. You should be thinking twice when you do this:
xml.sku product.sku
xml.name product.name
xml.brand product.brand
And it’s appropriate to expect that your client already knows how to find a basic action, since you’re using RESTful URIs, so you just need to give them a key (not necessarily the one in your database). You don’t need to offer them this:
xml.img_url url_for(:controller => :products, :action => :show, :format=>:png, :id =>

Also, you say URIs “belong in the view layer”. A URI is actually a request on the controller, not the view. Just because your .erb files are in the folders that correspond to your URIs doesn’t mean that the request for a URI is a request for a representation of that view. The fact that the structure of views might mimic the structure of your controllers and models is not something inherently MVC. It’s actually a sign that you might have a poor user interface, since the point of MVC is to let views represent data in a structure more appropriate for user interaction than the model representation can.