Part I
Have been wanting to write about this for quite a while, AJAX applications. Everyone's using them. #ell everyone seems to be writing them too!!
There are many flavors, frameworks and approaches all depending on the XmlHttpRequest object. But each differs in the way they use it.
The whole process is pretty simple. A call is made behind the scenes to the server and some content is returned which could take any conceivable format really. Now somehow the client DOM then has to be updated to reflect the changes in data/structure/presentation.
Complications arise because the whole browser base model was built out for one simple thing. Documents. Period. Which are very different from applications. Data although being central to applications forms only a subset.
It is amazing that we are delivering applications on this big a level on a model that really only supports documents. And it really does go a long way to proving the utter simplicity/flexibility of the whole model.
But unfortunately web applications can SEEM a little less than ideally responsive. One Small thing changes on the page and we have to load it all up. The server has to process everything, generate everything even though only one simple item might really have been changed or needs to be displayed differently. We simply keep recreating the whole page. Why? That's a DUMB way to do things. Not really,in the beginning it was a brilliant way to do things after all it was dynamic. but as all other brilliant things, it needs to improve, it needs to move on, it needs to evolve.
AJAX and its various forms are what step in to spice it all up. They allow for the submission of what can be considered an inline, on the fly request to a server. This request comes back and some amount of JS code then processes this response.
To make these things work we are now in the situation wherein we have a lot of complex UI based logic on the client side to manage the loading and display of the data that comes back from the server. We are writing mini-applications in the browser using lots of JavaScript.
There is a fair number of articles/tutorials/guides/books and blogs that talk discuss or preach the various approaches/frameworks. Most of the stuff being on the client side.
Client requests -> Server processes -> sends out response -> client processes -> DOM Manipulated.
The fourth step highlighted is the one that tends to become heavy and fat, But isn't that the goal? Are we not trying to emulate fatter clients using a real classic thin client?
Yes and Yes, but it does not have to be so. The server can still be in control of both the data it sends out and also dictating as to how the data should be structured/presented on the client.
So in comes a slightly different approach.
A few of my colleagues have been working towards building something that makes life easier for us folk. Write AJAX applications like totally normal web apps. It is quite possible that you can almost circumvent the usage of JavaScript. In comes, DUML - Document Update Markup Language.
The instructions to manipulate the client side DOM(resulting a change in the Data/Structure/Presentation) are sent back from the Server side. We do not have to write anything to process the data that comes back. A JS library(an implementation of the DUML specification) on the client side simply takes care of all this for us. It processes these instructions on the client side and builds out the DOM tree as intended by the developer. Hence it changes the application.
Let's quickly run through a small example.
Duml Based AJAX.
Ingredients:
1.) Client + Client side DUML implementation. A JS library available at DUML.org.
2.) Server side component. Handles the request and processes it and sends out the appropriate response. Dictates both the content and the presentation details.
Now, I can code my server side component using any technology I choose. It could be a Java app, It could be a .Net app, something whipped up in PHP! Irrespective of the server side technology all that needs to be spit out is XML compliant with the DUML specification. And in simpler terms all it amounts to is simple block(s) of html wrapped around in some DUML instructions.
These instructions serve as metadata for the client side JS library and define the manipulation of the DOM on the client side.
After all in a very crude way, that's all AJAX ultimately is, on the fly manipulation of the DOM based on inline requests that do not result in a total page refresh.
So say I write my web based pages in jsps. My response really needs to be XML. Or in other words it should be WF XML compliant with the DUML spec.
So there is a root node that identifies and defines that this is a DUML document. Now all the data will be sent back as regular HTML surrounded by DUML instructions as different blocks/nodes under this particular root node. Each instruction in this document sent back to the client denotes one particular operation to be performed on the client's DOM.
Say I need something on the lines of what GMail does. Every once in a while it polls the server to check for email. Whenever I get new email it should display a message in the status bar portion of my Inbox stating that I have new mail.
How would I do that?
1.) A client side submit to a page on the server. If you read up on any basic HttpXMLRequest stuff, this is pretty simple.
2.) Server side code handles the request, processes it and if it finds any new email it sends back the markup written out below. The DUML engine traps the response on the client side and then processes the set of instructions lined out in response and updates the DOM accordingly.
< duml version="1.0">
< instruction manipulation="appendChild" originnodeid="inbox" replaceifexists="true">
< div id="statusBar"> You've got Mail! </div>
< /instruction>
< /duml>
3.) So, what are we doing here? We have some node that is on the client page already as a result of some previous page refreshes or loads or AJAX calls. This node has an id of inbox. We need to add a div to this particular node that displays the message stating "You've Got Mail!".
That is all we are doing in the particular case.
How is this a good idea? Since all the updates done to the DOM were triggered by instructions sent out by the server. So all I need to write is proper instructions in Java/jsp, ASP.NET or anything that I choose in. The DOM manipulation is in a sense abstracted out and generalized to maintain the separation of concerns.
My client(browser) is truly bothered about one thing and one thing only, display, But I personally do not have to write and maintain complex script code to decide what goes where and how it looks.
Clean and clutter free. Of course it does add some complexity and added burden on the server side,. but hey,. Yes, the devil is in the details, but that's what pays the bills. :)
This is a very small introduction to DUML. It works great for us. We have a number of applications using it actively. I would say that it is still maturing and rapidly developing. I will dive into a few more details in a future article.
Please go and visit the DUML home page. Who knows, it might change your life or help you attain AJAXian Nirvana. No kidding, seriously, check it out!
I will be making this particular post a multi-part series. After all there is so much we can talk about when it comes to this. It will be my feeble attempt to supplement some of the stuff on the DUML site.
Duml and Dumler!
Have been wanting to write about this for quite a while, AJAX applications. Everyone's using them. #ell everyone seems to be writing them too!!
There are many flavors, frameworks and approaches all depending on the XmlHttpRequest object. But each differs in the way they use it.
The whole process is pretty simple. A call is made behind the scenes to the server and some content is returned which could take any conceivable format really. Now somehow the client DOM then has to be updated to reflect the changes in data/structure/presentation.
Complications arise because the whole browser base model was built out for one simple thing. Documents. Period. Which are very different from applications. Data although being central to applications forms only a subset.
It is amazing that we are delivering applications on this big a level on a model that really only supports documents. And it really does go a long way to proving the utter simplicity/flexibility of the whole model.
But unfortunately web applications can SEEM a little less than ideally responsive. One Small thing changes on the page and we have to load it all up. The server has to process everything, generate everything even though only one simple item might really have been changed or needs to be displayed differently. We simply keep recreating the whole page. Why? That's a DUMB way to do things. Not really,in the beginning it was a brilliant way to do things after all it was dynamic. but as all other brilliant things, it needs to improve, it needs to move on, it needs to evolve.
AJAX and its various forms are what step in to spice it all up. They allow for the submission of what can be considered an inline, on the fly request to a server. This request comes back and some amount of JS code then processes this response.
To make these things work we are now in the situation wherein we have a lot of complex UI based logic on the client side to manage the loading and display of the data that comes back from the server. We are writing mini-applications in the browser using lots of JavaScript.
There is a fair number of articles/tutorials/guides/books and blogs that talk discuss or preach the various approaches/frameworks. Most of the stuff being on the client side.
Client requests -> Server processes -> sends out response -> client processes -> DOM Manipulated.
The fourth step highlighted is the one that tends to become heavy and fat, But isn't that the goal? Are we not trying to emulate fatter clients using a real classic thin client?
Yes and Yes, but it does not have to be so. The server can still be in control of both the data it sends out and also dictating as to how the data should be structured/presented on the client.
So in comes a slightly different approach.
A few of my colleagues have been working towards building something that makes life easier for us folk. Write AJAX applications like totally normal web apps. It is quite possible that you can almost circumvent the usage of JavaScript. In comes, DUML - Document Update Markup Language.
It is a specification that defines a set of processing instructions to manipulate the DOM.The USP of this approach:
The instructions to manipulate the client side DOM(resulting a change in the Data/Structure/Presentation) are sent back from the Server side. We do not have to write anything to process the data that comes back. A JS library(an implementation of the DUML specification) on the client side simply takes care of all this for us. It processes these instructions on the client side and builds out the DOM tree as intended by the developer. Hence it changes the application.
Let's quickly run through a small example.
Duml Based AJAX.
Ingredients:
1.) Client + Client side DUML implementation. A JS library available at DUML.org.
2.) Server side component. Handles the request and processes it and sends out the appropriate response. Dictates both the content and the presentation details.
Now, I can code my server side component using any technology I choose. It could be a Java app, It could be a .Net app, something whipped up in PHP! Irrespective of the server side technology all that needs to be spit out is XML compliant with the DUML specification. And in simpler terms all it amounts to is simple block(s) of html wrapped around in some DUML instructions.
These instructions serve as metadata for the client side JS library and define the manipulation of the DOM on the client side.
After all in a very crude way, that's all AJAX ultimately is, on the fly manipulation of the DOM based on inline requests that do not result in a total page refresh.
So say I write my web based pages in jsps. My response really needs to be XML. Or in other words it should be WF XML compliant with the DUML spec.
So there is a root node that identifies and defines that this is a DUML document. Now all the data will be sent back as regular HTML surrounded by DUML instructions as different blocks/nodes under this particular root node. Each instruction in this document sent back to the client denotes one particular operation to be performed on the client's DOM.
Say I need something on the lines of what GMail does. Every once in a while it polls the server to check for email. Whenever I get new email it should display a message in the status bar portion of my Inbox stating that I have new mail.
How would I do that?
1.) A client side submit to a page on the server. If you read up on any basic HttpXMLRequest stuff, this is pretty simple.
2.) Server side code handles the request, processes it and if it finds any new email it sends back the markup written out below. The DUML engine traps the response on the client side and then processes the set of instructions lined out in response and updates the DOM accordingly.
< duml version="1.0">
< instruction manipulation="appendChild" originnodeid="inbox" replaceifexists="true">
< div id="statusBar"> You've got Mail! </div>
< /instruction>
< /duml>
3.) So, what are we doing here? We have some node that is on the client page already as a result of some previous page refreshes or loads or AJAX calls. This node has an id of inbox. We need to add a div to this particular node that displays the message stating "You've Got Mail!".
That is all we are doing in the particular case.
How is this a good idea? Since all the updates done to the DOM were triggered by instructions sent out by the server. So all I need to write is proper instructions in Java/jsp, ASP.NET or anything that I choose in. The DOM manipulation is in a sense abstracted out and generalized to maintain the separation of concerns.
My client(browser) is truly bothered about one thing and one thing only, display, But I personally do not have to write and maintain complex script code to decide what goes where and how it looks.
Clean and clutter free. Of course it does add some complexity and added burden on the server side,. but hey,. Yes, the devil is in the details, but that's what pays the bills. :)
This is a very small introduction to DUML. It works great for us. We have a number of applications using it actively. I would say that it is still maturing and rapidly developing. I will dive into a few more details in a future article.
Please go and visit the DUML home page. Who knows, it might change your life or help you attain AJAXian Nirvana. No kidding, seriously, check it out!
I will be making this particular post a multi-part series. After all there is so much we can talk about when it comes to this. It will be my feeble attempt to supplement some of the stuff on the DUML site.
Duml and Dumler!
