Archive for the 'Reviews' Category

Seems like I’ve been quoted in a book with the (contradictory) title Professional Cairngorm. It’s the now (in)famous Architectural Atrocities 9: Cairngorm’s Model Locator Pattern again. It’s not the best quote to take from that post, but beggars can’t be choosers.

The quote is on page 267 in the chapter “Criticisms of Cairngorm” (where else), and it can be found through Google Booksearch. The chapter also quotes Neil Webb as a critic of the Singleton pattern.

I applaud the author’s good taste in including a chapter on criticisms — although I think that if he really had taken the time to understand what both Neil and I have said he wouldn’t just put us under the sub header “Singled out — Bad Singleton, Bad”. Our critique goes far beyond Singletons and Monostates. Even so, if that is the level you aim for, then those things need to be said too.

Gumbo introduces many new classes, some of which are re-implementations of existing Halo classes (and thus have the same name). In order to disambiguate between Halo and Gumbo, Gumbo classes are prefixed to avoid collisions. Gumbo components that have Halo equivalents, like Button, List and CheckBox, are now prefixed with the letters “Fx”. This means in MXML, a Gumbo Button would be instantiated via the <FXButton /> MXML tag, and a Halo Button would continue to be instantiated via the <Button /> MXML tag. Additionally, the new animation classes in Gumbo also follow the same prefix policy. A Gumbo resize effect is instantiated via the <FxResize /> MXML tag while a Halo resize effect is instantiated via the <Resize /> tag.

From Gumbo Component Architecture

So what are they going to do for Flex 5, use “Fx2″?

Seriously, ActionScript has three* namespace constructs already, why introduce a fourth? Using prefixes is a hack to get namespaces in language that lacks them (like C or PHP), but packages were invented to solve exactly this problem.

In MXML it’s dead simple to use namespaces and prefixes to differentiate between different components with the same class name (e.g. <mx:Button> vs. <fx:Button>). The only place where it gets a bit messy is in ActionScript, but it seems to me that it is a fringe case when you want to juggle both a Halo and a Gumbo button or both a Halo and a Gumbo list in the same class (a Halo list and a Gumbo button, sure, but that wouldn’t cause a clash). I can see it happening, but not often enough to warrant such an ugly solution as this.

I remember when AIR was called Apollo and the WindowedApplication class was called ApolloApplication. This is the same kind of short-sightedness.

* Three namespace constructs: packages, namespaces and XML namespaces (which are different from packages since you can manually flatten a package structure with a manifest, e.g. the Flex namespace contains both classes from mx.core and mx.controls, and others).

Update: Adobe has decided to revert the decision of prefixing the new Gumbo classes. Good for everyone.

The news is that the proposed ECMAScript 4 (ES4) that created such a stir in the ActionScript community half a year ago is no more. Instead the ECMAScript working groups is going to pursue an update to version 3. I say good riddance to ES 4, it had a lot of interesting stuff in it that I would have loved to see in ActionScript, but that was only because ES4 had every possible feature from every language that its authors had ever laid their eyes on.

Read the rest of this entry →

I think that OpenID is a great idea, but there are just too many providers to choose from. Without even actively signing up for one, I’ve got at least six OpenID’s already: one from Wordpress, another from Technorati, and from Blogger, Yahoo!, Flickr and AOL. Either one would do fine, but one thing bugs me: do I really want my identity associated with one of these companies? I don’t dislike either one, but my only relation to them is that I use their products. I don’t think of myself as a Wordpress user, I’m not even a loyal one (my other blog is based on Chyrp).

One solution is to go with an OpenID provider that uses less branded URL:s. By way of recommendation I have found myOpenID, which works. Your ID URL looks like http://username.myopenid.com/, which I think is perfectly acceptable. But it gets better. It turns out that myOpenID has a feature where you can use your own domain in your OpenID URL (look for “Your Domains” in the menu). If your hosting company gives you access to the DNS records of your domain you can set it up so that you can create OpenID’s that look like they are hosted by you — and in the background myOpenID does all the authentication and provides the administrative tools.

In a few minutes I managed to get it configured and I’m happy to say that I can now identify myself as http://openid.iconara.net/theo. That is the kind of URL that I think everyone should be able to have if OpenID is going to become the one and only authentication platform on the web. It describes what it is (“openid”) and who I am (“theo” of “iconara”).

Oh, and is it only me or does the OpenID logo look just like the PlayStation logo when it appears in icon size (as it usually does in login screens and such)?

Adobe has a blatant lack of respect for my filesystem. The various applications that I currently have installed scatter files everywhere, without asking me and with total disregard of Apple’s documentation. Read on for a list of the offences.

Read the rest of this entry →

Today I needed to install Adobe Acrobat, which I’ve so far avoided to install because of its bloated size, slowness and general suckiness. Unfortunately, I really needed it. After searching my drawers for the CS3 install DVD, I pushed it into my computer and though that I’d managed the hard part. Now it should just be a matter of selecting Acrobat and hitting install. Yeah right.

Read the rest of this entry →

When Adobe SwitchBoard was announced the other week I was intrigued. It sounded like something I had been wishing for for a while: a better way to create user interfaces that leveraged the capabilities of the Creative Suite applications, something that the current scripting environment doesn’t do very well. I installed it and read the documentation and my entusiasm quickly faded. It’s the same lame impossible-to-use BridgeTalk technology as before with the same contradictory and strangely inter-application-incompatible API:s, but packaged differently. It’s true that you can create great user interfaces, but the scripting still sucks — and it turns out that it’s a resource hog.

Read the rest of this entry →

If you are tired of application frameworks that tie your code together and makes it an unwieldy mess, take a look at Mate.

Mate is quite unintrusive, lets you configure your application declaratively in MXML and does most of the boring things for you. Judging from the documentation and examples it looks like good competitor in the less-than-crowded marked of Flex application frameworks.

The core of Mate is something called the event map which describes what should happen when your application dispatched events of different types. For each event one or more handlers can be invoked. A handler can be everything from calling a method on an object, running a command or invoking a remote object call and there is room for writing your own specialised handlers. Handlers can also run in sequence and get hold of the previous handler’s result, which makes it possible to create quite complex logic. All this is done in MXML, which means that your configuration is also the actual wiring of your application — and it’s readable and quite easy to understand.

My only objection is how Mate handles updating of views. If I understand it correctly, there are two ways, either you have an injector which looks up the view and pushes values into it, or you have an instance of a dispatcher in your view where you listen for result events and update accordingly. Both remove the benefits of bindings, and while they are certainly better than the global variable lookup of other Flex frameworks, I’m not sure I like them. On the other hand I think you can skip that part and inject the model into the views directly. On the third hand, injectors can potentially make your code more decoupled.

Update: see comments below for a clarification on this issue by the framework’s author.

Some jokers who call themselves flexinmotion have released a ridiculously overpriced Flex component which “will automatically track all user navigation clicks, button click, check boxes, radio buttons and a number of other controls within your app automatically” using Google Analytics. Let me show you how to save those 149 bucks.

Read the rest of this entry →

From time to time I re-read the introductory articles on Cairngorm just to remind me of why I don’t use it and never will. This installment of the Architectural Atrocities series is a critique of the Cairngorm framework, and the Model Locator pattern in particular.

Read the rest of this entry →