From the code depot you can download a compiled SWC or a ZIP file that contains all the source and ASDoc generated files. We have posted the ADoc files on-line so that you can easily access them if you do not download them. Currently, we have 219 unit tests running and passing for the library, which are all available from the source tree if you wish to access them.

The current release of Core contains the following functionality. We have marked new and updated features that have been changed from the Vivisecting Media Library to the new Core Library:

• Task Management System new! – The Task system is a priority queuing system that enables an application to execute specific bundles of business and/or server logic in a specific order leveraging priority and the ability to override previously queued bundles. These bundles are encapsulated inside of Task objects, which can be then bundled Task Group objects. Tasks and task groups have the ability to take priority over other Tasks or Task Groups inside of the queue, as well as replace existing tasks in the queue based on a set of overrides an individual task can define.
• Command Action Delegation System (CAD) new! – Provides a pre-built solution for implementing the Command Pattern within ActionScript/Flex/AIR applications. The command / action system allows for commands to be dispatched to the ActionDelegate which then executes any assigned functionality via an Action.
• Selection Management System updated! – The Selection Management system enables any kind of object to become selectable and treated as part of a Selection group. In most cases this would be a UI Component that should behave similarly to a radio button group, where only one item can be selected at one time. This system also allows for multi-select and deselection of items that are members of a selection group.
• Local Connection Management updated! – The Local Connection manager is a helper class to quickly establish and manage local connection instances within an application. The Local Connection manager also supports the ability to maintain strong class types when the data object is passed over the local connection instance.
• Event Broker Utility – The Event Broker is a utility class that acts as a router for specified events. The Event Broker is a single point of contact that any object can broadcast to or subscribe to. This functionality is intended to be the focal point for implementing the mediator pattern within the application.
• Instance Factory Utility new! – The Instance Factory allows for the ability to make sure there is only one instance of a specified class within the instance of the factory. This is useful for using in Locators that handle generating a new instance on the first request but then making sure the original instance of the requested item is returned on subsequent requests.
• Singleton Factory Utility new! – Similar to the Instance Factory, the Singleton Factory verifies that there is only one instance of a requested item, but instead of being limited to the instance of the factory, the Singleton Factory verifies there is only one instance of the requested item in the entire application.
• Adjustable Date Utility new! – The adjustable date wraps a Flash Date object and provides a series of helper methods to adjust time and dates quickly and easily. Example uses included the ability to adjust a date by a specific number of days forward or backwards, making sure that the number of days in the month and Leap Years are respected during the adjustment.
• Queue Data Structures updated! – The Queue system allows for items to be stored in either a LIFO or FIFO based queue order or in a priority queue order and then retrieved from the data structure depending on how the items are ordered.
• Hash Table Data Structure – The Hash Table is key/value that allows any value or object to be used as a reference key to another value or object item. The Hash Table is similar to Flex’s ArrayCollection in how items can be referenced but unlike the collection, this is ActionScript independent, is not intended for data pagination and is focused on performance for larger data sets.
• Browser Location Utility new! – Utility class used to query the current url in the application. The class provides static properties for each piece of the application url.

Adobe MAX 2008: The Future of Flex Builder (Part One)

In this post I will be delving deeper into the new/updated feature set that focuses on the aspect of the “Test & Tune” workflow. Test & tune is the day-to-day development workflow that we are all used to: Navigating our projects, creating new code, documenting, re-factoring, debugging and testing. A lot of these features may seem small but they provide a lot of power and can drastically improve development time and ease frustration that we experience during the development cycle.

Package Explorer

The first test & tune feature I want to examine is the new Package Explorer. Some of you may be thinking to yourself that Flex Builder already has a Package Explorer and wondering why this is a new feature. Well, to be exact, Flex Builder 3 does not have a true Package Explorer, what it has is the “Flex Navigator” which is really just a folder browser. When we use the Flex Navigator we often treat it like a package explorer since ActionScript packages are just folder hierarchies and this is what is represented within the Flex Navigator. The new Package Explorer merges the functionality of the Flex Code Outline panel and the Flex Navigator into one view.

Take a look at the screen cap, first you will notice that the MXML root file is now in a (default package) node within the explorer. From there you can then expand the MXML file data to look at the Classes contained and the properties of the class. Next, you can see that the default view makes the hierarchy a flat layout. For example, the package “com.developmentarc.test” is listed all in one line which means you don’t have to expand to view the structure to access a deep package like you would in the Flex Navigator. If you don’t like the flat layout you can change the settings of the Package Explorer to create the more traditional parent/child structure.

Finally, look at the Flex 4 SWC package in the screen cap. The Flex SDK version for the project is now shown in the Package Explorer. Not only is it shown but you can expand the SWCs to see the content structure, classes and properties contained within. In the screen cap I am exploring the Array in the playerglobal.swc file. This SWC exploration also works with 3rd party SWCs, not just the Flex 4 SDK. These all may seem like small changes, but it makes exploration, creation and modification of existing projects much easier. This also allows for Java Eclipse users to experience a much more familiar view when developing Flex Applications. Good stuff.

Event Auto-generation

During development, creating event bindings and method handlers such as the Mouse click event, is a common task. The event auto-generation is a short cut feature in Design View that allows a developer to quickly generate an event handler for a component. The example they used in the session was adding an event handler for a Button’s click event. From design view the developer would click on the generate handler button next to the on click event field:

When the user clicks this button, the handler function is generated in an <Script> block within the MXML file and the method is then assigned to the Button’s click property. My personal feelings about this feature is that it is helpful for initial development and/or learning of the Flex event handling model, but for complex development I am hesitant to see this as a go to feature. For one, the feature automatically adds the script to the current MXML file. On larger projects I typically avoid having scripts in MXML, this is especially true when following the code-behind pattern. I also feel this is going against the proposed workflow model that Adobe is pushing for Flash Catalyst and Flex Builder integration since your MXML is becoming more layout-centric with Classes for logic.

Overall, its a helpful feature and it makes prototyping, initial development and demoing a lot easier. We will see how this feature matures and how it is adopted by developers in the future.

ASDoc

ASDoc-ing is the process of adding specially formatted comments to your code that enables the ASDoc tool to generate documentation from the code and formatted comments. ASDoc is just like JavaDoc and has been evolving and maturing the the first release of Flex. One feature that has been part of Eclipse’s Java development suite is the ability to see inline contextual JavaDoc notes for specific Classes, properties and/or methods. The next version of Flex Builder supports the same kind of in-context doc hinting for code that has been properly ASDoc-ed.

When a user hovers over a method, property or class in either ActionScript or MXML the ASDoc tooltip will display showing the contextual docs for the specified attribute. In the screenshot above, I am hovering over the “left” attribute of an <FxButton> tag. Notice that the displayed doc notes are only for the “left” property. If I rolled over <FxButton portion of the tag you would see the ASDoc content for just FxButton. Not only can you view content inline, there is now a ASDoc panel that can be added to you workspace layout. This panel automatically updates when you click on a property, method, class, tag or attribute. This way you can have the view up and accessing ASDoc content without having to wait for the rollover event.

The ASDoc feature also works within your own code. For example, if you are developing a custom Class and provide properly formatted ASDocs in the Class, the ASDoc window/tooltip will show your ASDoc notes whenever you reference your Class in the application. The Flex team is also working on a new SWC format nicknamed “Fat SWC”. This Fat SWC will now include all ASDoc notes that are provided in the source code for the SWC compilation. This means that when you use a “Fat SWC” in your project, you will get ASDoc hints for any of the Classes, properties, methods, tags or tag attributes that are contained within the SWC.

New Re-factoring Features

There are two new re-factoring features that were demonstrated during the session, both of which help automate tasks that developers do on a weekly, if not daily basis. The first feature is the ability to auto-generate a getter/setter pair from an existing property.

To use this feature you first select, or apply cursor focus, the property that you want to convert to a getter/setter pair. You can then either right click > source > Generate Getter Setter… or you can choose the Source > Generate Getter Setter… menu option. This brings up the above options dialog where you can decide if the existing property should become private, what the new name of the property should become (it defaults to a single underscore prefix), the name of the exposed get / set method, should it create both the get and set method, or just one or the other and finally where the new methods should be added.

This is one of those at first glance small yet super powerful features. During development there are many times where you need to convert a basic public property to a get/set pair and this helps write the code quickly and elegantly. One other cool thing to note about this feature is its ability to remember your preferred prefix. As I mentioned earlier, the default is a single underscore prefix for the private method. I personally prefer a double underscore prefix for my get/set value properties and when I added that additional underscore Flex Builder remembered this and kept the double underscore when I used the re-factor function again. Very, very cool.

The second re-factoring feature, isn’t really new, its just a lot more complete. When re-factoring the code-base, one of the biggest challenges is the process of moving Classes around to new packages. This may occur for all kinds of different reasons: better project organization, company name changes, project changes, etc. etc. Eclipse (which Flex Builder is built upon) supports the move option, yet in the current release this would just move the resource to the new folder and not update the Class’ package structure and linkage throughout the workspace. If you used the rename function, Flex Builder would handle all the updating for you, so it always felt as if the functionality was half-complete.

Well, now move is finally fully supported. This is great news for those of us that have had to spend five minutes moving resources and then the next hour fixing the compiler errors. Typically the process was move the resource, build the project, look for errors, updating bad references, re-build the project, looking for bad references, rinse and repeat. This can get really ugly when you have 800+ classes (which I have had in the past) and you are doing a massive project re-structure. Not fun, let me tell ya. When you choose to move an asset you get to choose what package to move it to and Flex Builder handles updating all the linkage references and package declarations.

One thing to note, in the current preview build of Flex Builder the package has to exist before you move the resource to it. If I recall, David Zuckerman mentioned that this will change in the future. Even if it doesn’t this is a great feature, one that I want NOW. It would have been soooo nice yesterday when I had to move a ton of MXML classes around and re-link them throughout the project, oh well.

Code Templates

Code templates are more or less self exactly what they sound like. A code template is similar to an email signature in that it provides the ability to auto-fill predefined content when a new MXML, ActionScript or CSS file is created. In a way, we have already been using Code Templates when we generate a new ActionScript class. The provided package structure, class declaration and constructor are all generated by the Code Template engine. The difference is that in the next version of Flex Builder this will all be exposed to you and fully modifiable.

Are you working on a MIT or other licensed project? You can now add the license block to the template code and any new file will have the proper structure. You can predefine code blocks, ASDoc blocks, code layout and preferred structures all within the code templates. You can also use variables that set time, file path, names, etc. into the template. On top of that you can export your created templates, pass them around and have others import the template into their Flex Builder. This is great if you work with multiple developers and want to create better coding standards or if you want to create company or open source project specific structures. Again, a simple yet very powerful feature that is being exposed to us.

Code Navigation

The last Test & Tune feature I am going to talk about in this post is code navigation. Code navigation shows a developer in code view what methods are overrides and implementations of interfaces. It also allows for quick navigation up to the parent reference when the triangle icon is clicked.

This is a nice feature because in the past you had to look at the Interface itself to determine what methods are implemented in the current class related. Overriding was generally easy to see at a glance because of the override keyword but getting to the parent method instance was not so easy. This feature enables both code readability and better navigation within the application.

Well, that is all for now. I have three more topics to write about, two more test & tune and then a look at the new Data service support. I will save those for the final post.

• Design Fidelity / UI Creation
• Data / Service Management

Design Fidelity / UI creation is focused around a Flex developer that is responsible for bringing in the initial design for that application and making it a reality. This process includes layout, skinning, styling, animation and effects creation with the core goal of meeting the required design fidelity for the final product. The second entry point is for the developer that is responsible for the Data / Services management aspect of the application. This process includes creating data services, data model creation and loading management. To be clear, these two separate approaches do not mean they are handled by different developers, this is just a way at looking at how developers approach their Flex development duties.

Because there are the two main entry points for most developers, the Flex Builder team is first working on new and improved features that focus on these two areas. There is also a general initiative to work on improving general day-to-day use in Flex Builder, re-factoring management and debugging of Flex applications (they called this process “Test & Tune”). This general initiative covers both the design and the data aspect of application development.

I am going to be breaking this article into three separate posts. This first post will cover the workflow and new features added to Flex Builder for the Design Fidelity aspect of development. Post two will cover the overall day-to-day use features that are being updated/added and how the Flex Builder team is improving the “Test & Tune” workflow. The third post will look at the data services features that are being added to the Flex Builder 4 (Gumbo). One thing to note is that this session was a mini sneak-peek of Flex Builder, and there is a chance (albeit very small) that some of the features discussed in the post may not see the light of day (or change drastically). Also, all the screen caps in the posts are from the MAX Preview release, so there is always a chance that the UI and functionality shown will change. Okay, let’s get to it!

Design Fidelity Features

Theme Management The first new feature they examined is Flex Theme management and installation. Themes are not a new concept, they have been around since at least Flex 2 (I can’t recall if Flex 1/1.5 supported them, I think they did). A Theme contains style and skins assets for every Flex SDK component and is applied to your application during the compile process. The idea behind a theme is that you can apply a unified style across your application without having to go in and skin each component yourself. If you are familiar with WordPress, its the same concept as their themes; all the functionality stays the same but the look and feel can be drastically different.

The Theme market for Flex appears to be growing, but adding a theme to an app requires making compiler argument changes to make sure the theme’s assets are loaded and compiled into the generated SWF or AIR application. This means that the Flex Builder developer has to configure the project properties in the tool to make sure the Theme is applied. I have personally not used Themes in my applications due to the fact that all of the projects I have worked on have design teams and/or unique design requirements, but I have played around with themes in the past.

The Flex Builder team has seen the growing popularity of Themes and they want to make Theme installation a much easier process. Themes are packaged as SWC files that contain all the CSS and style assets. When a user downloads the SWC file to their machine they can then choose to install the theme into Flex Builder. To install a Theme, the user chooses the Import Theme… option which allows the user to point to the Theme file. The theme is then imported into Flex Builder and it can be selected from the new Theme management dialog.

You can access the theme management dialog by clicking on the “Manage Themes” link above the UI component panel in Design View. This dialog shows all the currently installed themes and a thumbnail of what the theme looks like. You then select what theme you want to apply and this updates the complier options for you and rebuilds Design view using the new theme. It also sounds like they are working on streamlining theme creation and how they are distributed to make theme use easier and more popular.

Catalyst and FXP Support

The next Design Fidelity workflow feature is the ability to handle importing and exporting of Flash Catalyst project files. Flash Catalyst is a new design/development tool by Adobe that is centered around creating and styling Flex applications. One of the most challenging processes of Flex development is applying complex custom UIs into your final application. The goal of Catalyst is to allow a designer or developer to import assorted creative asset formats, such as Photoshop files, Illustrator files and Fireworks files and then quickly build Flex UIs using the creative assets’ contents (layers, symbols, etc.). Once the layout / styling is done the Catalyst user can save their Catalyst built application as an FXP file and pass this on to a Flex developer to wire it up to data services and functionality. The FXP file created by Catalyst is a zipped version of a Flex Builder project which means that a Catalyst user can share their work with a Flex Builder developer or visa versa. This gets us into the new FXP feature and workflow being added to Flex Builder 4.

Flex Builder 4 has the ability to import an FXP file and then create a project within Flex Builder from the FXP file. This imported project has all the structure and content that was created inside Catalyst. From there the Flex Builder user can begin adding functionality to the Catalyst generated project, such as data binding and data service management. As the project moves along there will come a time where the UI will need to be modified. At this point the Flex Builder user can export the Flex Project back into the FXP file format and pass this to the Catalyst user. The Catalyst user can then open the FXP file, make the UI additions and then hand the FXP back to the Flex Builder user.

At this point, when the Flex Builder user imports the updated FXP it recognizes that the project already exists and provides the option to allow the user to merge the Catalyst changes into the existing project. When the user selects merge, the project conflicts are then highlighted in red within the project view and the user can then right click on the conflicted files to show a merge tool view that enables the user to determine what changes to bring into the project. This current workflow is in its very early stages and I assume that it will be both improved and changed as development/testing/feedback is provided.

The focus of the FXP support within Flex Builder is to help create a better streamlined workflow between the design and development aspect of Flex. My example above assumes that your Catalyst and Flex Builder user are different people, but this workflow can be used by a single person going between Flex Builder and Flash Catalyst. As both of these products move forward in development I expect to see a lot of discussions around integration, workflow and best practices for planning and structuring your Flex projects.

That’s all for now… The next post for this article will cover the new Test and Tune features that are being added to Flex Builder.

I read a great analysis article by Grant Skinner, talking about the different Open Source licenses and how they can affect you and your client. I originally licensed the code library under the Mozilla Public License (MPL) due to its popularity, its freedom to allow developers to build on top of the code base for any purpose (free or for charge) and only requires code modification submission if the developer changed the original code in the library. My goal with VivMedia is to help developers build great applications, and the last thing I wanted to do is limit them, yet I do want to encourage people to submit changes and updates. That is why I went with MPL at first.

The issue with MPL (as Grant points out) is that when you use MPL code there are certain steps you need to take to release your project. In most cases this is not a big deal and it very rarely impacts the project but it may cause some developers or their clients a bit of grief. In all honesty, I just want to create a library that myself and others can use without having to jump through hoops with our clients. This lead me to change all the code license to MIT, which is very permissive of all forms of development. All you need to do is keep the MIT license headers in the source. You don’t have to submit changes (all thought I would be very happy if you did) and you don’t have to jump through any other legal hoops when deploying. So, if you are using the library already, update to the new version and know that the door is now wide open and you don’t have to fret about how you or your clients release the work.

The other addition to this version is the new Queue data structure. The Queue allows you to add and remove items is in a linear fashion. You can define the Queue as either Last in First Out (LIFO) or First in First Out (FIFO). What that means is when you add() item A and item B to the Queue and then call next(), the item returned is dependent if the queue is set to LIFO or FIFO. A LIFO Queue returns item B, since it was the last item added. A FIFO Queue returns item A since it was the first item added. As always, a full tutorial will be posted soon on how to use the Queue in your code.

The Queue is a building block for a lot of new functionality that I am starting to plan out. There will probably be variations of the Queue going forward too. For example a version that is designed to help solve Asynchronous issues in a Synchronous fashion, without you having to write a lot of logic around the actions. Right now, its all about what time permits… and as I said in the last post, vacation is nearly here! So, update/download the library, check out the ASDocs in the source (I always update them for each release) and let me know what you all think.

New And Improved UI

So, what’s new? Well the first thing up is the updated application UI. The goal for the updated ui was to continue showing off the skin-ability of AIR applications and also help streamline user interactions. kuler continues to leverage the transparency effects of AIR and now has a beautiful cutout UI that highlights the kuler logo and application buttons.

Some of the other UI additions are unification of the kuler web application loading animation with the loading animation within kuler Desktop and making the Sign In / Active Internet connection light more prominent at the bottom of the tool.

Another important change is the addition of the grip bar and hand icon over the Themes. One of the coolest features in kuler Desktop is the ability for a user to grab a Theme and tear it off into its own window. This is one of the “wow” features because every time someone sees it for the first time they instantly go “WOW!”, me being one of them. This functionality is actually not a new feature, it was in the original release of kuler Desktop. Unfortunately it was not as easily discoverable as was hoped and this new UI update is intended to help people discover it quickly.

New Menu Access

The drop-down menu now has two new options for users. The first is the About menu. In the previous release the general about details were located in different locations within the info panel and this information is now consolidated into a single location. The other new menu option is shown when a user signs into their kuler account using an Adobe ID. The previous version of kuler Desktop allowed users to view the Themes they created in the kuler web application but they could not view any of the Themes that were marked as favorites. Now user can view any Themes that they have marked as a favorite on the site once they have signed into My kuler.

Paging and Caching of Themes

With kuler Desktop users can now view all the Themes in all the categories. One of the limitations of the original release was that they could only see the first 100 Themes in a category. No longer! The UI has a new feature that allows users to page through the themes a 100 at a time, or they can jump to the first or last 100 with a press of a button. kuler now also show users their current position in the Theme category so that they know exactly where they are.

In addition to exposing this feature in the UI kuler now has added the ability to cache Theme pages so that when someone navigate back and forth through Themes they only have to load a new page when they exceeded the current cache limit. This makes extended browsing much quicker for everyone.

Creative Suite Integration (CS) via SwitchBoard

The killer feature in this release is the ability for kuler Desktop to export Themes directly into Adobe Photoshop, Adobe Illustrator and Adobe InDesign with a single click. Not only can kuler Desktop directly import a Theme with a click kuler Desktop can also launch the CS application if it is not already running.

kuler can do this thanks to an awesome new application called SwitchBoard. SwitchBoard, which is now on Adobe Labs, allows AIR applications to communicate with CS applications via an ActionScript API. Using the API developers can send ExtendScript commands directly to the CS application of their choice. Thanks to the power of SwitchBoard users are now able to save the Theme ASE (Adobe Swatch Exchange) file to the appropriate CS folder location, call the CS application, tell the application where the ASE now lives and to have it open the ASE in the Swatch palette.

Auto-updating / General Fixes

On top of all that kuler now has a built in an auto-update utility leveraging AIRs update support that allows kuler to determine you when a new version is available. Adobe kuler Desktop can now call out and see if a new version is provided and if it is the application will download and auto-install the update for you. The new version also a lot of fixes for usability issues and bugs that both the QE and the kuler community have found. Overall, this is a great dot-release and I feel you all are going to love the new features!!

One of the challenges of writing an article like this is first defining your audience and then determining how to cover the topic in the alloted text. The Edge sets a word count guideline and this limits how deep I could or in this case could not go. Personally, I fully support the word count guide because this both focuses the topic and generates more digestible articles. Yet, on a topic as broad and as deep as this one I had to focus more on an introductory guide to coding standards and adoption.

The second challenge is determining your audience. My goal was to create an article that worked for both readers who have never heard of coding standards, and readers that have been using them for years. I always try to create a broad stripe across my reader base because I want to inform as many people as possible. This thought process was kind of beaten into me during my years as a Technical Support rep and team-lead at Macromedia. There is nothing like having to write Tech-notes and email support to teach you how to write to a broad audience.

The main point I wanted to get across with this article is that coding standards are actually much more then just code formating. Code formatting, or code conventions, really focus on how you name variables, methods, classes, etc. Yet, this is just the tip of the coding standards iceberg. One of the least discussed aspects of coding standards is the adoption and implementation practice of code design patterns. As developers, we need to better understand how adoption of patterns, frameworks and micro-architectures help structure our code. Not only do they provided rapid development but they also help guide us into a more structured development process.

As RIA and web application development expands we are seeing a demand for much more complex and scalable applications. Scalability is not just about user load but includes further expansion of features and performance over time. More and more developers are being asked to create applications that have a lifespan longer then just a few months. Some people may gaffe at that comment, but if you look at a lot of “rich” applications up to this point, most have been for marketing campaigns and advertising. The nature of these kinds of projects do not focus on lifespan and version updates. Their focus is on making them work in a short time to meet the marketing deadline and then get them out the door.

With the trend of Web 2.0 (which I hate as a term), the web world is quickly being pushed into the long standing Desktop Software model. This is forcing a lot of us to re-evaluate how we design and develop our online enabled applications. This is a scary yet wonderful time in our industry as we are rapidly adopting and developing new ways of web application design and construction. Due to this push I feel its time to help expose more of us to coding standards. My article is more a call to arms then a definitive guide to coding standards implementation. If you are interested, take a read and add your thoughts to the comments…

Today’s big news in the tech industry was Amazon.com’s US outage. If you haven’t heard about it Amazon.com US, went down at 10:27am PST on June 6th:

An Amazon spokesperson said this afternoon, “Amazon’s systems are very complex and on rare occasions, despite our best efforts they may experience problems. We work to minimize any disruption and to get the site back as quickly as possible.”
— Amazon’s Web Site Goes Down: An ‘Unplanned Event’ on New York Times Bits by Brad Stone

But what is the real cause of this? Some sys admin friends of mine where trying to shop at Amazon when it went down. Being what they are they took a peek under the hood and it looks like the DNS was hacked. When a whois was run on Amazon.com this is what was returned at 11:20am PST:

$ whois amazon.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information.

Server Name: AMAZON.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM
IP Address: 69.41.185.219
Registrar: INNERWISE, INC. D/B/A ITSYOURDOMAIN.COM
Whois Server: whois.itsyourdomain.com
Referral URL: http://www.itsyourdomain.com

Server Name: AMAZON.COM.MORE.INFO.AT.WWW.BEYONDWHOIS.COM
IP Address: 203.36.226.2
Registrar: TUCOWS INC.
Whois Server: whois.tucows.com
Referral URL: http://domainhelp.opensrs.net

Server Name: AMAZON.COM.IS.N0T.AS.1337.AS.WWW.GULLI.COM
IP Address: 80.190.192.24
Registrar: EPAG DOMAINSERVICES GMBH
Whois Server: whois.enterprice.net
Referral URL: http://www.enterprice.net

Domain Name: AMAZON.COM
Registrar: NETWORK SOLUTIONS, LLC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com
Name Server: UDNS1.ULTRADNS.NET
Name Server: UDNS2.ULTRADNS.NET
Status: clientDeleteProhibited
Status: clientTransferProhibited
Status: clientUpdateProhibited
Updated Date: 28-mar-2008
Creation Date: 01-nov-1994
Expiration Date: 31-oct-2017

Last update of whois database: Fri, 06 Jun 2008 14:15:03 EDT

This just reeks of the same thing that happened to Comcast. If you read the full article at Wired, the hack sounds exactly the same. It will be interesting to see what Amazon has to say once the dust settles…

History Of The Code-Behind Pattern
This pattern was first applied in Flex 1 and 1.5 through a “feature” in the Flex compiler where two same named files would be merged into a single class. To leverage this the developer would create an MXML file that defines the layout and then an ActionScript logic class, which would have the same name as the MXML file, was used to handle all of the logic. At compile time the Flex compiler would take the MXML and the ActionScript and then merge them together using a process called mixins.

The original version of Flex was built in AS2 which enabled mixins during the compile process. A mixin is the ability to dynamically merge multiple classes into a single class without requiring inheritance. Its similar to implementing an interface but instead of having to code the methods to conform to the interface, mixins directly add the functionality in. Its a strange hybrid of inheritance, implementation and composition that is used in prototype based languages like JavaScript.

With the advent of ActionScript 3, mixins went away because the language moved from a prototype based structure to a stricter inheritance model. When this happened the “feature” that handled the MXML to Class code merge was “fixed” and stopped the initial form of code-behind. Once this “fix” was found by the development community there was a lot of concern about how the Flex team removed a powerful feature. This was an understandable concern yet the ability to handle mixins was no longer a feature of the language. The reason this no longer worked is that the compiler saw the MXML file and the backing class as a namespace conflict. From the compilers point of view you now had two different classes yet they where identically named, which is not allowed.

What Goes On Behind The Scenes
Whenever I give trainings on Flex to new developers one of the first things I talk about is the differences between MXML and ActionScript. When you first learn Flex there is often confusion between what MXML is and how it relates to ActionScript. We tend to think of it as different entities, but the reality is MXML is just an abstracted form of ActionScript. MXML is a declarative XML syntax that is converted by the compiler into an ActionScript class. This is an important concept to understand because this is the root of why the compiler throws an error when trying to have a MXML file and an ActionScript File with the same name in the same package. The MXML file is really just an ActionScript class and therefore we have a conflicting namespace error.

To help visualize this, imagine the root node of the MXML file is the same as an extends statement. When we use something like this in MyApp.mxml:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
	...
</mx:Application>

We are really saying:

public class MyApp extends Application

So why do we need MXML syntax if it just becomes ActionScript. As you are probably well aware, doing complex layout in ActionScript takes a ton of code, especially when you get into the world of nested layout. It can be done in code but why would you want to? XML is all about parent/child hierarchies and by using this as a layout language you can quickly define complex organizational structures that would have taken hundreds of lines of code if you did it all in ActionScript. Now that we have a better understanding of the MXML/ActionScript relationship we can start talking about how the pattern is implemented.

The Pattern Structure
When looking at Adobe’s MXML examples we often see them using the <mx:Script> tag to define any ActionScript that is required to make the MXML example work. This approach is fine for simple examples but once we begin development of a larger application using Flex, having all the MXML logic in a single <mx:Script> tag becomes unwieldy. Even if the code is written by the most organized developer, once you hit 300+ lines of ActionScript with 100 lines of MXML it becomes hard to see the forest from the trees.

One way to solve this is to use the source attribute in the <mx:Script> tag and set it to an external AS file. This helps because you now have separated all your ActionScript out of the MXML but now you have externalized AS files that aren’t really classes, that sit in the file structure and you can’t extend from them.

The Code-Behind pattern is a solution to this issue. The first step is to create an ActionScript class that extends the base type that you want your MXML file to be. For example, a Canvas:

package com.vivisectingmedia.demo
{
	import mx.containers.Canvas;
 
	public class MyComponentLogic extends Canvas
	{
 
	}
}

I have now created a Class in the com.vivisectingmedia.demo package that extends from Canvas. This is my backing logic class that my MXML extends from. Note that I have used the postfix “Logic” to create a unique name. If you recall, our MXML and AS have to be different names. I prefer the “Logic” postfix but you can use “Base” or “Backing” or any other postfix/prefix you like. Now, you can create the MXML file. In this example let’s assume the MXML component is in the same package as the ActionScript:

<MyComponentLogic
 	xmlns="com.vivisectingmedia.demo.*"
	xmlns:mx="http://www.adobe.com/2006/mxml">
	...
</MyComponentLogic>

This code would be in an MXML file called MyComponent.mxml. The MXML now extends from the ActionScript and we can begin to start laying out content and adding logic as needed.

Naming Conventions And Things To Consider
If you follow this patten there are a few gotchas you need to be aware of. These issues may feel a little limiting at first, but after using this on many projects it has become second nature for me and I have yet to be blocked or discouraged by any of the potential challenges. Here is some example code that I will be relating to for the following points:

package com.vivisectingmedia.demo
{
	import flash.events.MouseEvent;
 
	import mx.containers.Canvas;
	import mx.controls.Button;
 
	public class MyComponentLogic extends Canvas
	{
		[Bindable] public var my_button:Button
 
		// Constructor
		public function MyComponentLogic()
		{
			super();
		}
 
		override public function childrenCreated():void
		{
			super.childrenCreated()
			my_button.label = "do something..."
		}
 
		public function handleMouseEvent(event:MouseEvent):void
		{
			// do something
		}
 
	}
}

<MyComponentLogic
 	xmlns="com.vivisectingmedia.demo.*"
	xmlns:mx="http://www.adobe.com/2006/mxml">
 
	<mx:Button id="my_button" click="handleMouseEvent(event)">
 
</MyComponentLogic>

Remember that the MXML inherits from the base logic class. What this means is that as you add children components to the MXML and you want the ActionScript Logic to manipulate them you have to make sure the ActionScript has them declared. To declare them you have to define properties in the ActionScript class whose name matches the component id you use in the MXML. For example, look at the Button id in the MXML above and notice that I have a public property in the ActionScript with the same name. The property must be public in the ActionScript class and you should mark them as [Bindable] so that if you have other components binding to them the change watcher system still operates as expected.

This works because the MXML file is an extension of the base logic class and the components with the matching id is equivalent to overriding the properties in the ActionScript. You may wonder why the properties have to be public and not protected if this is an override. The issue is that the MXML components are not part of the MXML class, they are children of the MXML class. Since they are children they do not have access to the ActionScript class’ protected methods and the compiler will see their id as a duplicate name for the MXML class, which is invalid. If the method is public, the compiler interprets this MXML component id as an override and it works. So, long story short… always make the properties [Bindable] public.

Never try to manipulate the children components from the ActionScript constructor. This is a common mistake made by developers using this pattern. For example, you try to set the button label in the constructor. If you tried this you would get a null value error for the button since it has not been created yet. MXML creates the children components in the createChildren() phase so the best way to work around this is to override childrenCreated() method that is executed once all the children in the entire inheritance stack has been created. In this method you first call super.childrenCreated() and then you can start accessing children components.

Never try to removeChildren() that are defined in MXML. This is a mistake that sometimes works when you try it but in most cases this just causes a lot of heartache. Usually the heartache occurs after you have been doing this for a while and you then have to go back and fix a lot of code that was dependent on the first removeChild(). Unfortunately I have seen this first hand and its not a pretty sight. If you are doing a lot of children manipulation then you will want to move away from MXML declaration and handle the children creation/removal all in ActionScript.

Name your components using a different convention. This is not a requirement but it will help out in the long run. On my projects we use all lower case with underscores between the words (ex: my_button) to identify a component in the MXML. Camel case (ex: myVarName) is used for public and protected properties. I am an old school Flash developer so I use a single underscore (ex: _privateVar) for private variables and double underscores (ex: __myGetterSetter) for private properties that are exposed via a getter/setter. By using this kind of naming convention it makes reading your code easier to determine what is being manipulated and when.

Try to avoid mixing and matching MXML and ActionScript event/action binding. This is also more of a recommendation then a requirement. If you start binding the creationComplete or click events in MXML try to bind them all in MXML. If you bind your events in ActionScript try to bind all of them in ActionScript. In my above example I bind the click event via MXML. You can easily do this in ActionScript within the initilize() method using addEventListener(). Once you start mixing and matching it can be hard to track down code flow later on. You may find yourself wondering why an event keeps triggering yet it appears to not be referenced any where in your ActionScript. The problem ends up being that you used event declaration for that one type in MXML and forgot about it. Use what works best for you.

Code Behind allows for continued extending One issue with MXML is that you can only extend MXML from MXML. Once you have moved code/logic over to MXML and then you want to extend from it, you can not use an ActionScript class to extend from the MXML. I have seen some pretty ugly hacks, or even worse; mass duplication of code, because developers are attempting to extend or replicate most but not all of the functionality from an existing component. By moving logic into a backing ActionScript class, this means that only layout is defined in the MXML, from there you can extend from the base ActionScript class, add new functionality, and then add your layout. This is one benefit that I feel a lot of developers miss. For applications that mature and/or grow having a more robust pattern like Code Behind, can enable easier maintenance and additions without having to get into some crazy hacks of removing/hiding children from extended MXML files, or just copy and pasting an existing file and then making the required modifications.

In Conclusion
The Code-Behind Pattern is a relatively simple pattern that can provide a clean code structure which makes your code base a lot easier to manage over time. I have to admit that I was pretty hesitant when I was first required to use this pattern on a large project. It seemed like a lot of extra work but once we started getting into extremely complex components and layout this functionality was extremely powerful. Not only was the code cleaner but if you focus on abstracting your Logic base classes you can easily extend and swap out the interface. Its a lot easier to extend from a core AS class then trying to extend from the MXML and having to modify the layout. Try it out on your projects and please post your comments about your success or challenges using this in development.

revisions:

• April 29th, 2008: fixed a few grammatical errors and added clarifications to the “gotchas” section to help explain why the recommended solutions work.

• April 4th, 2009: fixed more grammatical issues and added a section about extending classes/mxml

• October 9th, 2009: fixed typo in package name and updated references to initialize() to replace them with createChildren(). For more information why, read the DevelopmentArc white-paper on The Flex Component Lifecycle that I helped write.

Doug is very strong writer and speaker and is outspoken on the concepts of development workflows, from the creative to the programatic.  I am looking forward to reading his posts and seeing both what he and Adobe envision as the current view of workflow and how they propose to evolve it over the coming years.

Color extraction allows you to upload an image and which is processed to create a color theme.  You can then change how the image is processed by selecting different moods, such as Bright or Muted.  Not only can the system pick the color but the UI then allows you to manually select the locations of the color samples used to create the theme.  Once you create your theme you can then save it in your themes and make it public for others to use and rate.

Other new features include the ability to store an unlimited amount of favorites.  As you go through all the themes you can pick out your favorites and store them to your account.  You do need to log in with you Adobe ID to access this feature.  There has been multiple UI tweaks and also a new drop down for random themes, highest rated, newest and most popular (based on the downloads of the ASE version).  When you download a theme it comes in the ASE format (Adobe Swatch Exchange) that can then be imported into Photoshop, Illustrator, InDesign, Flash and Dreamweaver.

Kudos to the Kuler team and their newest launch!!