Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Ajax: A New Approach to Web Applications
At 5:19 PM on Apr 6, 2005, Matthew Schmidt wrote:
Fresh Jobs for Developers Post a job opportunity
Read the whole article now!
36 replies so far (
Post your own)
Ajax: An approach to web applications that's been around for ages
It's not a framework (it's an approach).And it's not new (I implemented this approach in my company's web-based application software back in 2001). I'm looking forward to next week's article, "writing dynamic websites using server-side code"!
Given how effective this approach is in reducing data/presentation round trips, and how much more responsive (especially when coupled with DHTML and/or XML+XSLT) you can make user interfaces, it's amazing it's taken so many years to catch on. Hopefully this "discovery" might get noticed and websites might become more user-friendly.
Re: Ajax: An approach to web applications that's been around for ages
First, congratulations Christoper for having recognized the value of this approach long before most of the rest of the developer world awakened to it. It probably won't be the last time you start to do something useful before John Q. Developer does. Remember not to lord it over those who haven't seen the light as quickly as you.Second, it may be possible for you to help others use this approach. You can be absolutely confident that there is some percentage (perhaps larger than you'd like to think) of the readers here who have never heard of AJAX yet or who haven't had time to get into the details of it.
I would love for Javalobby to provide a killer "expert presentation" on this AJAX approach, so everyone can see clearly how useful it can be.
Rick
bestuff.com - the best stuff in the world
Re: Ajax: An approach to web applications that's been around for ages
Such an expert presentation would be a great idea.However, I think Ajax is not ready for use yet. There are to much browsers that don't support XMLHttpRequest and after all one should not forget that it is not a W3C standard.
Re: Ajax: A New Approach to Web Applications
I dont think this approach is all that new - I have known of applications before that consisted of large blocks of JavaScript code that was transferred to the client and handled most user interaction without contacting the server in between. There are even Web GUI frameworks today that use a lot of JavaScript under the hood to provide a desktop-like user (and programmer) experience.Personally, I shudder at the idea of a client-side GUI engine written completely in JavaScript. I only hope this is done by somebody else in a way that transparently handles all browser specialties. And then I would like a framework that gives me a nice object-oriented metaphor (e.g., Tapestry, Wicket, Echo, JSF or any other Swing-like API) on top of that. Otherwise, the technology mix could easily become unmaintainable.
BTW, I read that the Wicket team already aims at AJAX, so there is hope..
christian
Re: Ajax: An approach to web applications that's been around for ages
> It's not a framework (it's an approach).Exactly. We've been using it since last summer in our application (using ColdFusion, unfortunately ;)). A framework is what's needed to actually take advantage of the power it provides. Lot's of Javascript and DOM manipulation code and the result is an awesome web-based experience.
Our app hasn't been released yet, but it has produced a lot of jaw-dropping during presentations (even to non-technical audience). Searching, adding, editing and deleting through a single web page, without refreshing and with almost instant feedback, is more than impressive for many people!
As for development burden, it does add a substantial difficulty and slowdown to the whole process, but it's certainly worth the effort.
Re: Ajax: An approach to web applications that's been around for ages
How different is this from JSON-RPC. Refer my post:http://www.javalobby.org/java/forums/t16916.html
conceptually I see that they are very similar.
Re: Ajax: A New Approach to Web Applications
> I dont think this approach is all that new - I have> known of applications before that consisted of large
> blocks of JavaScript code that was transferred to the
> client and handled most user interaction without
> contacting the server in between.
The whole point of XMLHttp is to *contact* the server, but to do it in an asynchronous way (without refreshing the whole page).
> However, I think Ajax is not ready for use yet. There
> are to much browsers that don't support
> XMLHttpRequest and after all one should not forget
> that it is not a W3C standard.
All major browsers support it. Agreed on it not being a standard (yet) though.
Wake up people!
Wake up people!Come on, a superior technique has been developed/hyped/abondened years (or has it been decades?) ago: I think they called it Apples or Applets or whatever - I can't remember
Applets are far far superior concerning speed (is there HotSpot for Javascript already?!) maintainability (hey, it's Java!, not JavaScript), ease of use (no need for silly "hidden frames to dispatch requests" - how stupid is that compared to what can be done using Sockets, URLConnections and so on), cross-browser-compatibility (if a browser doesn't support the Java Plugin you cannot call it a browser
Let's all help and invest into these projects - they will make Ajax absolutely superflous!
Forget about Ajax - this is Javalobby not JavaScriptLobby!
Best regards -no offence intended- Sebastian
Re: Wake up people!
> I think they called it Apples or Applets or whateverThe applet I like has yet to be developed. Every applet I've been forced to use was made very badly (or it is really the technology in this case). Downloadtimes were unacceptable (even for smaller ones) and from my experience Firefox has some problems with them (it seems to freeze temporarily - or for a longer time, depends on the applet).
So I would prefer Webstart instead of applets.
> if a browser doesn't support the Java Plugin you cannot call it a browser
Of course you can.
Ever used links? It is a very nice browser because it doesn't show you images, it doesn't support ECMAScript and it doesn't support any styling. Increases the readability a lot.
> this is Javalobby not JavaScriptLobby!
A valid point, but we also had some nice discussions about C#, Microsoft and others, so, let's have a nice "Java"Script-discussion as well.
> Applets are far far superior concerning speed (is there HotSpot for Javascript already?!)
After they're started: Yes. Before that? No.
I've been developing an Richtext-Editor in ECMAScript for an WCMS I developed together with others. It is very responsive, powerfull and starts fast. We've talked about using an applet, but that was not a valid solution. The existing ones are really bad (read: slow) and some of them have been made by developers which I respect heavily so I won't say it is due to bad code.
Let's take "Editize" as an example.
After I clicked at the demo, this is what happens:
~5 seconds where my browser freezes (it does not react in any way)
~15 seconds until I'm asked to confirm the certificate
~5 seconds until Editize is started.
So, I need to wait full 25 seconds until I'm able to use that editor.
Using my ECMAScript based editor I get the component imidiatly (or a plain textarea if the browser is not supported). There are no issues with repainting the complete application when switching to another tab, etc.
On runtime both are next to equal. They work very well and are responsive, but the startup time and the issues with the browser are to exteme to use an applet.
This might be different for an application that does not have to be reloaded that much, but then I guess WebStart would be usable as well.
Oh and on your thoughts about ECMAScripts: There are tools like Venkman and the JavaScript-Console in Firefox is extremly handy when debugging JavaScript. If I'm not wrong there's even a JSUnit.
Note: I'm not a fan of ECMAScript, but it is not that bad.
Re: Ajax: An approach to web applications that's been around for ages
I'm not saying "clever me, I had the idea first". I'm just surprised at how many people seem to have "discovered" it recently (Ajax, Direct Web Remoting, ...).Well before XmlHttpRequest began to be widely available, you still had the option of using small, nearly hidden frames, containing forms that you could use to drive client/server communication (when the hidden frame is posted, the returned document can contain JavaScript or whatever to notify the rest of the screen's elements that new server-generated information had been downloaded.
Given the market share of Internet Explorer 5/6 and Mozilla-based browsers, the XmlHttpRequest object IS widely available, although not everywhere. Even then, you can still fall back to the JavaScript+forms approach.
Despite all these possibilities, I agree with the text-browser user: the primary function of HTML is information access. Information-driven websites should not use this approach, it's only really suitable for web applications. It CAN -- and should -- be combined with accessibility technologies, I'm a strong advocate of not excluding any user category.
And I don't think web-based interfaces are as good as WebStart-based interfaces either, but that's more of a user-driven decision (if you can be bothered to study your target user group) or a political/management decision.... I also agree that applets have their place, but you can't really deploy anything other than simple applets unless you make informed decisions about who you want to use your website and who CAN use it. We're still stuck with people without a 5.0 JVM or even the MSJVM
So, sorry Rick if the tone of my message seemed smug; I didn't publish this approach anywhere because well it just seemed pretty obvious (I browse API docs and the like with each new product release, just to see what it can do). I hope anyway -- if done well -- we'll get better user interfaces. For those tempted to write websites using "Ajax", remember that "Ajax-capable" browsers also have try {} catch (e) {} expressions in their JavaScript implementations!!! It doesn't need to crash your website...
In an effort to share some ideas then, here's some useful ways to do it...
1) write a javascript file with "interoperability" functions, probably using a decorator pattern. Include it in every HTML document that participates in client/server communication. You'll need to differentiate (between Mozilla/IE) XmlHttpRequest instantiation behaviour, XPath expressions, and XSLT transformations. Here's the function signatures of our implementation:
function createXMLHTTPRequest()
function getXMLHTTPDocument(xmlhttp,optionalParamURL)
function selectSingleNode(element, request)
function selectElementText(element, request, defaultText)
function selectNodes(element, request)
function loadXML(sXML)
function createXMLDocument(sRootElementName)
function createXSLTProcessor(xsltAsXMLDocument)
function applyXSLTParameter(xsltProcessor, param, value)
function transformToDocument(xmlDocument, xsltProcessor)
function nodeToString(node)
function transformToFragment(xmlDocument, xsltProcessor)
You'll probably want to use the following objects in your implementations:
For MSIE:
ActiveXObject("MSXML2.XMLHTTP");
ActiveXObject("MSXML2.FreeThreadedDOMDocument")
ActiveXObject("Msxml2.XSLTemplate")
For Mozilla and compatible:
XMLHttpRequest
DOMParser
XSLTProcessor
XMLSerializer
Note with MSIE, there are two DOM object types, only one of which gets along well with their XSLT processor. The component named by ActiveXObject is installed with IE or the XMLSDK.
2) write a javascript that leverages the above script, and creates an XML document modelling an HTML form. Send this as POST data in the XmlHttpRequest, and you can effectively submit your form, except for input_type="file".
3) write a small server-side Java API that exposes a "form" and "field" object model, with a "read" and "send" method that map onto HttpServletRequest and HttpServletResponse. The request reading should be done with a SAX parser for speed & efficiency. XmlHttpRequest implementations share cookies with your user's normal Http browsing requests, so session tracking works fine. The request/response format should be compatible with (2) and (4).
4) Read in the XML response, and either handle HTTP errors or internal server errors, and present it using a nice little javascript API.
You can use this to "pre-validate" user data, and offer helpful suggestions if their data was incorrect, or alternative form data. It's also handy for updating form elements (like sublists) that depend on other lists.
Other than that, the other "non-Ajax" use of these objects is to have a "skeleton" page with no user interface, and using a small JavaScript, download and cache one or more XSLT stylesheets, and one or more initial XML datasets. You can then generate the user interface, and update it by reapplying XSLT stylesheets to newly-"grabbed" XML datasets. That lightens the server load and is much more responsive for the client.
Don't forget to use simple features like GZIPping HTTP responses where possible for really getting faster network transfers.
Hopefully that'll be useful to someone.
- Chris
Re: Wake up people!
You totally miss the point of a web-app. An applet is a clumsy client-server application. All the advantages a server based application offers are gone when you use applets as the UI. A telent UI is probably a more viable alternative to HTML than Applets can ever be.The Ajax approach, as other have pointed out is not new at all. My company has provided web-applications for several years now, all based on an in-house developed framework that employs the same scheme. The generic JS engine we use is no more than about 100 lines of code. It sounds like Ajax is a lot bigger.
The end result is the same I guess. Listener based UI event handling and transparent local HTML page updates without explicit handling of browser/app communication.
Regards,
Silvio Bierman
Re: Wake up people!
> You totally miss the point of a web-app. An applet is> a clumsy client-server application. All the
> advantages a server based application offers are gone
> when you use applets as the UI.
Huh?! I hope I did not miss the point: I was just trying to say that one could use roughly the same techniques (XHTML document + dom transformations + Soaplike/xml-ish communication between client and server) using an applet: the applet renders the XHTML using CSS, manages the dom and modifies the content in response to events from either the client (mouse gestures, keyboard input, timing events, ...) *and* the server (using sockets, urlconnections and so on the server could easily even push the data to the client). The advantages over AJAX would be: Coding in Java rather than in Javascript, no need for workarounds on the different platforms ("WORA for Ajax") and easier communication, as well as the potential to possibly implement features that cannot be implemented using XHTML+CSS (I am thinking of custom components (Swing-like e.g.) that could be embedded into the HTML).
I don't see why this should be inferior to AJAX techniques, the problem is just that I am not aware of an existing finished XHTML rendering engine for Java/applets and that people think that applets are a bad solution per se.
Re: Wake up people!
Hello Sebastian,Sorry, I now see I misread your previous post. I got the impression you where pushing Applets as a replacement for HTML based UIs.
Using an Applet instead of XMLHTTP is possible. We did that in the early days of our framework. However, it proved to be a lot slower than JS. Apart from the sometimes terrible Applet startup times (varying with different plugin versions) an Applet has terribly slow access (LiveConnect) to the HTML page it is on which makes the (frequent and sometimes many-in-a-single-batch) page updates painfull.
Also, when using a cross-browser JS as we do you avoid the concern of whether the user has installed a Java plugin (which the majority has not). If he has disabled JS then LiveConnect will not work either.
Must say that the initial Applet approach allowed for a nicer communication scheme but that was the only advantage, so we ditched it completely when we got the JS version running.
Regards,
Silvio Bierman
Re: Wake up people!
Hi Silvio,There is still some misunderstanding: My idea was to use the Browser as a container only! The applet itself should perform the rendering - no need for "LiveConnect" and the such - one would not even need JavaScript enabled. This would give you an enourmous performance boost, although the startup-time would still be the usual applet startup time.
However my main point was to use pure Java for "everything", see https://xhtmlrenderer.dev.java.net/ for a possible implementation of the "view".
Best regards, Sebastian