JUnit in Javascript
A recent link from the Mir.aculo.us website talks about unit testing in Javascript. This is an important part of an Ajax toolset.
Jon Tirsen come up with a system that will look quite familiar to JUnit users:
Event.simulateEvent('tobeedited','mouseout');
assertEqual("transparent", Element.getStyle('tobeedited','background-color'));
You can see more here.
DWR has had it's own unit test framework in Javascript for a while. If you download the latest war file you can take a look for yourself. There is an easy link off the index page.
The DWR version contains a front-end which shows you the tests and the familiar green bar as the tests are running. It would be interesting to try using Jon's framework with DWR's UI.
IE7 Reviews
Update: See below.
Since IE7 got out of the starting blocks yesterday some decent reviews are starting to come in.
The most detailed review that I've seen so far is the Mezzoblue blog which looks at long list of IE6 rendering bugs and checks them off as not fixed in IE7.
It appears that IE7, like the other IE's can't officially be run at the same time as other version of IE. Although there is always the trick to running multiple versions of IE in the same OS.
The Register has a horror story about how IE7 nukes Google, Yahoo! search. Robert Schoble got cross with this report and I'd guess that Schoble is probably right in saying that any breakage to Google and Yahoo is not deliberate.
Microsoft may have made a rod for their own backs here. There has been a long history of accusations of Microsoft doing this starting with breaking Lotus with each new version of DOS and more recently with breaking MSN rendering on Opera. I guess people are bound to think the worst if they feel they've been burnt before.
Update
Some more up-to-date opinions:
- Alex Russell: The Virtual Life: IE At Arms Length
- Gina Trapani: IE7 vs Firefox 2: The memory usage showdown
- Matt Cutts: Firefox 2.0 or IE7?
- Derek @ Uneasy Silence: Doom doom dooooom.. IE7 final released
- Elizabeth Montalbano: IE7 finally arrives to kick some Firefox butt
- Steven Parker: Opinion: IE7 is out of the door, Move along Firefox?
- Chris Messina: The beast has awoken; or, The beginning of Web 2.0
- Jeremiah Owyang: At the IE 7 Release Party: Microsoft Gets Community (Photoblog)
- Mark Evans: Will IE7 Kill Firefox?
Javascript - Who wants a compression utility?
When it comes to Ajax apps you can quickly discover that your Javascript code is the major part of your application.
For example my current project is heavily Ajax'ed and contains 4500 lines of Javascript for a tiny 100 lines of HTML and 200 lines of Java server code (excluding libraries). Something like 2% HTML, 4% Java and 96% Javascript!
DWR contains a Javascript compressor and various other Javascript utilities. (You can take a look at the source through CVS at java.net). I put it together becuase I didn't know of any other Java based Javascript compressors under ASF-like licenses, and it occurs to me that other people might find it useful. I can see it being wrapped in an Ant task or as a Servlet Filter.
The question is "Would you like a free one in Java?", is it worth someone's time taking my code and packaging it separately? Please comment if you would use it or if you want to take the Javascript code from DWR and maintain it yourself.
Other languages
For the record I've found Javascript compressors in various languages:
Great web dev tool: Microsoft Fiddler
Microsoft Fiddler is an HTTP debugging proxy. It allows you to see the contents of HTTP requests as well as alter them on the fly using Javascript. You can download it from here and read about it on MSDN.
It works fine with Firefox but if you are prepared to use IE then it's more transparent because when you start it up it reads your system proxy settings and configures itself using them, and then replaces the system proxy settings with itself.
Once configured you get to watch requests in much the same way as with the Eclipse Proxy Tool that comes with WTP.
Fiddler however also allows you to alter the HTTP requests on the fly, or reply them, or script changes using Javascript (sorry JScript.NET).
It is a useful AJAX debugging tool because it captures all your Ajaxian requests and it is nice (and slightly scarey) to see all the requests made by apps that send background requests to auto-update and so on.
Nailing the A in AJAX
There has been some debate recently about the A in AJAX and how much harder it makes life. There is a feature of DWR that does a long way to nailing the problem without hanging the UI thread which I guess people don't know about. Yet...
The secret sauce is DWREngine.setOrdered(true). Which does what it says on the tin - makes sure that we don't dispatch a new Ajax call until the last one has returned.
If you've made a call to DWREngine.setOrdered(true) then DWR keeps a list of the calls that it has been asked to send, but has not been able to yet and sends them just as soon as it can. (So whenever an Ajax call returns DWR checks to see if it needs to send another one out).
It is documented (See the section on "Call Ordering").
The implementation is a work of genius. Someone sent me the code shortly after I pronounced that it couldn't be done so it is neat.
Whilst it is an easy solution that doesn't require much effort, I would generally use the closure solution instead because it isn't much harder to implement and it does not have the draw-backs in responsiveness.
Another DWR feature for UI responsiveness
While we are on the subject of DWR features that are not commonly known, a related function is the GMail style loading message that lets users know that some background work is going on.
Just call DWRUtil.useLoadingMessage(); from the onload event and you get a red "Loading" message in the top right corner. All the demos at the DWR site use this option.
High Volume Websites
I thought I'd worked on some fairly high volume websites until I saw these stats from the BBC last Thursday. Hitwise recon that 28% of all page views in the entire of the UK were to the BBC news website, and that at it's peek they were handling 40,000 hits per second. Outch.
Does anyone know how many hits per second Google can cope with? I thought that they must average way more than the BBC's normal average of 25 million hits per day. But Alexa seems to think they average about the same. How many other people can cope with the BBC's peak of 115 million hits per day?
Ajax: How DWR handles XML
Greg Murray recently noted that AJAX does not need to use XML (although he clearly likes the idea). He refers to DWR using text/plain in it's place. I thought it was worth noting how DWR handles XML.
DWR works a bit like RMI except that instead of having 2 Java systems talking to each other using JRMP you have a web browser and a web server talking using AJAX/HTTP.
DWR marshalls all the Java and Javascript parameters over an AJAX HTTP call, but it always uses text/plain even when it is transferring XML. How does it do this?.
Suppose you have a Java method that looks like this:
public org.w3c.dom.Document getNode() {
/* some DOM code */
return doc;
}
DWR generates Javascript for execution by the browser. For the example above the Javascript contains a text version of the XML document above. DWR arranges for it to be parsed using the browsers internal XML parser and then calls the appropriate callback to recieve the DOM tree.
This may seem like an overly complex way to do things but it means that you can pass around compound JavaBeans which contain a number of things including XML elements:
public class ReturnPojo {
// Getters and setters omitted for brevity
org.w3c.dom.Document doc;
java.util.List collection;
java.util.Properties settings;
}
We could pass a ReturnPojo to DWR and it would create a Javascript object to match in the client, including the DOM document parsed by the browsers parser. Such trickery would never be possible if we only used XML.