Distinguish between Ajax.Request and Updater?

Rails
1

Is there a way to tell if an actiojn was called with Ajax.Request as
opposed to Ajax.Updater? Ie., if link_to_remote was called without the
:update param, and with the :update param?

In my action I would like to know if I should use render :update or I
can just use render for this particular request. For performance
reasons, I want to use :update where possible, since it is twice as fast
without the escaping, but there are still times I need my action to do
more than just render a div…

Obviously I can do it with some extra param in the link_to_remote :url,
but if there is some ‘well known’ rails way of doing this I would like
to know.

Thanks.

2

I believe this is what respond_to is for:

respond_to do |wants|
wants.html {#render some html}
wants.js do {#render some rjs}
end

Fred

3

Fred wrote:

I believe this is what respond_to is for:

respond_to do |wants|
wants.html {#render some html}
wants.js do {#render some rjs}
end

Fred

Ah, thanks… knew it was something simple…just couldnt put my finger
on it.

4

Slain W. wrote:

Fred wrote:

I believe this is what respond_to is for:

respond_to do |wants|
wants.html {#render some html}
wants.js do {#render some rjs}
end

Fred

Actually, this doesn’t work. link_to_remote :update => ‘some_div’
triggers the wants.js even though it really only wants.html by
definition.

There is a problem in prototype 1.5.0_rc0 in setRequestHeaders causing
this:

‘Accept’, ‘text/javascript, text/html, application/xml, text/xml,
/’];

will ALWAYS trigger the wants.js in a link_to_remote :update and never
the wants.html. The request headers for an Ajax.Request and an
Ajax.Updater should be different…
Update should be:
‘Accept’, ‘text/html, text/javascript, application/xml, text/xml,
/’];

and request should be

‘Accept’, ‘text/javascript, application/xml, text/xml, /’];

I’m thinking. Or else, rails needs another way of knowing whether html
or js is wanted…

Adding a custom setRequestHeaders to Ajax.Updater that omits the
javascript option works as well…

setRequestHeaders: function() {
var requestHeaders =
[‘X-Requested-With’, ‘XMLHttpRequest’,
‘X-Prototype-Version’, Prototype.Version,
‘Accept’, ‘text/html, application/xml, text/xml, /’];

if (this.options.method == 'post') {
  requestHeaders.push('Content-type', this.options.contentType);

  /* Force "Connection: close" for Mozilla browsers to work around
   * a bug where XMLHttpReqeuest sends an incorrect Content-length
   * header. See Mozilla Bugzilla #246651.
   */
  if (this.transport.overrideMimeType)
    requestHeaders.push('Connection', 'close');
}

if (this.options.requestHeaders)
  requestHeaders.push.apply(requestHeaders,

this.options.requestHeaders);

for (var i = 0; i < requestHeaders.length; i += 2)
  this.transport.setRequestHeader(requestHeaders[i],

requestHeaders[i+1]);
},

5

Alan F. wrote:

Slain W. wrote:

Slain W. wrote:

Fred wrote:

I believe this is what respond_to is for:

respond_to do |wants|
wants.html {#render some html}
wants.js do {#render some rjs}
end

Fred

Actually, this doesn’t work. link_to_remote :update => ‘some_div’
triggers the wants.js even though it really only wants.html by
definition.

Not the solution you’re looking for, I know, but can you go for two
separate actions with the common code extracted ?

A.

The patch to prototype works, so I’m happy. And no I dont really want
to break that out in a dozen actions :stuck_out_tongue: But it would work of course, or
as I mentioned, adding another parameter to the link_to_remote :url like
:is_update => true

6

Slain W. wrote:

Slain W. wrote:

Fred wrote:

I believe this is what respond_to is for:

respond_to do |wants|
wants.html {#render some html}
wants.js do {#render some rjs}
end

Fred

Actually, this doesn’t work. link_to_remote :update => ‘some_div’
triggers the wants.js even though it really only wants.html by
definition.

Not the solution you’re looking for, I know, but can you go for two
separate actions with the common code extracted ?

A.