MVC and Ajax? How?

[effex0r]

Is it possible to use an MVC design architecture for a site that uses Ajax to update/delete information?

As I understand it, it seems when people utilize MVC, all requests (GET/POST) are funneled through the index.php page, where they are examined to discover the correct Controllor to use.

But it seems that Ajax requests, by their nature, happen more directly from the UI, using JavaScript to call the server.

How can these 2 methods be used consistently in an application? They appear to be complimentary.

Th a nk s

[mrsmiley]

You are partially correct. MVC isn't reliant on the index.php file per se, but rather the controller to tell the backend what to do with the request.

If index.php is happily processing and routing all your standard GET/POST requests, then you might benefit from setting up a new controller script just to handle all your AJAX request routing.

Using AJAX you can more closely mimic the true nature of MVC as its found in desktop applications, but you are essentially relegating the controller code to the client PC and this isn't always a good thing from a security stand point.

I'd probably recommend setting up a dedicated controller for the AJAX request instead as the logic behind them could be different as the parameters you feed it could be different as well.

[REMIYA]

I personnally make a pure PHP MVC page(s) and also separate PHP Ajax MVC page(s).

The pure PHP pages work only with the PHP side of the website, while the Ajax page(s) handle only the Ajax requests, and respond.

[Dr Livingston]

Umm...

Not particularly used AJAX as such in a viable application yet, but I've taken a look at it; From my point of view, a request is just a request, regardless; You talk about the Front Controller (index.php) so it shouldn't really matter to this architecture what or where the request came from.

If it does, then you'd have to rethink your design is how I see it; The issue you have I think, is how to distinguish the AJAX calls from normal requests? What I do, is to prefix the name of the controller with ajax during my research.

So, instead of this,

www.domain.com/en/products/update/id/SCH1000/

I would have this,

www.domain.com/en/products/ajaxupdate/id/SCH1000/

Makes little difference, since the URL it's self isn't altered (from what I see of it anyways?), so this is the route that I'm going to take. Why? Well for one, I can at a later date, at AJAX functionality to an already mature application, without the need to alter the application it's self. All I would need to do is to add another class method on the Products controller, and voila?

You of course, need to select a response which may well differ, but have I missed something out? Really, I know there is still a lot of buzz going about this, but it's not that difficult to take account of

One issue that I have concerns for is security, and I'm of the view that there is a lack of particular detail in this regard; I suppose it's one reason that I've not yet moved towards developing with AJAX yet... Another reason being is I'm not a fan of Javascript, from the usability point of view.

If the user has it disabled...

[oerdec]

Maybe you´ll find this article interesting: AJAX MVC (so to speak).

OK, so what part of this process can be associated with a View, or a Model or a Controller? The Model is easy, it's the business logic ... This is the PHP script. The View? Obviously this is the HTML page and the CSS. But I'd like to think also about the JS that updates the page as part of the View.... How about the Controller? Well, we have two controllers here. One that is on the server side, a PHP script that receives requests and "asks" the Model for the response. The other controller is on the client side, this is the JavaScript that decides what happens on a click of a button and sends an appropriate AJAX request to the PHP controller. Therefore I would consider any behavioural JS as part of the Controller, including attaching events as well as sending HTTP requests.

Code and a demo can be found there. I don´t know what to think of it ... it could become very complex and bloated if have many controllers (pairs). But I´ll check it anyway.

[oranjcrush]

I don't see why this is an issue since, if you want to keep your AJAX calls separate, you can just use an 'Ajax' Controller and provide the functionality needed through AJAX specific actions.
Alternativly, and personally, I use the view layer of the MVC pattern to provide an AJAX 'view' of the data (returning XML/JSON in lue of returning a complete XHTML Page.
In fact, its also how i deal with RSS feeds. (Any page in my application, with only a few exceptions, can return their data as XHTML, XML or JSON)

If you want some code examples, just let me know and I'll post when I get back to work on Monday


edit:
Just to be complete: When my controller recieves an AJAX call (known either by POST/URL Param or via REST) a set a "returnAsXML or returnAsJSON" attribute in the Response Object that is picked up by my View_Factory (which finishes preparing of the Response Object utilizing my View_XML / View_JSON Classes', respectively)

[skinny monkey]

Just to be complete: When my controller recieves an AJAX call (known either by POST/URL Param or via REST) a set a "returnAsXML or returnAsJSON" attribute in the Response Object that is picked up by my View_Factory (which finishes preparing of the Response Object utilizing my View_XML / View_JSON Classes', respectively)

I'd like to see an example of this

[Czaries]

I think you may be regarding this issue as more complicated than it really is. All AJAX really does is create a different way to send and receive a request. The URL format and everything will still be the same. The only thing that really needs to change is the VIEW, depending on how you want to receive the response. If you need the raw HTML that will be generated, sometimes that doesn't even have to change.

What I do to simplify things is either create a different method within the same controller or create an IF statement to check if the request is an AJAX request within the same method. I generally append an extra variable on the end of my AJAX requests (via a javascript wrapper function) like: "&ajaxRequest=1" so my scripts can then check for that POST variable in the request data. It's an easy way to see how the request is coming in and what response needs to be sent.

[dagfinn]

I think you may be regarding this issue as more complicated than it really is. All AJAX really does is create a different way to send and receive a request. The URL format and everything will still be the same. The only thing that really needs to change is the VIEW, depending on how you want to receive the response. If you need the raw HTML that will be generated, sometimes that doesn't even have to change.

I've only sniffed Ajax briefly so far, and I find that comforting. But there is one other side to this that should probably be kept entirely separate. It's possible (must be) to use traditional rich-client MVC on the client in JavaScript. That would be useful for the same kind of thing, such as synchronizing separate controls containing the same data without contacting the server.

[Jasper Bekkers]

The only thing that really needs to change is the VIEW, depending on how you want to receive the response.

When implemented correctly you typically have a HMVC / PAC architecture, one MVC layer on the client-side and one layer on the server-side in which the controllers talk to each other.