Download: en_AU_10

It should install like any other translation. Hopefully I can get this uploaded to the official list soon enough.

One interesting thing that came up while doing the translation was how powerful the shell (bash) was for assisting me in finding places to correct words. I ended up using the following code to find misspellings in all the CSV files:

cat *.csv | cut -d ',' -f 2 | aspell -l en_AU list | sort | uniq

Basically it will output all the text in the files into a single stream which gets piped into cut to extract the second column (the text that needs to be translated) which is then sent to aspell for spell checking. The output from aspell is then sorted and duplicate words removed. You therefore end up with a nice list of the words that are wrong – or at least that aspell thinks are wrong – which you can put into grep to find exact lines locations:

grep -in word *.csv

This will find all the occurrences of “word” in all of the CSV files and print output which tells you the file where it was found and the line numbers. For example:

Mage_FileName.csv:25:"This is a line where word appears."

Since some of the lines can get quite long, which are then wrapped, and can make it harder to read, I like to cut off the output of the line itself:

grep -in word *.csv | cut -d ':' -f 1,2

The only problem with using aspell is that it doesn’t actually have a dictionary for Australian English! Thus I had to use grep (in a similar method to above) to hunt down words that needed changing. The ones I found are: catalog, color, honor, initialise, authorise (etc), initialization (etc), canceled, and check (=> cheque). The good thing about using aspell is that it does pick up words that are simply misspelt – so the Australian translation is currently more correct than the US English version! Running the same commands over the en_US version will pick up a few spelling mistakes that can be corrected.

I hope this could help someone in doing their own translation – I’m often amazed at how much effort is discarded by a few simple shell commands.

Finally, please let me know if you find any problems with the translation I have created. I’m interested in feedback on any grammatical issues and whether we should have things like Province => Territory.

The first, which was pointed out by Ajazza on the initial post I made for the module, concerned Australia Post shipping to New Zealand. Apparently Australia Post does not offer sea shipping to NZ because the price was coming up as $0.00! I have now corrected this so that it checks if a price will be zero and, if so, does not display that price.

The second two were just things I’d forgotten to do before releasing the module: adding the final BPAY display code to the “info” block as well as the “form” block (so it shows up in the customer’s account area) and changing the BPAY logo URL to be more generic rather than specific to people running Magento on their localhost! Both changes have exposed other things I need to figure out: how do I get the full BPAY info to display in the customer’s order info but not in the admin area? Currently it’s just throwing up errors. And what’s the best way of providing an image as part of a module? I’d also like to know if the template changes could be stored in a directory under the main module code, rather than requiring the admin to install this separately.

First of all, Ext really is just freaking massive. Although jQuery isn’t exactly minuscule it’s still a hell of a lot smaller than Ext. Loading my Ext application, even on a local connection, takes quite a while and freezes the browser while all that code is processed. Admittedly this is more to do with my browser being slow as a dog than with any inherent flaw in Ext. Still, if you want to have a lightweight site Ext is pretty much immediately out of the running.

One thing that I initially loved about Ext, that I am now starting to loath, is that it tries to be too much like Java or some other desktop programming language/library. Basically you can (and probably should) build the entire interface through JavaScript calls rather than use HTML and CSS. The problem with this is that, at the end of the day, it’s not Java and Ext just ends up doing fancy DOM manipulations anyway (for the layouts anyway) so all it’s really doing is obfuscating what’s going on and making sure you are forced to rely on the Ext interfaces rather than DOM manipulation or CSS or the like. Now, 98% of the time this won’t be an issue for you but I’ve run into a few cases where it’s tripped me up because I can’t work out how to get around all the Ext-ness.

In comparison jQuery provides almost nothing but DOM manipulation helpers, which is really useful if you already know what to do but if you want to build a layout like Ext does then you’re going to be messing around with HTML and CSS quite a bit. That said, it really isn’t that difficult to get the basics up and running but emulating something like SplitPane would be painful … unless you find an appropriate plugin. So, for what it does, jQuery is stunningly good. It makes enhancing web sites trivial and removes a lot of the sharp edges from JavaScript without attempting to fundamentally change how you use it.

As an example of how the two differ, here’s some code to run logic when a user clicks on a link and to disable the normal execution of that link.

For Ext:

Ext.select('#links a').on('click', function(event) {
    alert("You clicked: " + Ext.get(event.target).dom.innerHTML);
  },
  this,
  {stopEvent: true}
);

For jQuery:

$('#links a').click(function(event) {
  alert("You clicked: " + $(this).html());
  return false;
});

As you can see, the jQuery code is a bit shorter and easier to understand. To disable the normal browser action of following the link, Ext has a special option on the event handler whereas in jQuery you simply return false from your click function. This might seem counter-intuitive if you don’t know JavaScript so if you don’t, compare the above to how you’d do this without the libraries:

<a href="/foo/bar/"
  onclick="alert('You clicked: ' + this.innerHTML); return false;">
Click here
</a>

You can see that returning false is what you normally do anyway so, instead of encapsulating this, jQuery basically just lets you use the normal way of doing things. Ext, on the other hand, makes things more programmatic and Java-esque by having an extra configuration option to the event handler.

I am still developing web applications with both of them so I can tell you that both libraries are suitable for RIA development, it’s mostly just a question of whether you prefer developing apps entirely in JavaScript or using JavaScript for logic and a little layout, as well as whether or not you need all the advanced features Ext comes with. I think that I would normally pick jQuery because I prefer the simplicity of it and like more control when writing an application. Hopefully this little post has given you an idea of what the two libraries are like and encourage you to try them both out. I’d like to hear the experiences of others working with these libraries, as well as others like Prototype and Mootools, which I am also interested in.

The first order of business has been to upgrade the version of Cake that’s currently being used, 1.2 alpha, to the new 1.2 beta version. I figured this would be simple since the existing code was being kept in a Subversion repository that we had access to and we had a copy of the latest working version. Unfortunately the code had not been checked in for quite a while, and contained updated code, so I would have to do a “first” commit … and this is where the first problem popped up. It turns out that the repository has since been moved to a new server, because of the project change over, so I had to switch the existing working copy over to the new URL. Anyone attempting this themselves: it turns out a Subversion working copy doesn’t like it when you switch targets with some unversioned files inside it. For the first time ever I discovered a ~ next to the status of several directories – this apparently means something is “blocking” this file.

This is where I ran into the second problem, which is actually rather amusing. Trying to fix one of these directories resulted in some circles: first I would be told that they couldn’t be checked in because the file .svn/entries could not be found. Hardly surprising since it didn’t exist. Trying to create it by svn adding the directory, I got told that I couldn’t add the directory because it was already under version control. Going back to step 1 and repeat! My attempts to fix the problem only exacerbated the problem by moving it further up the directory tree.

Thus I found myself using a rather “brute force” approach to fix it: checking out another copy and copying the original working copy’s files over the top of this new one. Thankfully, this eventually worked.

The moral of the story?

1. Don’t switch over a working copy when it has unversioned files in it.
2. Commit your work regularly – something I’m sure most developers forget!

I haven’t had any cause to use this system yet but I’ll be sure to write a review when I do. Anyone else taken this for a spin?

First of all, getting Ext running is slightly more complicated than getting jQuery running. jQuery is a simple matter of including jquery.js in your HTML and then writing your script. Ext requires first it’s own CSS file, then an adapter which uses another library (jQuery, YUI or Prototype) but can also use the newish ext-base.js which doesn’t depend on external libraries, and finally you include ext.js itself. I went with the pure Ext solution but tried out the jQuery adapter and found it didn’t work for me – I’m sure I was doing something wrong but didn’t care enough to fix it and went back to Ext.

Secondly, Ext is rather huge. Not surprising considering what it can do but the whole thing (ext.js, ext-base.js and stylesheet) still comes in uncompressed at just over 512KB. Sorry, I should mention that that’s with Ext’s default minification – the debug versions are a bit over 1MB! In comparison, jQuery is roughly 70KB before any minification is applied. So what do you get for all this size? Quite a bit actually.

The customer info area of my application is designed with a list of customers on the left and an area for details on the right. With pure HTML and CSS a nice-looking layout here, similar to a desktop app, is really difficult to achieve. With Ext it’s almost trivial and you can use a logical declarative style of recursive JavaScript objects to define the layout – similar to how it would be done in Java Swing, for example. With Ext you can also easily get “bonus” features like resizable panes, content areas that adjust to the size of the viewport and a default style that looks pretty damned good (and you have to option of using different themes). Without any trouble I was able to get a simple list working which allows clicking on customer names to load their details asynchronously in the details panel, as well as allowing dynamic updates and the like.

The standard things that I use with jQuery – selectors and AJAX support – are also well supported in Ext, even if they are slightly more verbose. Ext also includes a nifty feature in it’s simplistic load() method that allows you to set a loading message, something that I believe you have ot do manually in jQuery.

Ext also supports a wide range of widgets and the like out of the box. Data grids are all the rage now and Ext makes it simple to get them up and running. Tree views, buttons, colour pickers, date selectors and a bunch of others are provided as well. If there’s something missing you might be able to find a plugin for it.

Overall, I’m really enjoying working with Ext. It makes some fundamental yet complex things ridiculously easy and provides enough of a framework to get almost anything working with a bit of lateral thinking and liberal application of nested layouts and the like.

So I guess the obvious question now is if I prefer Ext or jQuery? Honestly, the two are just aimed at completely different areas. If you’re making a web site that needs some fancy JavaScript effects, a bit of AJAX and you want it to be light and accessible, then I’d say jQuery is the way to go. If you want a RIA with lots of advanced functionality and don’t care about those plebs who don’t have JavaScript then I’d say Ext is definitely the preferred option. If I had to pick I’d say I like jQuery a bit more since I prefer writing enhanced web sites rather than desktop application wannabes but this is really just a personal choice. Both libraries offer the same basic functionality and jQuery can certainly be extended to do pretty much what Ext does so choosing either will probably let you do what you want.

The stuff in the “Source” and “Refactoring” menus especially are a real time saver: being able to automatically create getters and setters, constructors, extract methods, rename methods and variables and a bunch of similar operations are made trivial rather than tedious. The ease with which you can create and run unit tests has also meant that I’m actually keen to create unit tests for all my code – Eclipse will create all the relevant classes and test methods for a given class for you.

Some of the available plugins are really good too. I’m using EclEmma to perform code coverage analysis and direct my test writing. I haven’t set up any source control for my project yet but I hope to use Subclipse to connect to a local Subversion repository automatically. I also installed the C/C++ Development Tools (CDT) package but haven’t attempted any C++ development.

While in the past I thought the layout of the IDE “workbench” was far too cluttered, I have since changed my mind. On a 22″ monitor there’s plenty of room for everything and being able to access everything easily saves quite a bit of time. At the same time I can have information views for the package explorer (displaying all the classes in the project), coverage reports, an outline of the current class and a test report. I’m also amazed at how customisable the whole thing is: views can be moved around basically at will.

I’ve only been using the IDE for a week or so but I find it really helpful for Java development. I would also like to try out NetBeans to see how good it is – version 6.0 was just released.

One of the more interesting things is that applications are developed in Java with the Android SDK and use Android API calls to access device functions such as Bluetooth, cameras, touch screen, etc. Apparently you can use C as well but it’s far more complicated to get everything going so it’s probably not worth your time. I do wonder if other programming languages could be supported via the JVM used. For example, would Jython work?

The documentation for the SDK “preview” is rather extensive for a product that hasn’t been released yet. It takes you through the basics of creating an application, testing apps and explains what the various parts of the SDK are for. From my brief look through everything it appears as though writing applications for Android is pretty damn simple (assuming you know how to program Java).

It’ll be interesting to see where this goes. Despite having been out only a short time, the platform is generating a lot of buzz and with so much major backing here’s hoping it can start a revolution in the mobile world so that mobile application development can be made a whole lot easier.

Update: you might also like to check out this article on Linux Devices.