Testing IE Versions Just Got a Little Easier
Testing your sites on different versions of Internet Explorer has always been notoriously difficult mainly due to the fact that Microsoft prevents you from running to different versions of the browser in Windows. Sure there have been solutions to get around this limitation but in my experience, they’ve always caused unexpected results and instability for the operating system or required you to run a VM. Not ideal.
Jean-Fabrice RABAUTE, the man behind the IE debugger DebugBar, has come up with a nice solution he’s called IETester. This free tool allows you to have the rendering and javascript engines of IE8 beta 1, IE7 IE 6 and IE5.5 on Vista and XP, as well as the installed IE in the same process.
You can check out IETester in action below:
ScreenCast IETester from WebInventif.fr on Vimeo.
(Via Ajaxian.)
YUI 2.5.2 Released: Bug Fixes and Support for Upcoming Firefox and Opera Releases
The YUI development team released version 2.5.2 today; you can download the new release from SourceForge or configure your implementation using the YUI Configurator. This is a focused release that addresses several key bugs while providing support for Firefox 3 and Opera 9.5, both of which are expected to reach GA this summer. Key points for YUI 2.5.2:
- Anticipating Opera and Firefox updates: When Firefox 3 and Opera 9.5 go GA this summer, they will be A-Grade browsers, and we wanted to make sure that we anticipated those debuts with a release that was validated against the latest betas available. YUI 2.5.2 was tested against Opera 9.5b2 and Firefox 3.0RC1. In both cases, the new browsers look terrific, and this YUI release incorporates several changes that will help users make the upgrade seamlessly.
- Major bug fixes: DataTable, Menu, Rich Text Editor and Button are the key beneficiaries of bug fixes in 2.5.2, but dozens of fixes are provided throughout the library. Check out George Puckett’s release rollup in the YUI Community Forum for a complete rundown of what has changed in this release.
- Charts Control: The experimental Charts Control is upgraded for 2.5.2 with support for integral legends and for three new series styles.
- ActionScript Source: The ActionScript source for components that use Flash (Charts and Uploader) is now available as part of the download for developers who want to dig more deeply into these components.
After you’ve downloaded YUI 2.5.2 (or changed your pathnames using Yahoo!’s free edge-hosting service), head over to the YUI Community Forum and let us know how it’s working for you.
(Via Yahoo! User Interface Blog.)
Google Web Toolkit 1.5 Release Candidate
I’m excited to report that there are some fresh new links on our download page leading to a release candidate of Google Web Toolkit 1.5.
Since the previous release of GWT, we’ve seen a lot of really great applications that demonstrate what is possible when you are able to focus on the user and stop worrying so much about browser quirks and other Ajax obstacles. Inspired by what we have seen so far, we have continued to concentrate our efforts on enabling developers to use their existing tools to create web apps that users enjoy. GWT 1.5 takes this commitment even further with exciting new features and over 150 bug fixes. And, like all GWT releases, most of the benefits are just an upgrade-and-recompile away.
We’ve gotten very positive feedback from early adopters and here is what they are most excited about:
Java 5 language support
It feels good to finally close out our most requested feature. GWT developers can now freely use the modern Java syntax including generics, enumerated types, annotations, auto-boxing, and so on.
New compiler optimizations increase performance
With this release of GWT, we’re happy to announce that our compiler produces faster code than you would write by hand! How’s that? A bunch of new compiler optimizations allow us to efficiently inline method calls, even through many layers of indirection. Translation: all the nice abstractions and clean design work that are essential to maintaining a large code base melt away in the compiler’s output, giving your users the fastest possible experience. By contrast, if you were writing JavaScript by hand, you’d have to choose between writing good code and writing fast code — and when your application got to a certain size, maintainability would make the second choice impossible. With GWT 1.5, you don’t have to compromise; just write good code and let the compiler make it fast.
JavaScript Overlay Types
This further enhances GWT’s interoperability with the underlying JavaScript layer. “Overlay type” is a new term we’re using to describe the ability to model JavaScript objects as strongly-typed Java instances with no additional runtime cost. Overlay types make it easy to provide fine-grained interop with handwritten JavaScript libraries as well as providing an optimal way to make JSON structures directly accessible to GWT code.
High-performance DOM API
Up until GWT 1.5, we’ve concentrated mostly on Widget-level APIs, and until the advent of overlay types (above), direct DOM programming wasn’t particularly convenient. GWT 1.5 goes beyond “convenient” and well into “elegant” with an entirely new DOM API that enables type-safe, low-level DOM programming that will be both comfortable to DOM experts and free of any runtime overhead.
Default visual themes
Several default visual themes are now available by default so that developers get an attractive UI out of the box and have a good starting point to create their own custom styles in CSS.
To find out more, download the release candidate and join us in our mission to radically improve the web experience for users. And as always, we are eager to hear what you think so feel free to give us feedback in the GWT Developer Forum.
(Via “officialgoogleblogs-dev” via Google Reader in Google Reader.)
Mac OS X 10.5.3 released
Apple has just released the next point release of Mac OS X Leopard, version 10.5.3. This release has been speculated for a while now, and includes some hefty updates in the 420 MB package. Software Update gives us the following information about the update:
The 10.5.3 Update is recommended for all users running Mac OS X Leopard and includes general operating system fixes that enhance the stability, compatibility and security of your Mac.
Apple posted detailed information about the update on their website. You can download 10.5.3 by opening up Software Update (Apple menu > Software Update …). Have you noticed anything different in the update? Be sure to leave a comment or drop us a tip!
Thanks to everyone who sent in this tip!
SquirrelFish: WebKit has a new, fast, JavaScript engine
SquirrelFish seems to be the code name for a new JavaScript engine for WebKit.
You can see performance benchmarks that show a significant increase across the board of tests.
On average the tests show a 4 times improvement (compared to Safari 3.1), with spikes of 12.6x improvements on some access tests, and with the lowest grade of 1.63x for String unpacking.
This is great news. We are now seeing all of the major browsers improving their JavaScript stacks significantly, which means we will be able to do a lot more. If you are building heavy Ajax applications, this is what you dream off, and at the same time you hope that you can stop worrying about older browsers ;)
(Via Ajaxian.)
Speed up access to your favorite frameworks via the AJAX Libraries API
Google engineers spend a lot of time working on speeding up their Web applications. Performance is a key factor for our teams, and we recognize how important it is for the entire Web.
When you take a look at the effort that it takes to setup work that should be simple, such as caching shared JavaScript libraries, you quickly realize that the Web could be faster than it currently is.
The AJAX Libraries API is an attempt to make Web applications faster for developers in simple ways:
- Developers won’t have to worry about getting caching setup correctly, as we will do that for you
- If another application uses the same library (much more likely), they there is a much better chance that it will be already caching on the users machine
- The network and bandwidth of the users systems will not be taxed.
What exactly is the AJAX Libraries API?
We have worked with a subset of the most popular JavaScript frameworks to host their work on the Google infrastructure. The AJAX Libraries API then becomes a content distribution network and loading architecture for these libraries.
We realize that there are a huge number of useful libraries out there, but we wanted to start small with the program, which has us starting with:
We work with the key stake holders for these libraries to make sure that the latest stable versions of their work get into our system as they are released. Once we host a release of a given library, we are committed to hosting that release indefinitely.
You can access the libraries in two ways, and either way we take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.
The first way to access the scripts is simply be using a standard <script src=".."> tag that points to the correct place.
For example, to load Prototype version 1.6.0.2 you would place the following in your HTML:
<script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js"></script>
The second way to access the scripts is via the Google AJAX API Loader’s google.load() method.
Here is an example using that technique to load and use jQuery for a simple search mashup:
<script src="http://www.google.com/jsapi"></script>
<script>
// Load jQuery
google.load("jquery", "1");
// on page load complete, fire off a jQuery json-p query
// against Google web search
google.setOnLoadCallback(function() {
$.getJSON("http://ajax.googleapis.com/ajax/services/search/web?q=google&;v=1.0&;callback=?",
// on search completion, process the results
function (data) {
if (data.responseDate.results &&
data.responseDate.results.length>0) {
renderResults(data.responseDate.results);
}
});
});
</script>
You will notice that the version used was just “1″. This is a smart versioning feature that allows your application to specify a desired version with as much precision as it needs. By dropping version fields, you end up wild carding a field. For instance, consider a set of versions: 1.9.1, 1.8.4, 1.8.2.
Specifying a version of “1.8.2″ will select the obvious version. This is because a fully specified version was used. Specifying a version of “1.8″ would select version 1.8.4 since this is the highest versioned release in the 1.8 branch. For much the same reason, a request for “1″ will end up loading version 1.9.1.
Note, these versioning semantics work the same way when using google.load and when using direct script urls.
By default, the JavaScript that gets sent back by the loader will be minified, if there is a version supported. Thus, for the example above we would return the minified version of jQuery. If you specifically want the raw JavaScript itself, you can add the “uncompressed” parameter like so:
google.load("jquery", "1.2", {uncompressed:true});
Today we are starting with the current versions of the library, but moving forward we will be archiving all versions from now onwards so you can be sure they are available.
For a full listing of the currently supported libraries, see the documentation.
We are really excited to offer something that we feel can truly help you out, and please give us feedback in our Google Group to let us know how the feature is working for you, and if you have a craving for a particular library to be included.
(Via “officialgoogleblogs-dev” via Google Reader in Google Reader.)
New Dreamweaver, Fireworks, and Soundbooth Betas Released on Labs
Beta releases of the next versions of Dreamweaver, Fireworks, and Soundbooth are now available for download on Adobe Labs. Anyone can download and try the software for at least two days after installation while existing customers of Dreamweaver CS3 and Fireworks CS3 can request a serial number to activate the respective beta for the duration of the prerelease period. For those interested in the Soundbooth beta, we are allowing any customer with any CS3 product serial number (including but limited to Photoshop, Illustrator, Dreamweaver, Fireworks, etc.) request and receive a beta serial number and activate the Soundbooth beta.
For more information regarding each release, follow these links:
* Dreamweaver beta
* Fireworks beta
* Soundbooth beta
(Via Adobe Labs.)
Declarative Syntax for Widgets
Jeff Watkins is updating his MVC library, Coherent, and is wondering if he should add declarative syntax for child widgets. Currently, you have to write a lot of init() setup code, but instead he would like to do something like:
-
-
sample.MyWidget= Class.create(coherent.Widget, {
-
-
init: function()
-
{},
-
-
title: TextWidget(‘div.header em’, {
-
htmlKeyPath: ‘*.selection.title’,
-
-
onclick: function(event)
-
{
-
… handle clicking on the title …
-
},
-
… etc …
-
}),
-
-
nextButton: Widget(‘div.controls button.next’, {
-
onclick: function(event)
-
{
-
… go to the next image …
-
}
-
}),
-
… etc …
-
});
-
Just before calling init, the Widget framework should create sub-widgets for title and nextButton. For the title, its html binding would be connected to the key path selection.title from the outer widget. Additionally, a click handler would be created with the given method. The scope of the onclick method for title would be MyWidget rather than the actual TextWidget.
Using the new Selector library, you could create widgets based on any CSS query rather than just a direct descendant or ID. I don’t think there’s any need to have sub-widgets within the sub-widgets. If that’s what you’re looking for, you probably want to look at creating a widget rather than declaring the structure.
How does that look? Any advice for Jeff?
(Via Ajaxian.)
Parsing OWL XML with StAX
I needed some data to build an ontology, so I downloaded a sample wine ontology from W3C. The file is in OWL (Web Ontology Language) XML format, so I needed to parse it. Ordinarily, I would have used JDOM to parse it, but I had recently heard some good things about XML pull-parsing from a colleague, so I decided to use StAX, which is built into Java 6, in order to check out pull-parsing.
My objective was to parse out the XML file into a simple database structure, so I can use it later. The database structure is shown below. The central table is the entity table which represents a node of the ontology. The relations table links nodes via relationships. The attributes table contains non-base properties of an entity. The distinction between attributes and relationships is kind of gray, but in general I consider an attribute to be a property that we can look an entity up by, such as a name. The attribute_type and relation_type tables are an attempt to normalize repetitive attribute and relation names out of the tables.
I would like to point out that the parser is not a “standard” OWL parser. The tag names to extract information from was determined by eyeballing the wine.rdf file and figuring out which tags would yield interesting information. So it will need to change in order to parse some other OWL file. However, if you are just looking for pointers on how to go about doing something similar, you may find the post useful.
Since this is the first time I used any pull parsing library, I would like to share my initial reactions to this strategy. At first sight, there does not seem to be much difference between SAX (push-parsing) and StAX. With SAX, you intercept the parser lifecycle, adding hooks into the startElement() and endElement() methods to do custom processing, and with StAX, you respond to startElement and endElement events fired by the parser. The difference becomes apparent once you start working with it, however. Because you are working with events, you can delegate processing to sub-methods by passing around the parser reference, which makes your code a bit cleaner.
The code for the parser is shown below. It saves the extracted data into a local MySQL database. Callers would instantiate the OwlDbLoader, set the path to the OWL file and DataSource, and call the parseAndLoadData() method.
(Via Salmon Run.)
JavaScript Super Mario Kart
Jacob Seidelin keeps on going, and has created a Super Mario Kart prototype:
It uses the canvas element to do most of the rendering and should work in both FF2, FF3, Opera(9.27 and beta) and Safari 3.1.1. There are a few glitches in Safari in the kart sprites, but other than that it should be playable. Also, if you’re using WebKit nightly builds, make sure you’re using the latest, as some of the recent ones had some canvas problems. I haven’t even considered getting IE support, sorry.
The (minified) code weighs in at about 11 Kb, but unlike the Mario game from last month, this one uses several external image files. This was more a test of how smooth I could get a game like this to feel, anyway, so filesize wasn’t an issue. I think it runs pretty ok, though.
There are a couple of rendering settings you can play with. “Quality” controls how many vertical lines are rendered, “Screen scale” controls the size of the screen (duh). Both trade visual appearance for performance.
(Via Ajaxian.)
leave a comment