Why is the dataType attribute set to 'script' in the ajax call?

[rails]

Why is the dataType attribute set to 'script' in the ajax call?

[mjonuschat]

I vote vor a solution like this one: 9e2709aff4c063c22d3f6a71d1b8efbdef9cbc0b

This way we default to 'script' but can override it with a html5 attribute

[brianmario]

+1 on yabawock's comment (obviously)

[jorgemanrubia]

I think the advantage of that solution is that it doesn't break compatibility with apps already using the driver. However, I think that a more coherent approach would be to default in the same way JQuery does (not to default to script, but to the jquery-detection system).

[spastorino]

drogus tries a patch here https://rails.lighthouseapp.com/projects/8994/tickets/4603/a/522635/allow-to-set-datatype-with-data-type-html-attribute.patch it seems ok.
I can't see the patches from brianmario

[stevestmartin]

The current behavior is meant to serve as a default, adding a data-type html attribute would require changes to rails-core, and each driver to implement the change. Setting dataType to script allows the most common use case to occur on its own (parsing js response) without having to specify the request format to the server. If you would like to use an html response you can use something such as this http://gist.github.com/403791

Closing for now, if this is unacceptable or a use case in which the solution does not work, a ticket should probably be opened in lighthouse due to changes in html_helpers being needed.

[brianmario]

I'm fully aware of how to do it manually, and I understand the current value is meant to serve as a default. This is why my proposed patch left it as "script" but allowed the user to override it if need be. Why should I need to duplicate all this logic manually when all that's needed is a simple two line patch to this file?
The point is I wanted to take advantage of what rails.js was doing in my JS code, reusing the global ajax:* events is a great solution IMO.
Are you proposing this file only be used by rails itself?

[brianmario]

Also, why does anything in Rails have to change for this patch? You can just set any arbitrary attributes you want using the existing html_helpers.

[mjonuschat]

I don't see where the proposed solution requires a patch to the html_helpers as the default is left as 'script'. It doesn't change the way anything works, it just allows a developer to reuse existing functionality and override it.

The solution you propose just results in code / functionality duplication in the application.js. As the previously linked patch doesn't show any content anymore here's a fresh link.

Maybe you could take a look at the patch (again) and re-evaluate why it would make changes to rails-core necessary.

http://github.com/yabawock/jquery-ujs/commit/a189b805344fadbb743999175eb78bac672eaf90

[stevestmartin]

Keep in mind that each of the primary extension points (callbacks, attributes) within the driver are meant to handle rails generated markup and be consistent between implementations. Introducing new markup to be handled by the driver should likely be handled within all driver implementations which is why I'm hesitant at changing the behavior.

The reason for the current implementation is parsing a javascript response is the only thing that can really be done for you, other response types callbacks will need to be written anyways ex: html and json there is no way the driver could know what you want to do with the data once its returned.

This is definitely something I'd like to hear other opinions on, and possibly a decision from rails core. The best way to do that is probably through continuing the conversation within lighthouse. Maybe removing dataType: 'script' and changing the URLs / actions to use request formats would be a better solution allowing jquery to determine the result itself and the controller to know how it should respond without any code changes to rails core.

[brianmario]

I'm still failing to see why this has anything to do with Rails code at all. This change doesn't break any of the existing behavior with Rails. It doesn't make any new assumptions about what Rails is doing. This is seemingly a similarly small change in all the other drivers as well.

I'd be more than happy to take on the work to patch all code that needs to be updated to get these patches in.

Honestly I don't mind just using my own fork of this, I'd just rather share the love with other developers as well. This change really does enable good code reuse. It's too bad this JS is being treated as if it's only for use by Rails itself.

[bkimble]

It would be nice to see this. render :json => {:foo => "bar"} returned "Invalid Label" errors because the data type is set to script instead of json :(

[dgm]

I'm currently doing something like you said in http://gist.github.com/403791, which has been working up until I updated jquery; Since I'm returning a plain text, the script parsing fails and the ajax call throw an error and runs my error handler, not the success handler. I think this change happened in a jquery update recently. Do I need to change all my format.js { render :text => message} calls into something else? This hits me mostly on the delete methods, as I have a routine that removes the row from the page, displays the returned text, and then fades.

[bkimble]

Seems kind of odd to use an AJAX call that returns plain text with the exception of a delete action. If your format is js, you should be using dataType: 'json' or dataType: 'script'. If you plan on rendering :text, you should be using dataType: 'html'. IMO you should be returning js/json though so you can parse the response in a programmatic way. Otherwise if you return text or html it will be difficult to slice out any error messages associated with the action you are taking.

[dgm]

Actually, this is for a delete action... I was using the return to flash a status message and delete the line:

https://gist.github.com/1206990

I used the default ujs options to start the project, and since I just added the :remote => true to the link_to call, the obvious option was to use a format.js receiver.

I'm in the process now of refitting all these calls to use a standard json response, as outlined in http://paydrotalks.com/posts/45-standard-json-response-for-rails-and-jquery