The form element in html was a key component of dynamic content on the web. If you wanted to change something on the server with a user action on the Browser, this was the way to go. Well it still is quite popular. Click on a hyperlink / click of a button was the main interaction mechanism long back. Things are no longer the same.
The advent of Asynchronous Communication with the server (aka AJAX) has opened up the list of options I have. To list a few you see so often in the web.
Star Ratings.
Digg / Bury.
Tabbed pages.
Web based chat.
Auto Save.
Auto Complete.
....
These interactions with the server do not rely on form submit. There are things that happen behind the scenes as well. If you read a article, The author of the article can find out how much time you spent on the page. Also he can find out if you did scroll down to read the entire article. He just managed to capture something important about your behaviour without your sending it to him. Scary huh!
I was designing an Web UI for an application recently (this was after i became comfortable with the ajax technology) and I did spent some time trying to find out a good way to place the form element on my page. In simple cases it was pretty straight forward. In more complex scenario i found there was no neat place. That really set me into some thinking mode. What is that the form element really gives me.
1) It can get the data from a bunch of related fields and send it to the server.
2) I have a place to specify the URL where this data needs to go.
Have you used hidden fields in form? Didn't it seem kinda ugly hack. People have misused it. I know a couple of them. Don't want to list it out, cause people knowing me will find out what I am talking about ;)
Ok, that was a thread that just spawned off. Lets get back to the main thing. What can I do instead of using a form?
A small javascript method can achieve the same with a lot more flexibility.
1) I can determine the exact thing that gets sent to the server.
2) I can determine where it goes, The same information I can send to different URL's based on the user choice. (remember the hidden field called action/type! :) )
3) I am not limited to GET/POST. I can follow the restful http paradigm to a great extent. I can set the method as DELETE / PUT as well.
This things will make sense if you have already commited to the AJAX way of building an applications. Most of the Java Web frameworks out there still have Form as an integral part of their framework. Capturing the information in databean and passing it around.
I tried it out, It works! More...
Wednesday, January 28, 2009
Monday, January 12, 2009
Light Weight Web Application Development
I am one of the Java Application Developers who use the java platform to build web applications. There are lots of frameworks out there which can help me do that, I have read about a lot of them, tried out quite a few of them using the sample apps that is provided by almost all of them.
I do get a nagging feeling in the back of my mind when I use them. Something is not right. There ought to be a better/simpler way to do this. I know I am not the only one who gets this feeling. The fact that there are so many frameworks out there and smart people haven't stopped creating new once as I write it.
Then it slowly started to dawn upon me the problem is with the statement "I am a Java Developer!". If I replace that with I am a web developer, suddenly more options open up. And one of them I realized was my kind of way. I am not going to write a long article about why I think this is the best way. The business requirements determine what would be the best solution for the given problem.
I am only going to talk about the mainstream web application. A typical crud application where the user puts some data. He should be able to get this data at a later point in time. Also he should be able to see data from other folks in the town. (building a case for web application over standard desktop.)
Let me describe the architecture that I finally found most to my liking.
I use html as frontend. I use Servlets as data service layer. Popular data formats being xml, json, html snippet. I used html snippet only for tabular data. The rest was json. The interaction between the server and the client follows the Rest paradigm. The verbs of the web PUT, POST, GET and DELETE are used where appropriate. To elaborate on the frontend more. HTML is used to define data elements. css is used for styling and Javascript is used for Behaviour. The UI widgets were all javascript widgets.
Does this sound like the old Client Server architecture? Well to a certain degree it is. But the difference is the the server is not a DB server here. Its an App Server and can do a lot more. It can give me data in a format I find more suitable. I can do a lot more things than saving and getting records from rdbms. Have you noticed that the DBMS today want to do more and more.
List of benefits of this architecture as I see it.
1) The user action is responded to at the first layer. I dont have to move the information several layers down and bring the response up several layers. Some frameworks hide this fact. But I have to understand this to use those frameworks to the best. Others dont care and refuse to acknowledge that there can be intelligent layer defined in the javascript layer.
2) There is no impedence mismatch. This is the main complaint I had with the traditional web frameworks. The actions on the browser needs to be converted to a form submit. The elements of form have to define the action, The same has to get converted to Java in the backend and passed. All the while I have to keep in mind how the data is getting transmitted over the wire.
3) The existing frameworks have accomodated ajax as an afterthought. With this architecture there are no 2 ways. There is only the ajax way.
4) Testing is easy. I can easily test my servlet data services.
5) The solution can have higher throughput because the load on the server is less. The clients will take the majority of the load. The network load will also be less.
I used JQuery because javascript was is a first class citizen in this design. There is lot that would happen in javascript. A syntax that would let do more with less code is what helps me here.
What has changed in last few years that should to be taken into account.
1) The client have grown fat. I am talking about the PC's that you get now a days. None come with less than 2 GB RAM. I still remember the days when 2GB Hard disk was a luxury. The mobile platforms are still lean but the way things are going they are putting on weight like humans!!!
2) The Javascript libraries have matured a lot. The libraries out there can produce UI that are as slick as the desktop UI.
3) I can ignore the people who dont have Javascript enabled in browser. The requirement that your site should degrade gracefully in absense of javascript what a big stone around our neck. Its time to throw it away and lets assume that everybody has a good javascript engine. The people who dont have it should get it.
4) The browsers which form the 98% of the user base have become more standards complaint. I can ignore the remaining few. They or their browsers will die soon.
So now I call myself a web developer. Java, Javascript, css, html developer. I want to throw in the paintshop in that mix, but some people might think of that as lowly. (remember rounded corners!)
Some might question why Java it can be anything! Yes it can be PHP/C#/Python/Perl. Its just that I have more experience in Java. Java is a good language. The platform is stable. I get tons of useful libraries(mostly opensource). I don't see a need to jump from the Java ship. I am also not going to ask the PHP guys to come over here. That just reminded me I should write about Perl as well. My favourite for server side scripting.
I do get a nagging feeling in the back of my mind when I use them. Something is not right. There ought to be a better/simpler way to do this. I know I am not the only one who gets this feeling. The fact that there are so many frameworks out there and smart people haven't stopped creating new once as I write it.
Then it slowly started to dawn upon me the problem is with the statement "I am a Java Developer!". If I replace that with I am a web developer, suddenly more options open up. And one of them I realized was my kind of way. I am not going to write a long article about why I think this is the best way. The business requirements determine what would be the best solution for the given problem.
I am only going to talk about the mainstream web application. A typical crud application where the user puts some data. He should be able to get this data at a later point in time. Also he should be able to see data from other folks in the town. (building a case for web application over standard desktop.)
Let me describe the architecture that I finally found most to my liking.
I use html as frontend. I use Servlets as data service layer. Popular data formats being xml, json, html snippet. I used html snippet only for tabular data. The rest was json. The interaction between the server and the client follows the Rest paradigm. The verbs of the web PUT, POST, GET and DELETE are used where appropriate. To elaborate on the frontend more. HTML is used to define data elements. css is used for styling and Javascript is used for Behaviour. The UI widgets were all javascript widgets.
Does this sound like the old Client Server architecture? Well to a certain degree it is. But the difference is the the server is not a DB server here. Its an App Server and can do a lot more. It can give me data in a format I find more suitable. I can do a lot more things than saving and getting records from rdbms. Have you noticed that the DBMS today want to do more and more.
List of benefits of this architecture as I see it.
1) The user action is responded to at the first layer. I dont have to move the information several layers down and bring the response up several layers. Some frameworks hide this fact. But I have to understand this to use those frameworks to the best. Others dont care and refuse to acknowledge that there can be intelligent layer defined in the javascript layer.
2) There is no impedence mismatch. This is the main complaint I had with the traditional web frameworks. The actions on the browser needs to be converted to a form submit. The elements of form have to define the action, The same has to get converted to Java in the backend and passed. All the while I have to keep in mind how the data is getting transmitted over the wire.
3) The existing frameworks have accomodated ajax as an afterthought. With this architecture there are no 2 ways. There is only the ajax way.
4) Testing is easy. I can easily test my servlet data services.
5) The solution can have higher throughput because the load on the server is less. The clients will take the majority of the load. The network load will also be less.
I used JQuery because javascript was is a first class citizen in this design. There is lot that would happen in javascript. A syntax that would let do more with less code is what helps me here.
What has changed in last few years that should to be taken into account.
1) The client have grown fat. I am talking about the PC's that you get now a days. None come with less than 2 GB RAM. I still remember the days when 2GB Hard disk was a luxury. The mobile platforms are still lean but the way things are going they are putting on weight like humans!!!
2) The Javascript libraries have matured a lot. The libraries out there can produce UI that are as slick as the desktop UI.
3) I can ignore the people who dont have Javascript enabled in browser. The requirement that your site should degrade gracefully in absense of javascript what a big stone around our neck. Its time to throw it away and lets assume that everybody has a good javascript engine. The people who dont have it should get it.
4) The browsers which form the 98% of the user base have become more standards complaint. I can ignore the remaining few. They or their browsers will die soon.
So now I call myself a web developer. Java, Javascript, css, html developer. I want to throw in the paintshop in that mix, but some people might think of that as lowly. (remember rounded corners!)
Some might question why Java it can be anything! Yes it can be PHP/C#/Python/Perl. Its just that I have more experience in Java. Java is a good language. The platform is stable. I get tons of useful libraries(mostly opensource). I don't see a need to jump from the Java ship. I am also not going to ask the PHP guys to come over here. That just reminded me I should write about Perl as well. My favourite for server side scripting.
Subscribe to:
Posts (Atom)
Posts
