Friday, March 11th, 2005
Ajaxian Lifecycle vs. Conventional Lifecycle
Category: Ajax
We are used to the following:
- Client makes request to /foo
- Server receives request and passes it to a handler
- Server renders a response, maybe delegating to various actions, or maybe doing forward/redirects
If you have a lot of conceptual components on a page, the server has to coordinate what is going on. If you click on a link on ComponentA, the server needs to handle that call, and also re-render ComponentB and ComponentC. This is where frameworks such as Tapestry come in to help you out (Rewind!).
Now, compare this to an Ajax view. Now the page has various components, and they each have their own separate lifecycle (which may coordinate with other components). When an event fires on ComponentA, it can go back to the server itself. This server endpoint JUST needs to know about ComponentA, and the various events that it understands. This will end up with mini-server side actions, which probably wrap a framework such as JSON-RPC, or an XML language. The developer is abstracted from this view though.
So, the lifecycle views are:
Conventional
Client Request -> Server takes request and calls all of the components, gets a joint response and -> Send Response
Client Components -> Server end point -> Render full page
Ajaxian
Client Request -> end point for THAT component, which sends back a small packet which the component understands. The rest of the page isn’t re-rendered from the server, but the client can change the DOM based on the response.
Client Components -> Server end point -> Send information back to that particular component
In general, it is interesting to see the similarities, and the differences between the two models. In some ways the Ajaxian model is simpler, as each component only worries about its own world.
Related Content:
This is a serious question – not flame bait. Disclaimer – I have limited web presentation experience. Why would you prefer this Ajax approach to something like Laszlo?