In Professional Flex 3, I wrote a chapter on integrating Flex with Java-based Web Services  (see below to download actual chapter).  More specifically I used Grails (similar to Ruby on Rails, except for the Java world), which is based on Groovy (a dynamic language that compiles to the Java platform) to expose SOAP-based Web Services to the client built with Adobe Flex.  The application isn’t anything sexy, but does show CRUD-based data operations for a Flex client using a SOAP-based Web Service implemented on the Java stack.

Note, in the actual book, there’s also similar demos (that I wrote), on http’s RESTFul web services with the ZEND framework (see Chapter 49 in Professional Flex 3), and Soap-based Web Services with Microsoft’s .NET WebService stack and the ADO.NET Entity framework (see Chapter 51 in Professional Flex 3).

Here’s just a few reason why I think Grails/Groovy for the Java world are great:

1)  All your syntactical sugar of the dynamic languages for the Java platform.  If you program in Python or Ruby you’ll know what I’m talking about.

2)  Reliable, proven runtime with Java.  Enterprises have been running a variety of highly supported Java runtimes supported by companies like Apache, IBM, Oracle, ATG, etc…

3)  Most likely, your operational teams and data centers already support Java VMs and have operational procedures in effect around maintaining such infrastructure.  While, they won’t be switching to a LAMP-based open source stack anytime soon, there is probably a path you can go down to use Groovy and Grails for application development that can be released to existing infrastructure, hardware, VM’s, etc…

Anyone stuck in a large corporate, enterprise environment at least has an option to get some syntactical sugar and agile speed in their development environment.

Now, add a sexy Flex interface and you’re cooking.

My publisher Wiley is allowing me to offer up the chapter.  You can download it here  (335KB PDF file).  Don’t forget about the source code for Chapter 50, which is available here at Assembla (Subversion repository).

I hope you enjoy.

It’s Here!  For about a year I worked with a team of smart guys (Andrew Trice, Joseph Balderson, Peter Ent, Jun Heider, Tom Sugden, David Hassoun, Joe Berkovitz) to create what we think is one of the best books out there on Adobe Flex.  It’s around 1400 pages, nearly 5 pounds, of comprehensive knowledge.  It’s available at Barnes and Noble and Amazon.Com, and probably your local bookstore or wherever Wrox books are sold.

I’m proud of this book.  It was hard to write and took way more time than I thought it would.  But the end product is outstanding.  It’s one killer book that covers a lot of the internals of Flex, including the extras like Cairngorm, unit testing, AIR, Flash Media services, FXG, Flex Builder, Subclipse, custom components and the component lifecycle, skiing, Flash integration, etc…  It’s all covered.

I was responsible for writing about Adobe AIR and a lot of the server side data stuff, especially in regards to open source, Java, and .NET.  I did a lot of work to show the flexibility (no pun intended) of working with Flex and a variety of back-end technologies.  Specifically I have demos in there working with server-side data using:

• PHP and the Zend framework over a RESTful-based framework
• Java WebServies created using Grails and Groovy.
• .NET with WebServices

I have some follow ups that I want to write about.  Specifically, I want to port the Zend framework samples to use the new AMF support.  And while I’m at it, I’d like to port the Grails example to use AMF, too.  BTW, I believe GRAILS is the Holy Grail (dang, another bad pun) for Java Developers wanting some syntactical-love in their lives, yet at the same time harnessing all those enterprise APIs and existing operational infrastructure that seem to chain them down.

To get you started, Andrew Trice, one of the co-authors, has posted a nice excerpt from the book: Chapter 67: Application Performance Strategies.

While Flex 4 and Flash Builder 4 are on the horizon for being released, they both still rely on the fundamental technology presented in this book.  This book will be a great addition to your team library, especially for getting your new developers up to speed, or your existing developers to learn some advanced techniques.

Go forth, read, and build great applications.

Yesterday I came across a post over at Inside RIA (probably the best place to keep up on RIA ) about a handy new mockup Tool called Balsamiq Mockups.  In the past, I've used a lot of Viso and PowerPoint with various templates for doing mockups, so I'm always interested in tools that help me with quick and dirty screen design to communicate concepts.  I'm even more interested in tools that are built in cross-platform tool kits that can perform this.

This post isn't only about about screen mockup software (though a brief review with follow), it's about the power of Adobe AIR and the Flex platform.  Its been awhile since I've seen some exciting AIR work (I know it probably exists), so I thought I'd write some of my thoughts out...

Since AIR hasn't been around very long, there's not a very long list of applications that really shine and show it off (Twhirl, FCG, DestroyFlickr are really good ones, though).  Most, though, that I've looked at are semi-finished, with minimal polish.  But thats OK, it takes time to build a properly polished desktop application, and I'm sure a lot of the applications were built to play around with the new toolkit.  But none have really held merits on their own as just being must-have applications.  99% of every AIR application I've tried has been uninstalled because either they weren't very polished, only performed a subset of what they'll do (early betas), or there's nothing extra that they do that the versions running as Flex applications inside a browser can do, or that even a regular web application can perform.  And I always say, if it can run in the browser, don't make me install an application to my machine.

I think this is where Balsamiq Mockups really shines.  Its a tool that no matter what it was written in (it happens to be Adobe AIR) that I feel I could finally keep on my desktop, and not just to tinker with because I work with AIR and Flex.  It shows off a rich UI that is well thought-out and very user intuitive.  Flex is being shown off here, too.  The Flex graphics apis are one of my favorite parts of the toolset, and Balsamiq really shows off how nice of a layout engine can be designed (theres other Flex apps, too, that do mind mapping, etc. that I've seen, I just don't have the links handy).  When dragging components onto the canvas, the hinting for aligning with other objects is superb and so simple.   One of my favorite things about Flex and AIR is ability to build modern UIs as Balsamiq Mockups demonstrates. 

Nevermind that they already have an upgrade path to Linux for when the AIR runtime is released.   AIR has the potential to huge for Linux desktop application development.

Things that make Balsamiq Mockups a great little application:

1)  The layout engine and ability to aline things simply

2)  The little iconwidget that lets you explore their library for little icons

3)  Super simple to use

Here's a little mockup I made of Eclipse with Flex Builder in debug mode:

Its nothing fancy, but it did only take me about 15 minutes to put together, and that's including the time needed to explore all the available mockup compoents, different properties they support, etc....Notice how easy things more the most part align.  It was really quite easy.

Some features I'd like to see implemented:

1)  A library of other screen elements that you can browse online and import into the application.  Maybe even have an API so third-party devs could build these UI components and publish them to this browsable repository.  After all, Adobe AIR is about connected applications.

2)  Ability to adjust the font size of screen elements.  Some of the elements, like the Link Bar allow changing the font sizes), but I'd like to see this extended to some of the other elements, like the Tabs Bar.

3)  A tree mockup component.  UPDATE: Found it in the component finder called "Tree Pane"

4)  A vertical Button Bar.  In fact, just make a Button bar that's either horizontal or vertical, and make it really easy to add either icon buttons, text, or both!

5)  A mockup Grid component.   UPDATE: Found the DataGrid, had to type it in the component finder in the top (I didn't see it in the component bar)

6) an online Flex version with saving PNG files locally via proxying through the server.  (Hey, what can I say, I'm a bit adverse to installing software, when a simple software link could do the trick.)  I understand though, the perceptions of paying money for software and having a nice desktop download, and not having to wait for all the graphical assets to load, though...just thinking outloud.

That's about it as far as what I have to say about this usefully simply screen mockup tool.  Though the tool costs money, it's actually useful and pretty polished, so its probably worth the $80 or so.

About cross-platform development in general:

In the past I've looked at a lot of cross-platform toolkits, like QT, wxWindows (and wxPython bindings for wxWindows), and java toolkits such as Swing and QT's Jambi.  I think AIR has the potential to really help in cross-platform application development, because I have some issues with all the prior one's mentioned (I'll write about that later).  My only hope is that Adobe releases other security settings so that you can run AIR applications as full local applications with full access to the operating system and other applications (this is AIR's biggest downfall at the moment).  This is needed to get the hardcore desktop developers interested in building software that integrates with other services (Yeah, I know about the Merapi project, but if I'm going to have to maintain and ship the java JRE with my AIR application, I'd seriously have to consider not using AIR and instead settle for QT's Jambi...actually I'd probably still prefer the AIR and Flex toolkit and deal with shipping the java runtimes...).

Anyway, keep up the good work building these tools and these applications.  Get enough kickin' applications written in AIR, then it wont matter what operating system the user wants to use they'll be able to use your application.

Now that Adobe's released the final bits to Flex 3 with Adobe AIR support, my latest article Digitally signing Adobe AIR applications has been posted over on Adobe DevNet.

Read it if you're interested in understanding a bit about the code signing process, including certificate acquisition, and signing from all the tools Adobe supports AIR application creation from: Flash CS3, Dreamweaver CS3, Flex 3 SDK, and Flex Builder 3.

Cheers.

ABC.Com has been offering full episodes of shows to watch over the web, but what's new is their offering of Lost in HD 720p.  Personally, I haven't watched the show since Season 2, and it seems to have been getting a little long in the tooth with long drawn out plotlines traveling the road to Snoozeville.  However, the fact that 720p is being broadcast over the Internet with such ease is pretty darn cool.

Since the site is Flash, I assume they're using the new Flash HD streaming capabilities that Adobe released in early December for streaming the HD content.  There's a couple of HD demos of the new Flash Player showing off the new HD capabilities on the web, but ABC.Com is the first mainstream content provider I've seen to use the technology.  And I gotta say, it works and looks spectacular.

They have a few 30 second commercial breaks (sponsored by LG), interspersed throughout the episode I watched.

The stream came down to me at 1388 kbp/s and it looked fantastic.  I only have a 180 KB/s Internet connection and it didn't stutter once upon playing, compared to when I last tried the NetFlix WatchNow streaming service in which I could only get the medium quality option because of my crippled Internet connection.  Back with the ABC Video Player, there was some initial interlacing when the stream started playing and my initial reaction was "this isn't HD", but after about 20 seconds, probably when buffering caught up, it looked really, really good.  Did I say how good this look?  We've come a long ways since the days of Real Media over a 56.6K modem!

This is a huge step forward in content sharing.  Companies are interested in fulfilling the niche market of letting people watch television on their own schedule.  I can't wait until some form of devices that sit on our television can play all this content like this.  Blu-Ray, HD-DVD players....bah...just let me stream the content directly from a source.  We know it'll eventually get here.

To me, the DVR is a temporary hack.  The future is going to be all about watching the shows/movies you want to watch, when you want to watch them.  I'm not interested in maintaining my own media, media servers, remembering to get a season pass to a show, etc...  I want everything to be onDemand.  And with Flash player streaming HD content smoothly and a mainstream content provider offering up premium content, we're well on our way.  ABC's putting LOST up on the web (obviously to promote the new season coming out) in HD is one little step closer to my media dreams.

Now the question is, when will the FLASH player be getting embedded into little media devices?  Also, if anyone in the technical know knows the details going on behind the scenes with ABC and their HD streaming, feel free to comment on it.  I haven't really had any time to dig at any depth into how/what ABC is using for delivery of this HD content, I'm only assuming the new Flash "Moviestar" player.

An article of mine, based on a previous blog entry, has been posted to the Adobe AIR Developer Center for Flex.  Read about Building Flex and Adobe AIR applications from the same code base.  The Adobe Developer Network version goes into more detail and has a pretty UML diagram to make it all sensible.  Check it out.

It's been awhile since I've posted anything here.  Which ostensibly means I've been lazy.  However, in reality, I'm busy as ever, and I have several half-finished postings that I hope to post soon on such topics as:

• Using the new goods in .NET 3.5 and Visual Studio 2008 to write a back end for Flex -- especially interesting is the new Astoria functionality that will add RESTful web services to your .NET backend.
• An ImageProgressBar component that uses an image and selectively applies visual formatting as progress occurs.  In this case, it converts from B&W to color as progress proceeds, or from color to B&W. 
• A component for building thumbnails from a directory of images in Adobe AIR.  This isn't as simple as it should be due to processing long operations in the Flash timeline.  Don't worry, I have an event chaining solution that keeps your application responsive while generating thumbnails.
• Summary of all the different ways and technologies that Flex/AIR can access a back end.  (This is mostly for my own benefit, since it's hard to find a complete listing of both Flex and .NET libraries.)
• Code generation with Python, especially useful when using Cairngorm as a framework (I have some scripts that mimics Ruby on Rails generators.  Don't be shy about the command line.)

I'll get these things polished as I find time, which has been tough these days.  I'll start with one this weekend.

Now that the AirDerby deadline has passed, people are starting to show off their cool applications.  I've been to a few sites that have an "Install Now" badge (like the Adobe AIR Sample Gallery).  These badges allow the user to click on a link and both the AIR runtime and AIR application will be installed for the user.  This sounds very enticing and is a very easy method for the user to install your application.  However,  despite not even working on my system (Windows XP SP2, Firefox and the latest Flash beta), and despite Adobe's touting of this as a feature (AIR Install Badges), THIS IS A VERY BAD PRACTICE.  There's negative stigma associated with installing software from the web browser, especially software that can access local files.  A CTO sees this and their scared-off searching for other development options.

JUST SAY NO TO WEB-BASED INSTALL

The stigma of installing software from links on websites to my local system scares me.  Over the years, I've trained all my users and friends that it should scare them, too.  We can probably thank Internet Explorer and the days of ActiveX Controls for this.  Using the AIR "Install Badge" gives the user a very similar experience as ActiveX in the old days, which nobody in their right mind uses anymore because it's associated with the virus mayhem (not to mention C++ complexity).  Why do we want to bring this into the new and exciting world of Adobe AIR?

Users of fine software understand the need to  install software to their local system, and that when they do, they should really trust the source of where that software came from.  For this process, they're trained to download the .DMG(OSX), .MSI (Win), etc. to their desktop, and then double-click to invoke the installer.  This is something they are comfortable with, and more importantly it's also a process that raises the user's awareness that what they're about to install could be dangerous to their system.  Installing AIR applications from a web-page doesn't make me feel comfortable, despite being prompted with dialog boxes announcing that the code is signed code and asking me where I want to install it. (Adobe is doing a good thing by requiring AIR applications to be signed.)

The use of these badges, and the prompts a user reads, is very reminiscent of Internet Explorer and it's ActiveX control installation process.  And no one trusts that these days, so why duplicate that installation process with the Adobe AIR product?  Some proponents of the badge might argue that there's the automatic FLASH installers.  For this, I'd say that Flash is ubiquitous enough, and has enough familiarity that this falls into a different category because users are comfortable installing FLASH.  It's the Coke-a-cola of multimedia viewing on many web sites.

Let's not confuse users, nor tarnish AIR applications by even offering this service from a web page.  Instead, have your users download the AIR file, and then manually install it.  This sends a clear message:  you're installing a full desktop application that might be bad for your system, you should be aware of this.  This physical act is more important than the reading of dialog boxes.

A suggestion for a better install process

To go a step further, I'm really hoping that Adobe offers some form of packaging for AIR that is native to each operating system.  As a developer I can distribute a single DMG or .MSI file  that the user downloads.  Inside this DMG or .MSI file is the AIR runtime (the version that my application was developed with) and my custom AIR code.  I don't mind the 8 to 10 megs of overhead this brings.  This way, users can install software with the appropriate prompts that they are used to from native installs.  The Mac users can drag the application to their Applications directory; Windows users can answer all the appropriate prompts.  This is an installation process that end-users are both familiar and comfortable with.

Not to mention, this install badge doesn't even work for me!

I'm on Windows XP sp2 and Firefox, and the latest Flash Beta.  It seems most AIR developers are on OSX, so maybe my Windows security configuration is protecting me -- or maybe it's just a bug with the Install Badge?  Personally, I'm glad this is failing.  However, since I've seen this "Install Now" badge on several sites, I have to assume it works on people's computers.  Every application on the Adobe page that I tried to install with the Install Badge, fails.

Summary

The AIR Install now badge is reminiscent of being prompted to install ActiveX controls.  Internet users don't feel good about doing this.  Though it's only in perception, there could (and will) be many malicious applications written in AIR that will do things like erase users images, send files to remote web servers, etc.  This is the price you pay for writing applications that run in the user space.  Let's just not confuse the users, nor tarnish the AIR reputation by using these INSTALL NOW badges for your legitimate applications.  Let's leave that circumnavigation to the nefarious webistes.  And Adobe, please offer us some form of native install user experience for our applications.

What's your take on it?

You can learn more about creating AIR install badges by reading AIR Install Badges, How to: Creating an AIR Express Install Badge, and Using SWFObject and the AIR install badge for easy deployment.

Worked late last night to solidify the functionality of FOTOBlendr, my entry into the Adobe AIR Derby.  It's an application for quickly building photo collages with community shared templates (in progress), as well as a free form tool using custom borders and slapping images on a Collage Canvas.

Currently, it supports the ability to grab images from Flickr, or your filesystem (there's thumbnail generation going on, so it'll take some time to import your local files, but they will be cached for next time).  Then the user can either throw all the images onto a Collage Canvas and then save it, or email it to their friends, or they can enter the Collage Builder mode where their taken to a screen that allows for custom layout.

Here's the 3 minute guided tour

The Main Screen

This is where you get started:

1. Import images from the file system (this takes time as a thumbnail is being rendered for each image in a directory, it's cached for future use, though).  Start with only a directory of 20 or so images, to see how it performs on your computer.
2. Adjust the size of the thumbnail (just like Adobe Lightroom).
3. Select the photos you want to build into a collage.  To select photos, press and hold the ctrl-key and select images.  Those selected will have a white border.  (Shift-selecting ranges of images works, too.)
4. After image selection, press either "I'm Lazy" for a jumbled mess of photos, or "Build Collage" to build your own custom collage.

The Custom Collage Building Screen with Templates

1. You come to this screen after pressing the "Build Collage" button on the main screen.  Here you can apply pre-build templates, or free-form layout your images.
2. Try selecting a template and watch your images fly onto the Collage Canvas.  Then try another template.  If you don't have enough images selected, you'll be warned when you try applying a template designed for more images
3. There's lots of good stuff coming with templates: Background images, B&W backgrounds, etc...it's going to be sexy.

The Custom Collage Screen with Custom Layout and Border Selection

1. If you don't like the templates, create your own.
2. Press "Clear Collage" button to get a blank canvas.
3. Drag your mouse around, the image will be dropped on the canvas when you click.
4. Change the borders, by pressing either the "Choose Border" button which will bring up a menu of borders, or select "Shadow Border", or "Sloppy Border".
5. Resize your images by pressing the "["  or "]" keys.
6. Rotate your images with "," and "."
7. Cycle through available border with "K" and "L"
8. Press "H" for help.  (See below for a screen shot of all the keyboard shortcuts.)

The Border Selector

1. By pressing the "Choose Border" button, or the keyboard shortcut "B", you'll be presented with a preview of borders.  Select the border you like. 
2. In the future, there will be the ability for community members to create border-packs to share.  And the application will be able to filter from the web.

The Help Screen

1. Pressing "H" or the "Help" button will bring up the keyboard shortcuts available.

Email or Save the Collage 

After you are done with your collage save it to your local disk, or email it of to a friend (the resulting file isn't very large).

Thanks for looking.

I'll figure out a way to post the .AIR file soon.

A little rant here.  I know Adobe AIR is new sexy and everyone's trying to build apps that run naively on the desktop, but please, if you're not making use of local filesystem, native windows, drag-and-drop, SQLLite, native menus, or any other of the useful AIR APIs, you should really consider not releasing it as an AIR application.  I'd prefer to use your application quickly via clicking a URL in my web browser.  I say this after having spent a few minutes uninstalling most of the AIR applications that have been cluttering my desktop that turned out to be remarkably useless, yet still required network connectivity.  There's no need to clutter the desktop with applications that run perfectly well in the browser!  Let's not forget about the great little thing called the World Wide Web, web applications, Web 2.0, AJAX, and regular-old Adobe Flash/Flex!

  This burgeoning Adobe AIR application market space reminds me quite a bit of the Visual Basic 3.0 days when all of a sudden tons of crappy shareware was developed in it.  Unlike those days, however, we already have a better way of running and trying out these applications, the web browser!  The user doesn't need to bother installing/uninstalling your application!

  Here's a technique that I'd love for all AIR/Flex developers to adhere to when creating their applications.  Make it run in both environments: the browser (via Flash), the desktop (via AIR).  Make the web-browser version limited in functionality -- if you desire -- showing the user the essence of your application.  Make the AIR full-blown sexy that a user might want to upgrade to or purchase (maybe the user wants to use their own personal files and data).  Prompt the user using your web-based version to upgrade to the full version at appropriate moments, like when they press the "Save" button.  This allows me to navigate to a URL, use your Flash/Flex application, and if it's worthy, download the full AIR version.  It even allows for a way to monetize your application.

  Now, I fully understand the desire to take your existing Flex apps and port them to the AIR Framework so you can test the installer and see how it behaves on your desktop.  After all, it's a great new tool, and you get that warm-and-fuzzy feeling thinking about all the new desktop applications that you can build.  But if there's something to learn from yesteryear, it's that there's going to be a lot of CRAPPY Air Applications released -- and I don't want to waste the time installing and uninstalling what are essentially demo applications.  Nor should we want to pollute the world with a ton of weak AIR applications so that when they are prompted in the future to install the Adobe AIR Runtime or and .AIR file, they're not going to want to install it because of all the negative association in their head.  (Any of you who've ever installed shareware made with tools like VB 4.0, etc. know what I mean with this.)  This is one reason why Web 2.0 applications are so great:  I navigate to a website, use the app, hate it, never go back.  Nothing further is required from me!  No installing/removing of software.

  Flash/Flex/AIR provides a very unique opportunity that allows people to try your software before purchasing via a web-browser, with nearly zero hassle.  I can't think of any other tools out there that encourage this. 

  I promise you, all my applications, you'll be trying out on the web first.  When it comes time to using your personal data, you'll download the desktop version!

  If you'd like some ideas on how to structure your Flex/AIR projects in Flex Builder so that you can build both web-based and AIR-based applications from the same Eclipse workspace, may I suggest reading my little tid-bit on How to compile both Flex and AIR Application from the same codebase.

Today, I decided it would be easier for me to demonstrate my AIR application to end users if they could just go to a link on a website.  However, getting AIR code to compile into a Flex SWF file, isn't as simple as I initially thought.  Naturally, there's the additional APIs that AIR allows the developer to use, like all the local file system interaction.  But, I figured I'd just use some form of pre-processor compilation tags, place them around the code I didn't want, compile,  call it a day, and drink a beer.  Wrong.

I searched around a bit and found a few conversations discussing how one should go about doing this.  David Coletta had some ideas posted over at his blog.  But I couldn't find any working code.  Since this took me several hours how to get it working, I thought I'd share my sample project files with you.  Mind you, I'm not totally happy with my solution and think it can be improved upon, but it's a start.

Download the code here.  (It's only for Flex Build 3, Moxie.)

The solution:  create thee projects.  One for your AIR application, one for your Flex application, and one to place most all the code, we'll call it CommonCode.  For these three projects, you create source path references to each other to include common code into their build paths.

The AirCode project includes a source path to the CommonCode project.

The WebCode project includes a source path to the CommonCode project.

The crux of the solution involves coding common code to Interfaces defined in the CommonCode project.  Both the Air and Flex Projects then Implement these interfaces into concrete classes specific to their projects.  For Air, the implementation might include functionality to save to local file system (File.browseForSave).  In Flex, you may prompt the user for an email address to send the file to. 

The other part of this solution is the shared UI.  The UI for both applications is defined in CommonCode::TestCanvas.mxml.  The AirCode and WebCode projects load this in their respective MXML files -- AirCode.mxml and WebCode.mxml -- upon starting.

At runtime when you need to save a file, you selective create the appropriate class depending on the runtime environment (Flex vs AIR), and then call the method on the Interface.   The following shows the basic implementation of the GeneralFactory class.

Misc thoughts :

1. Security.APPLICATION static string declarations exists only in the AIR framework.  Trying to reference that from a Flex project will result in a compilation error.  Use the string "application," instead.   Same goes for Capabilities.playerType DESKTOP, use the string "desktop" instead -- if using that method of determining whether you're running in the browser or in AIR.
2. The Flex compiler will not include any classes that aren't explicitly referenced in the code.  This must be an optimization.  Because of this, you need to include a declaration to all your classes that you want to have dynamically generated at runtime.  (Look at the static const called neededForCompilation in both the AirCode.mxml and WebCode.mxml -- this is essential for compilation.)
3. I don't like having the class names hard-coded as strings in the Common Code.   I could get around this by making some a Factory available on each the FlexProject and AirProject, but this seems to be a little too complicated.  For now, this is a livable solution
4. This is for compilation purposes only.   There's no dynamically loading modules at runtime. 
5. There is one negative side effect:  this slows compilation time considerably.  I now feel like I'm working in C++ back in the mid-90s.

I'm welcome to ideas on improving this implementation.  Also, does anyone have any code or CSS stylesheet for including ActionScript code in a blog without creating an image of it?  Thanks.