I would personally illustrate the AJAX anaology as follows:
The model and the view are still handled by the server, but the controller would be handled on the client side.
Now I may be wrong in my understanding here, but depsite having never read anyone suggest this, I personally see the model/view as requiring somewhat of a mini-controller...perhaps it's needed only in my implementations...
view controller - determine which view to display
model controller - determne which model function to invoke
A bare bones request:
1) index.php is invoked
2) Front controller initializes and determine where to route the appropriate messages
3) The appropriate controller intercepts message, decomposes it and determines the model/view to invoke.
I'll explain...why I always need to make the distinction between the two mini-controllers:
The front controller as part of MVC...does as I've described above (or something very similar?) it dispatches tokens, messages, whatever to the appropriate controller...
But IMHO the controller can be further decomposed into model and a view controller
The MVC controller must determine which view to display, which also typically requires pulling on a model as well. In this regard, I see the controller logic here as a mini-view oriented controller. The MVC controller must also determine which actions to possibly perform, prior to rendering the view. This action handling also requires dealing with the model.
Now, I want to clarify that it's to my understanding that the front controller is actually responsible for dealing with such events as determining which action to execute (if any) and then which view to render.
Depending on the implementation this
event -> view handling may be done sequentially or require 2 seperate HTTP requests (from what I can tell Sympony allows you to choose between the two).
By considering the above, assuming I'm correct in my understanding of a front controller...this squashes my mini-view/model controller concept. But in model 1 architecture where there is no front controller, the I think this analogy still applies.
Even if I am wrong, for the sake of clarity, I think it helps to distinguish the two psuedo-(mini)controllers.
So...IMHO AJAX architecute works like this:
Also, I find it helpful to define the primary layout template of a web site as the FRAME where as the body-content section of a web site is called the VIEW to assist in clarifying the solution.
1) index.php is invoked
2) A default page is rendered by letting index.php run it's course - no AJAX
3) User clicks on a AJAX supported link
4) AJAX determines which "VIEW" to select and bypasses server side front controller
5) AJAX invokes a psuedo-page controller to emulate server side front controller
6) Server side view is executed and renders/returns HTML output
7) AJAX captures HTML and injects content into document body via innerHTML or similar.
In this regard, I personally tend to think of AJAX in MVC architecture as more of just the view portion of the MVC paradigm. Emulating something of a mini-front controller by only having the capacity to execute the view, not act on the model directly, so it's not entirely a controller by definition???
This is why I avoid using AJAX for this purpose, but instead use it only to make my interface more interactive, updating comboboxes for hierarchial datasets like:
Country, City, Province (State)
Instead of keeping state using GET I just refresh required comboboxes...
AJAX is IMHO difficult to effectively map to the MVC design pattern when it's dually or *asynchronously* implemented on the server side as well
HTH
Cheers
