Flex Has Forced Me To Think Differently About My Code

Flex Has Forced Me To Think Differently About My Code

Posted by Brad Wood
Oct 04, 2008 20:40:00 UTC
I have been enjoying my dip into Flex so far. Sometimes you don't notice habits until you have to change them. One rut I've gotten into over the years is the procedural way web-based apps have gotten be thinking about programming.The request/response nature of the HTTP protocol gets you thinking of your code as quite linear. A request for a page comes in and the code is processed as quickly as possible from top to bottom and when it is done, the result is sent back. Your code executes in little spurts all day long. Even if you are using latest and greatest "OO" practices, there is still a definite beginning and end to each request, and a given order in which it all happens. Something I'd lost touch with since my Visual Basic days in College was the paradigm of a state-retaining app that was event-driven. Ajax interfaces have been pushing me back in that direction recently. In a Flex app there is technically an initial request and response that serves up the SWF, but once that is out of the way, you are left with a bunch of objects (some visual, some not) and defined events that are being listened for so they can respond. There is no time line per se, and the app isn't done until the user closes it or navigates away. MXML is familiar since it is tag based. Unlike ColdFusion though, it requires the code to be XML compliant. Reminiscent of cfscript, are script tags floating around with Action Script in them. There is a lot of overlap between the AS and the MXML tags. For instance I can declare objects and variables using both. The glaring difference is what the code represents. For lack of a better example, a lot of CFML is more of a control language. It defines processing via if statements and is tightly coupled to the output of what I am coding. CFML is always executed from the top of the page down. MXML feels more like a definition language. I am really just defining objects and their attributes as well as how they respond to events. Each tag basically represents an Action Script class. When tags are nested, you are creating composition as the object represented by the outer tag "has an" instance of the object represented by the inner tag. Inheritance can happen when I define a component (a separate MXML file) whose file name is the name of the component and whose root tag defines the base class being extended. Properties and behaviors are overridden right there in a natural way that almost doesn't even feel overtly "OO" if you aren't paying attention. Like ColdFusion, Flex makes the basic stuff easy. For instance, you can make a basic bar chart with normal looks and the usual expected behaviors with only a few lines of code. Flex really goes an extra level when it comes to exposing all the configurable goodness of its objects though. If I want to format a number as dollars and cents, I create an instance of the currencyFormatter class (with the like-named tag) and call its format method appropriately. I can define custom horizontal and vertical axis objects to control the display details of my graphs. There are near-endless ways the built-in Flex objects can be extended, overridden, and modified. I like the way Flex is making me think. It feels natural and intuitive. The only thing I have done so far that felt "clunky" was the Remote Object calls to my CFCs. I hate having to have a separate function to handle the return; especially when I want it to execute synchronously. I would much rather have something like CF's cfajaxproxy where I could just call my method inline and get the results back on that same line of code. Maybe that already exists and someone can show me how. Well, it doesn't feel like I done writing, but if I keep going I am going to start repeating myself so I'll quit. Let me know if you see Flex the same way.

 


ike

Dunno about Flex, but your comments about stateful interfaces reminded me of some of the ways XHTML is handled in the onTap framework. When I create an index page that lists records for a given db table for example, I'm no longer dealing with the familiar cfoutput or cfloop tags. In their place I have more of a declarative for the behavior of the table.

<table tap:query="myQuery"> <tap:column remove="recordid" /> <tap:column rename="recordname" label="name" href="edit.cfm?recordid=#recordid#" /> <tap:column label="created" type="date" /> <tap:column label="description" type="left" format="40" /> </table>

I'm not sure how accurate that code is offhand. But that's the gist of it. All the stateful behavior of the listing table (pagination for example) is wrapped up in a declarative, "domain specific language" way. I'm not saying it's a replacement for Flex, just noting the similarity.

ike

funny... I just got a bounce response from the mailerdaemon telling me it couldn't alert you about my last comment.

Brad Wood

@Ike: Yes, somehow the IP range that my VPS falls in has been flagged by some ISP's as being use for spam. Perhaps I should ask my hosting company for a new IP address in a different sub net.

ike

well that blows -- but at least you know what the problem is :)

RogerV

The most natural model to program Flex RIA web apps by is this:

RIA + SOA

where interactions are asynchronous in nature and even asynchronous messaging based (think BlazeDS server-side push of events/msgs).

RIA, of course, refers to the client side. SOA refers to the services implemented in the web server middle-tier.

The bane of the old web (before AJAX) was its synchronous behavior.

The fact that Flex supports asynchronous i/o for all of its variations of remoting calls, coupled with ActionScript3 closures to handle results, business logic errors, and transport/network faults, means that the user doesn't have to stare at a web page waiting for it to redraw itself. They can actually keep interacting with a fully visible page, while something goes on in the background that may be getting new data or pushing up new data, etc.

It's possible to even design a visual indicator that signifies something is happening and offer a cancel button (or the equivalent), giving the user a way to abort it if they want (think search critera for queries that probably need to be more refined by the user and tried again).

Also, if you put BlazeDS in the middle tier, you can start doing AMF marshaled remoting calls and can have events/msgs pushed down via the Comet Pattern. This is super powerful way to design client tier software.

If you use AMF object marshaling, I'd recommend that the client-tier swf code and the middle-tier Java .class code be packaged into the same .war file. That way you can manage keeping them in sync much more easily. Deploying those two things separately will eventually just lead to a mismatch when things start getting large and complex.

Lastly, if you haven't done so yet, would recommend designing your Flex client tier where MVC is implemented entirely in the client. For any non-trivial application, it really needs to be implemented ala MVC pattern. So no doubt you've heard of the Cairngorm MVC pattern. It's the one most associated with Adobe and in a sense has their backing. They're provided a home on their web site for it and are allowing it to be entirely open source. To use it, you drop a compiled .swc file into your client project and follow its documented conventions on how to program to it. The thing that will be trickiest to groc is the need for doing events to fire commands and the whole decoupling that is done there between the view and the controller.

Because all your i/o interactions with the web server tier will be asynchronous, I'd recommend writing a single fault handler that you provide as a closure to all such async i/o calls. Handling transport and network related failures can probably be coded once and reused IOW. You might have a way to hook that handler, though, with a way to report or handle the fault that provides some context to the situation that was in play.

So, the upshot is that with Flex - completely abandon the old mental model of handling your i/o interactions with the web server middle-tier in a linear, synchronous manner. Fully adapt yourself to event-driven asynchronous way of structure your application.

ike

>>> It's possible to even design a visual indicator that signifies something is happening

Those are being called "throbbers" ... http://en.wikipedia.org/wiki/Throbber

Brad Wood

@RogerV: Thanks for all the info. I will have to read it a couple times to absorb it all.

@Ike: That's funny-- I never knew those little animations had a name !

ike

@Brad - Neither did I until I saw someone else mention it in kind of the same way. ;)

Site Updates

Entry Comments

Entries Search