We could have done it in DHTML, or using a browser-based plugin such as a Java applet or Flash. Given the need for a smooth customer experience and reliance on development tools, no-one was really keen to use DHTML. Java applets relied too much on deep GUI skills (disregarding things like thinlets), so that left Flash. Flash seemed like a natural fit -- it's well known in the designer community, there's a good infrastructure of tools and support, and it is literally built to look nice.
But Flash had a couple of problems. It was built around movies, and we wanted to write a GUI. So we looked at Flex.
I took a long hard look at Flex before I decided it was a good thing. I wanted to make sure that it was a real application and not a marketing gimmick. I didn't trust the blogs to come up with the right answers, so I poked at it myself until I was fairly sure that it didn't stress the server, didn't stress the client, provided features in the context of a conceptual framework and had all the obvious bugs worked out from the first release. I looked at Laszlo and another tool, but it was obvious that they didn't have the depth that Flex did.
For Java people, Flex has a number of similarities to javascript, J2EE and Swing models. Like JSP, MXML is an easy to use format that is converted on the fly to a lower level programming language (Actionscript), and then compiled to bytecode. In MXML, like Javascript, a component can fire off events and methods are called in response to those events. Best of all, Flex contains the idea of a dataProvider which provides the classic Swing separation of model and view.
In short, Flex is not a completely new paradigm. It's a synthesis of already known ideas. I consider this a strength. It is reassuring to see something that you've seen before, and it's good to know architects of this system use the same mental shorthand. There are fewer surprises. So we picked Flex, and then worked on making it do what we wanted it to do.
The short version of the story is that we all worked very very hard, the project was a success, and the lighting configurator was Macromedia's Site of the Day. The long version will probably turn up sooner or later, but here's the technical skinny before I get too familiar with Flex and start drinking the kool-aid.
I worked through a number of prototypes during the design phase to be sure that I had a good understanding of the relationship between MXML and Actionscript.
For the most part, I didn't have a problem with anything in the actual framework itself. The new stuff is good. My biggest issues in Flex were to do with Actionscript and the Flash MX framework underlying Flex. Bear in mind that I approached Flex as a complete newbie, with a good theoretical understanding of Javascript and the iterationtwo and Moock books. As a result, some shared understanding was missing.
My biggest beef has to be with Actionscript. I realize that I'm approaching this from an enterprise Java perspective, but I can see good choices made on top of bad ones on top of good ones. It feels like Perl worked over by the Ada committee and then handed off to Gosling. For example, I understand the need for strong typing, and the rationale for mixing strong typing with weak. But Actionscript specifies a type using postfix notation:
var s:String = "foo";
I can see absolutely no advantage to this notation. Except for maybe copying it into UML diagrams.
There are exceptions in Actionscript. But they're all unchecked. And they're inconsistently used. This is almost worse than no exceptions at all.
There's a difference between null and undefined. I believe this is from Javascript, but I dislike the idea that there is an undefined value at all. Wasn't null magic enough?
Every untyped object in Actionscript is an associative array. This means that you can say:
var o = new Object(); o.name = "test"; o.age = 25;
And it gets stored with the keys of "name" and "age", respectively.
This is good in one way, because it means that with a single debug call, you can get to all the properties:
public function toString(o:Object) : String
{
var msg:String = "Object:";
for(var prop in o) {
msg += " ";
msg += (prop + " = " + o[prop]);
}
return msg;
}
The bad news is that if you get an event, you have to poke around with the above method before you know what it is and what you're supposed to do about it.
if an array is passed through as a parameter and there's only one element in the array, then the parameter appears as a single element instead of an array containing a single element. Why? It's a "feature." This is a feature the same way it's a feature to have a single tube for both breathing and eating: it sounds good right up until you breathe a peanut and choke to death. Seriously, it took me almost a full day to figure this one out. What happens when the array is empty? I never tried. It probably represents it as null.
The final, inexcusable, really bad thing in Actionscript: no NullPointerException. If you call a method on a null object, the result is null. You have no way of distinguishing except by an equality test. This would be acceptable if there were a lint for Actionscript, but from what I can tell this is just The Way Things Are. There's not even a 'use strict' option for us language fascists.
Then, once you get past the Actionscript design decisions, you run into issues with the Flash browser. The documentation says that Flex supports CSS. This is true to an extent, but it is limited to what the Flash plugin will support. CSS1 supports the text-decoration attribute, but you cannot use the strikethrough option because the client can't display it. Macromedia support supplied a custom component that overrode the component draw method with a strikethrough as a workaround, and we were good to go with an hour.
We also ran into a bug with mx:Text not displaying HTML correctly. Resource Interactive found that htmlText cannot be used with embedded fonts (we were using Minion) and the workaround was to use a font tag:
<font style="Minion">{ my.text }</font>which was inelegant, but it worked. CSS divs and styles do nothing with embedded fonts. It has to be old school.
The only issue I ran into directly with Flex was the difference between Flex 1.0 and Flex 1.5. The iterationtwo book is good, but it provides code examples which are already out of date. That is, the book suggests
public var _remoteClass = "com.rh.flexlighting.proxy.ShadeSKU";
when it should be using:
public static var regClass = Object.registerClass("com.rh.flexlighting.proxy.ShadeSKU",
com.restorationhardware.lightingapp.vo.ShadeSku);
Even with the minor version drift, the iterationtwo book is mandatory. You simply will not get a good idea of Flex without it -- the Macromedia documentation is good, but far too linear and abstract to get a handle on. Iterationtwo has worked on this stuff in real-world projects, and they understand very clearly what questions developers ask and in what order.
That said, Flex is great. It's easy to use. The communication between client and server is done with POJOs, is easier than RMI, can be debugged over the wire using Flex Builder, and can be configured through a single flex-config.xml file. There's a
I think I've written about this before, but really Flex is overdue. Something has to replace HTML (or evolve it), and I don't see another decent competitor right now: Avalon is vaporware, Laszlo doesn't have the infrastructure, Mozilla has a bad habit of changing APIs faster than the books can come out, and everyone gave up on Java applets in 1999 and are shy about going back.
Flex doesn't make any shortcuts. It's an extensible, complete XUL framework that insulates you from the Flash underpinnings without cutting off any functionality or future expansion. There's a very strong feeling from the code that the Flex architect want to get this right, and for the most part they've pulled it off. It's actually fun to use.