Use the JavaScript console in Firebug and run the following script snippet:
var xmlhttp = new XMLHttpRequest();
xmlhttp.open("HEAD", "the_url",true); // Async HEAD request (relative path to avoid cross-domain restrictions)
xmlhttp.onreadystatechange=function() {
if (xmlhttp.readyState==4) { // make sure the request is complete
alert(xmlhttp.getAllResponseHeaders()) // display the headers
}
}
xmlhttp.send(null); // send request
cache-control, pragma, no-cache, expires header, and tons more. I learned a lot from the below referenced articles.
Caching tutorial for web authors: http://www.mnot.net/cache_docs/
jGuru forum question: http://www.jguru.com/faq/view.jsp?EID=377
I just invested 30min to find tools/libraries which allow me to use PHP scripts instead of Java on the server when the front end is GWT. There are various potential channels through which GWT and PHP can talk to each other. GWT RPC, ideally native or over JSON/XML would certainly be the most obvious choice.
My Internet search didn’t turn up a whole lot of useful stuff…
http://code.google.com/p/gwtphp/
http://code.google.com/p/gwtamp/
http://code.google.com/p/lacertae/
http://download.boulder.ibm.com/ibmdl/pub/software/dw/xml/x-gwtphp/x-gwtphp-pdf.pdf
This blog uses the iTheme for its layout and graphical representation. However, I wasn’t satisfied with the fixed width of 770px. In a time where wide-screen displays have become common I felt that a lot of precious screen space was wasted left and right of the actual blog content. So, I widened it by 224px. It should still be perfectly legible with an older standard resolution of 1024×764, though.
Please let me know if you have trouble reading this blog on your screen.
Furthermore, and this is really important to me, the calendar icon with the blog post’s publication date doesn’t just display month and day but also the publication year. There must be a valid reason why so many themes don’t include that but for me this a bug and not just a missing feature. Fortunately it was easy to fix for iTheme. On line 10 of iTheme index.php I replaced
<div><span><?php the_time('M') ?></span> <?php the_time('d') ?></div>
with
<div><span><?php the_time('M') ?> <?php the_time('y') ?></span> <?php the_time('d') ?></div>
I recently started surfing the Internet with cookies disabled in my browser. You wouldn’t believe how many sites that require cookies to be enabled fail to tell me so. I would guess it’s about 90%. Most often I notice this when I try to log in to a site and simply can’t get past the login dialog. Sad if web developers don’t think that far…
I’ve long given up sending a friendly email to the respective webmasters – it’s just too time consuming.
After many hours searching the Internet for GWT widget libraries, analyzing them, and taking notes I thought I might as well publish my findings here. Feel free to comment and point out inconsistencies.
At the moment the market seems to be split into two segements:
- a few small or medium-size, low-key libraries with little activity
- the whole “Ext” gang
However things change very quickly, in a matter of months, and the end of 2008 saw the advent of a new-kid-on-the-block: SmartGWT.
Small, or medium-sized libraries
The “Ext” corner
A long time ago (think Internet time 
) a guy called Jack Slocum built an extension to Yahoo’s YUI widget library named YUI-Ext. It evolved and became independent, Ext JS was born and with it a new company: http://extjs.com. The library quickly became very popular.
Once GWT was released people started writing widget libraries for it. Boston-based Sanjiv Jivan started GWT-Ext and based in on Ext JS. Darrell Meyer wrote MyGWT, a pure GWT widget library which shared the Ext JS l&f. It was voted #1 widget library one year ago.
In April 2008 things became very nasty an confusing when Jack Slocum changed the Ext JS license from LGPL to GPL thereby forcing GWT-Ext to stick with Ext JS 2.0.2 which was the last version available under LGPL. Furthermore, he hired Darrell Meyer who brought his MyGWT as a dower into the relationship. As a result, Ext JS published its own GWT widget library called Ext GWT. Now developers had the choice between GWT-Ext (full OSS with LGPL) and Ext GWT with a dual-licensing model. The GWT widget “war” (see references 1-5 below) turned many away from Jack Slocum’s Ext JS because they disliked the way the company treated the GWT community.
On November 26th, 2008, the game changed again when the GWT-Ext crew announced that they would no longer build major new features but instead be migrating to SmartGWT, a library created by GWT-Ext developer Sanjiv Jivan . SmartGWT 1.0 had been announced only two weeks earlier.
[1]http://www.jroller.com/sjivan/entry/my_response_to_jack_slocum
[2]http://pablotron.org/?cid=1556
[3]http://www.gwtsite.com/ext-gwt-gwt-ext-what-now/
[4]http://ajaxian.com/archives/to-gwt-ext-or-to-ext-gwt
[5]http://gwt-ext.com/license/
Whenever I’m confused about the wmode parameter when embedding Flash objects into websites I turn to http://www.communitymx.com/content/article.cfm?cid=e5141. It describes the three modes “window”, “opaque”, and “transparent” with just the right degree of details and contains sensible demos. Of course, it’s helpful that the explanations are also related to DHTML menus because problems with those most often rise questions about Flash’s wmode parameter.
I always get annoyed when I end up at sites where the developer (deliberately?) forgot to set the focus to the relevant input field if there is one. IMDB, as great as its content is, for example fails to give that hang-on-to-your-keyboard experience. I assume that usually you don’t want to switch from keyboard to mouse first in order to put the focus in the search field before you can start typing again.
As a remedy a wrote a little Greasemonkey script that focuses the first “text” input field (text, password, textarea) in the first form if the field is visible i.e. inside the view port.
You may ask yourself whether there are no other scripts available that solve this issue. Sure, there are, but their limits were not acceptable for my needs.
Being a software engineer I of course have both Firebug and Adblock Plus (ok, this has nothing to do with being a programmer ) Firefox extensions installed on all systems.
As one of its tasks Firebug dutifully reports all script errors. For quite some time I wondered why so many sites using Google Analytics fail with a
“urchinTracker is not defined” error. Turns out Adblock by default blocks requests to http://www.google.com/analytics/*…
Furthermore, like millions of others I’ve subscribed to some recommended filter lists. Among them is the Adblock EasyList tracking list. This, however, I had long forgotten; that’s the flip side of such fire-and-forget list subscriptions. Turns out one entry in the tracking list blocks access to URLs containing /js/urchin.
So far, so good. It doesn’t really matter if a single “standalone” call to Google Analytics fails. It’s much worse if the calls to a tracker are embedded in a JavaScript function with some real business functionality. Firefox for example preempts script execution in a function when it encounters a script error.
The Union of European Football Associations, UEFA, offers pay-per-view live video streams of all games at the EURO 2008. However, when you click the “Pay” button Firebug reports “_hbSet is not defined” and nothing else happens. UEFA uses HitBox to track their web traffic. Not surprisingly, EasyList’s tracker list contains two entries that block such requests: /hbx*.js|$~other,~object-subrequest and /js/hitbox. Since UEFA’s invocation of the _hbSet() prototype function is embedded right in the middle of their business logic inside the openVideo() function this fails badly. openVideo() is called, goes about its business, fails to find _hbSet() and stops the further execution of the rest of the code.
Oh, and all you webmasters out there trying to track our surfing behavior, would you be so kind and check the existence of an external JavaScript function first before calling it. Thank you.
if (window.urchinTracker) {
urchinTracker();
}
Or at least place all the tracking code at the very end of the business logic.
Microsoft’s Internet Explorer never fails to amaze me – coding JavaScript and CSS for the IE is quite a challenge. The other day I tried to show/hide a table based on the value of a dropdown box.
function hideUnhideDateFields() {
var tarifScheme = document.getElementById("dropdownTarifscheme");
var dateTable = document.getElementById("dateTable");
if (tarifScheme && tarifScheme.value == "") {
dateTable.style.visibility = "collapse";
} else {
dateTable.style.visibility = "visible";
}
}
While this works flawlessly with browsers, the script crashes in IE: it complains about “Could not get the visibility property. Invalid argument.” Hey IE, talk to me, what is your problem?
I couldn’t get behind it and switched stratey, therefore.
function hideUnhideDateFields() {
var tarifScheme = document.getElementById("dropdownTarifscheme");
var dateTable = document.getElementById("dateTable");
if (tarifScheme && tarifScheme.value == "") {
dateTable.style.display = "none";
} else {
dateTable.style.display = "";
}
}