The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Making ajax requests to a controller

I was wondering how people are integrating ajax into the web apps.

For instance, one part of my site is a contact page, with the form action posting to ContactController::submitForm, which validates a user-supplied email address (among other things) and sends the form.

Now an aspect i think ajax works well is input validation, and i'd like to verify the users email address before they post the form. The only way i can currently do this is to wrap my email validation class into a separate file to be used for, and only for, the purpose of ajax requests. You see the problem - i'm starting to fragment my codebase by creating different files for different types of input.

So i was wondering if it's a bad practice for a controller to call methods on itself. For example, in ContactController::submitForm, validation of the email address could occur (and be delegated to from submitForm) in ContactController::validateEmail. This way if the form is posted, the email is validated by php, but i can also point my ajax request directly to ContactController::validateEmail.

Rails takes the approach of responding to different types of requests by mime/type (I believe the Prototype javascript library sends special HTTP header in its AJAX requests). Most controller code should be the same no matter how its being invoked, its just the response that varies. Here's how Rails does it:

Actually it is the mime-type all right. The field is called Accept when requesting and Content-Type when responding, but the value is a mime-type in both cases. The reason for calling it Content-Type is because that's what it is called in emails, so to be consistent with that already established standard, they choose to call it the same in the HTTP protocol.

Just like your controller can (and should) dispatch to different functions on different HTTP-methods (GET/POST), so can it dispatch to different functions, depending on the Accept header. I'd normally use the same URL for ajax-type callbacks, but send a custom Accept header to indicate the type of response expected. This could be something like application/x-ajax-html for HTML-fragments, or application/x-ajax-json for JSON type response etc. There is no standard content-type for these different types of response, so everybody seems to be making up their own slightly different solutions. The Prototype library for example, doesn't even use the Accept header - instead, they made up their own header field. There was some effort to standardize this matter, but I don't think anything ever happened.

Perhaps the solution I have used in the past is too simplistic for you, but I would just insert an 'ajaxCall' variable in the javascript to be POSTed with the other data I passed, and would just do a simple if check for that variable like so:

Having a blast using the Symfony framework which handles all this for me. The way that framework handles it is to treat AJAX requests the same as any HTTP request -- they get routed to a module then an action within a module. The only difference is Symfony detects it's an XMLHttpRequest as kyber described and skips decorating the template of that action with the module's layout, so all that's returned is that action's output alone. Prototype/Scriptaculous handle all the actual JS work.