This article proposes a faster and safer way to build Web applications.
Part 2 of this article presents a C# and Java example about what Standalone Ajax may be.
Some time ago, I was reading an article about possible technology trends like having the Ajax standalone - not needing any more ASP or JSP or PHP, etc. - and I decided to give it a go by myself.
Doing Ajax enabled pages within my ASP.NET projects is not a convenient task sometimes. Why bother with the viewstate, how about not needing it at all?
Let's have Ajax standalone - in a simplified vision: static XHTML, JavaScript Ajax call layer, and service oriented server-side. Such an approach will perfectly fit with Agile, TDD, Web design... and will bring very close from the start the service oriented architecture for the server side!
Let's say we need to build a Web application based on some initial discussions that end up by not giving a clear overview of the functionality (as usual), so you can build first at most an incomplete skeleton.
We are in the first sprint... some Agile teams may struggle already to deliver "usable software"... well, bits of it... then change it later with great agility and... under the pressure of changing requirements - most of the time the client needs to achieve a better structure for its own processes before it would make sense to have custom software... The sooner you get better requirements, the lower the costs will be. Most of the clients want to see something before getting really involved. It would be great to provide ASAP a live Web site and let the client play around and get the feeling, understand the gaps... and it would be the static XHTML itself that you will use further in the development.
On the client... now having most of the functionality clarified by the already "moving" static XHTML prototype, it is time for some more sprints. It is time to go further with the Web design on the live XHTML - you don't have to bother the Web designers anymore with some ASP or JSP or PHP since they usually "like" XHTML, CSS and "PhotoShop" and also you don't have to drive the developers crazy to reproduce some web designer "crazy ideas"... nice on XHTML but scary from within the "X" Server Pages script. Just refine the web design and, when "some server side" is available add the Ajax call layer, the guys doing those don't even need to be in the same room... not that good communication is bad, I only want to point the loosely coupling idea.
The server side... as soon as you understand how the database can be and what business logic you may need (even in the first splint in parallel with the rapidly growing static XHTML presentation), start to build a server side call skeleton with methods returning even test hard coded, with unit tests if you do TDD. The goal is to supply ASAP the server side to support the first Ajax calls... from the already good looking web site... and go to the client again... he will be thrilled about how fast his software grows tailored to his needs... and will pay attention to clarify all that you need.
Now it is mostly clear what to do, so just test and refine the application, e.g. exchange the shortest XHTML possible.
And if the client suddenly discovers that will have 1000 times more hits than expected... just deploy the server side on some big WebLogic cluster and you are done.
Avoid requirement document overheads, allow the functionality to be clarified on live components: what you see is what you get, also a good approach to "get" the client.
Fancy web design is no longer a problem for the learning developers.
Be focused on writing loosely coupled services and render the least XHTML you can with the Ajax calls - XHTML should be static, it is mostly a matter of how you design the application. Why waste server resources to render "dynamic HTML" when you mostly can avoid it?
Keep the Ajax JavaScript layer simple, you need to mostly use document.getElementById and innerHTML. Also be aware that you do not bloat the web server with Ajax calls...
Try to involve TDD on the server side and... Ajax JavaScript layer should be highly testable too - remember, the client will discover new "desires" right before the deadline... and how else can you rely better on your code?
XML is great if you can reduce the database complexity or even if you may need to apply some XSL, but don't overuse XML. Standards are good but you may not need WS and SOAP, a simple HTTP servlet is already a service. Not drowning in technology can greatly reduce costs.
Hope this helps.
| You must Sign In to use this message board. | |||||
|
|||||
