Hypothetical Question about Views

This is purely for curiosity’s sake:

If I have a simple controller method:

def index
@thing = Thing.all

respond_to do |format|
format.js
end
end

And I’d like to call the ‘index’ controller method from three different
locations, all with AJAX, to return three entirely different views.

Currently I use this:

def index
@thing = Thing.all

respond_to do |format|
format.first_view
format.second_view
format.third_view
end
end

I have a hunch, however, that separate mime types for different views is
inappropriate, or is this good? Any thoughts?

On Sep 14, 9:44 pm, Kendall B. <rails-mailing-l…@andreas-
s.net> wrote:

I have a hunch, however, that separate mime types for different views is
inappropriate, or is this good? Any thoughts?

Sounds like a needless complication to me - I don’t see what this buys
you.

Fred

Frederick C. wrote:

On Sep 14, 9:44�pm, Kendall B. <rails-mailing-l…@andreas-
s.net> wrote:

I have a hunch, however, that separate mime types for different views is
inappropriate, or is this good? Any thoughts?

Sounds like a needless complication to me - I don’t see what this buys
you.

Fred

How do you deal with wanting three different views for the same data? Do
you use three separate controller actions?

If it is 3 views of the same data, then the controller could just look
at a params[:which_format] value to determine where to route the view
for rendering.

Creating mime types for different views all destined for the same
recipient format
is, in my opinion, an inappropriate use of the mime
types.

And just a niggle… Thing.all implies you are retrieving @things,
plural.

Kendall B. wrote:

def index
@thing = Thing.all

respond_to do |format|
format.first_view
format.second_view
format.third_view
end
end

I have a hunch, however, that separate mime types for different views is
inappropriate, or is this good? Any thoughts?

I have a hunch that your hunch is correct. At least in the sense that
you present here. There is a fundamental concept of the REST
architecture that I believe Rails tends to make somewhat obscure. The
concept I’m referring to is the fundamental definitions of resources and
representations.

It is tempting to think of a “resource” (in Rails) as the combination of
a controller and a model, but that is not really the case.

Take for example this table from Fielding’s Dissertation on REST:

       Table 5-1: REST Data Elements

Data Element | Modern Web Examples

resource | the intended conceptual target of a hypertext
reference
resource identifier | URL, URN
representation | HTML document, JPEG image
representation metadata | media type, last-modified time
resource metadata | source link, alternates, vary
control data | if-modified-since, cache-control

Notice the definition of a resource, “The intended conceptual target of
a hypertext reference.” The concept of a resource by definition is a
conceptual target not a specific controller.

In my mind this means that there is not a one-to-one correspondence
between a resource and a controller/model. Therefore, if there are three
separate, and independent views, they each deserve their own “conceptual
target,” and hence their own set of resource identifiers. In Rails this
means they might have their own controllers and their own routes to map
URLs to controller actions.

The responds_to block (and hence mime-types) are intended to provide
access to the representations of a resource. Again these are
representations of the conceptual concept of a resource. As indicated in
the table above this might be in the form of an HTML document, JPEG
image, XML document, JSON, etc.

The types also do not have to be a one-to-one correspondence. One could
very well have multiple representations in HTML. A good use case for
this is to provide alternate layouts for different target devices. One
might define a mime-type for an iPhone representation of a resource
along with a desktop browser version both using HTML.

On Sep 14, 10:54 pm, Kendall B. <rails-mailing-l…@andreas-
s.net> wrote:

Frederick C. wrote:

How do you deal with wanting three different views for the same data? Do
you use three separate controller actions?

I would. Sounds like it would be clearer than fiddling with
respond_to. Obviously you’d want to share the data generation stuff
between the various actions.

Fred