Sunday, April 29, 2012

Flex GroupStack (ViewStack) Component

Update: I've released a more direct port of the ViewStack and will be deprecating this component.

One of the components missing from the Spark component set is the ViewStack. Generally, I have not missed this component when creating Flex 4 applications because I tend to favor using skin states where I would have normally used a ViewStack in Flex 3 applications. That, and if I really need a ViewStack, I don't mind using MX controls in my Flex 4 applications.

When I do want a ViewStack, it's usually because its children need to be dynamic. In other words, either I need to add/remove children at run-time, or I'm developing a reusable component and each instance of the component may need a different set of children. Although this can still be achieved with skin states, it's a bit difficult and cumbersome to set up skin states and their configuration at run-time, and a ViewStack would solve the problem in a much more elegant way. However, I've often found that when wanting to use the ViewStack, it's usually to replace a "contentGroup" skin part within the skin class for a Spark component. A ViewStack, not being based on Group (like contentGroup containers usually are), ends up breaking the skin part contract between a Spark component's host component and skin classes.

With that being said, some of the components I'm creating for the ShinyLib library need ViewStack-like functionality. When I originally created the ShinyLib library, I made the decision to keep it as a Spark-only library, meaning that I don't even have access to MX controls, such as the ViewStack. For that reason, I created a quick and temporary solution: the GroupStack, which is a Spark Group extended with ViewStack-like functionality.

Like I said, it was quick and temporary solution, mainly to avoid putting off the creation of some components I've envisioned while waiting for an official Spark ViewStack. That means that it does not have all the features of the MX ViewStack (such as creation policy and deferred creation) and it's not heavily tested. When we do get an official sparkified ViewStack in an upcoming release of the Apache Flex framework, I'll update my ShinyLib components to use that instead, and remove (or possibly deprecate) my GroupStack.

The GroupStack implements the ISelectable and IList interfaces including a selectedChild property to give you most of the same API as the ViewStack. Unlike the ViewStack, the children of the GroupStack only need to be instaces of IVisualComponent instead of INavigatorContent. This means that the children can be simple controls such as Buttons and CheckBoxes and do not need to be wrapped in NavigatorContent containers. However, if you wanted to set the GroupStack as the dataProvider to a ButtonBar or TabBar, it's still best to wrap the children in NavigatorContent containers in order to properly render labels and icons.

The first example, below, shows a GroupStack with a Button, TextInput, and VGroup as direct children, and a NumericStepper to control the selectedIndex. The second example is the same except each of the children are wrapped in a NavigatorContent container in order to be set as the dataProvider of a ButtonBar.

Either scripts and active content are not permitted to run or Adobe Flash Player version 11.1.0 or greater is not installed.

Get Adobe Flash Player

Source code located at:

Friday, April 20, 2012

Using manifest.xml Files in Flex Library Projects

Have you ever wondered why the spark, mx, and fx libs in your MXML files get pretty url-like namespaces while your own library projects are given package-like namespaces? Using a manifest.xml file you can choose a custom namespace of your own. Plus, there's benefits for doing so.

First, why would you want to (other than the professional aesthetics of your awesome library)? I see two main problems with the default package-like namespaces.

  1. Since the namespace is tied to a specific package structure, any time you modify the package structure of the library or move components around in it, you have to go through and update all your namespaces.
  2. If you use more than one component from your library in the same MXML file, in which those components exist in different packages in your library, you end up with multiple namespaces -- one for each package from which the components came from.
A custom namespace has no ties to a package structure in your library allowing to re-arrange things as often as you'd like and separate them into as many packages as you want, all with a single namespace that never needs updated. Any of these changes to your library simply requires updates to the manifest file.

Although the manifest file can be named whatever you want, it's customary to name it "manifest.xml". You can place it anywhere you want. I suggest keeping it somewhere in the project but above the source directory (such as in the root of the project).

The content of the manifest consists of XML nodes for each component you want to expose in the namesspace. For example, the source of the manifest for the ShinyLib library looks like this:

<?xml version="1.0"?>
    <!-- components -->
    <component id="CollapsiblePanel" class="com.shinynet.shinylib.components.CollapsiblePanel"/>
    <component id="FieldSet" class="com.shinynet.shinylib.components.FieldSet"/>
    <component id="FormattedTextInput" class="com.shinynet.shinylib.components.FormattedTextInput"/>

To apply the manifest to your library and give it a custom namespace, from FlashBuilder, go to the library's properties and to the compiler options. Towards the bottom you'll see a space for specifying a custom namespace and browsing to your manifest file. The namespace you choose can be anything you want, but it should be something unique as well as providing some insight to what the namespace points to. In the case of the ShinyLib library, I'm using library://

That's really all there is to it. However, you may notice a couple less-than-ideal situations. First, the benefits I mentioned above (being able to reorganize your library with no changes to the MXML files using the library) is only valid for... you guessed it, when defining your components using MXML syntax. When you instantiate the components in actionscript it still requires a package-specific import which would require updating anytime your library's package structure is changed.

Also, you have no control over the namespace identifier that FlashBuilder automatically generates for you. It's usually "ns1", such as xmlns:ns1="library://... and then "ns2" followed by "ns3" and so on. I tend to update the identifier to whatever I want after the first time FlashBuilder adds it for me, and then each additional use of a component from the library in that same MXML file will use the same identifier/namespace combination.

As Tink mentioned in the comments, you can control the namespace prefix that gets automatically added to your MXML file by utilizing a design.xml file. You can look at the design.xml file in the ShinyLib library to see an example of how to create it. The design.xml needs to be placed in your library's source root and you need to make sure it's compiled into your library.

Overall, it's a handy mechanism to utilize.

Thursday, April 19, 2012

Why I can’t grok RobotLegs

Warning:  I try to stay away from rants and philosophical posts on my blog, especially long ones. I’m violating all of these practices here.

I remember taking looking at RobotLegs two or so years ago. I also remember being a bit puzzled by it. I was a Parsley user at the time (and still am) because I had that “instant gratification” of how it could help me build larger and more complex applications more easily. I never got that feeling with RobotLegs… at least not instantly. Maybe I didn’t give it enough time.

What must a framework do to provide that feeling of instant gratification? It simply needs to solve a common problem I run into during development, or, at the least, make a common development strategy easier. That’s what design patterns are for, right? And that’s really what a framework does – enables you to employ design patterns to solve common problems. And that’s where RobotLegs was failing me. It’s not that I was failing to understand it, or what it was trying to do and achieve, it’s just that it was trying to solve problems I was not having.

It was never the dependency injection or event bus that bothered me… those aspects are great. It’s just that you can get that functionality from anywhere. The bothersome aspect was what RobotLegs referred to as the mediators. I have no issue with the mediator pattern. In fact, I think the pattern is great. I use mediators all the time, everywhere during Flex development. And I bet you do too whether you realize it or not. My issue was that what I was seeing from RobotLegs was not the mediator design pattern.

I’m no expert with design patterns and never have been.  But I have done enough research, experimentation, and real world usage to recognize, implement, and understand the benefits of the more popular ones out there. When it comes to mediators, I’m referring to what is represented by the Gang of Four. A mediator is simply a class that mediates the communication between two or more “colleagues” (components, views, etc.) in order to keep those colleagues decoupled and knowing nothing of each other. That’s not a quote, rather, just my understanding of them.

Have you ever implemented a container that has two or more child components in which the container facilitates the communication between those children? Of course you have. You probably do it all the time. The container is acting as the mediator to its children. Even the spark component architecture implements a mediator pattern in which the host component mediates the skin parts.
The recommended usage of mediators in RobotLegs is something…. different. I’m not quite sure what pattern it’s following, which is why I’m not sure what problem it’s trying to solve. From every example and real-world application I’ve seen running on RobotLegs, each “mediator” has a reference to a view, but just a single view. That would seem to mean that it’s mediating the communication between that view, and… I don’t know… the rest of the application, maybe? Shouldn’t that be the role of events or a messaging framework? The mediator needs a reference to two or more views to facilitate some mediation, in order to operate the way I understand the pattern and to solve the problem it’s meant to solve.

This one-view-to-mediator structure reminds me a lot more of presentation models. However, when you Google the proper usage of mediators in RobotLegs, you’ll find overwhelming opinions that they should not hold state. I would agree with that in the case of true mediators, but that would also disqualify them from acting as presentation models.

This brings me back full circle to the question of “How am I supposed to be using these mediators and how do they benefit my development?” Again, I completely understand how the documentation is suggesting I use them, but after implementing it that way, I have to take a step back and figure out how it was beneficial to the application versus implementing the architecture without using RobotLeg’s version of mediators. That’s the key feature I’m missing.

In any case, this was all in the past. Mostly just experimentation in an attempt to learn new ways of application development which resulted in a framework that wasn’t for me. No big deal. I moved on as a continued happy Parsley user. However, fast forward to current times and I ended up in a situation in that two contracts in a row involved development using RobotLegs. I thought maybe that enough time has passed that the framework may have matured into something “a bit more” than what I was seeing previously. Or maybe this time a light switch in my brain would turn on allowing me to see some crucial aspect I failed to see the first time around. Unfortunately, no such thing happened.

The first of the two contracts that I needed to utilize RobotLegs wasn’t much of an issue.  The application was mostly complete and I was brought in to help finalize it. That meant that most of the architecture was already in place. What little interaction I needed with the framework was a simple matter of following the guidelines, checking in the code, and calling it a day. The application definitely had an over-engineered feel to it and my estimates tended to be a bit under-estimated do to the additional implementation required to follow the suggested RobotLegs architecture, but so be it.

The second of the two contracts was a bit more problematic. This was another application that was far in development by the time I was added to it and it was far more complex than the previous (but I’d still label it as a small-to-medium sized application compared to others I’ve worked with) and followed the RobotLegs-way of development fairly close to the suggested guidelines as far as I understood them. Never-the-less, the application started to get out of hand to the point that an entire iteration was planned just for refactoring. I’m certainly not putting all the blame on RobotLegs, for a lot of it had to do with unrealistic deadlines, scope creep, and just about every other common issue that leads to application failure. However, it was also filled with so many view/mediator class combinations (which probably made up two-thirds of the entire application) that were doing absolutely nothing except making simple tasks more complicated and time consuming. The hardest part for me was being asked my opinion on how we could simplify things. I tend to be in more of a mentor role with magical answers to these types of questions, but in this situation, I had nothing to offer. With so much already implemented and dependent upon RobotLeg’s suggested architecture combined with a deadline looming, I knew that a major architectural change was out of the question. The only thing I could have recommended was to keep on doing things the RobotLegs way and get through it.

So, is anything I’ve said up until now valid? I believe so. Could a seasoned RobotLegs developer show me where I’m going wrong and lead me to the light? Perhaps. If anything, this just goes to show that no single architecture will fit every developer’s preferred style. I think that’s why I’ve always preferred “frameworks” to “micro-architectures”. Like Cairngorm before it, RobotLegs is a self-described micro-architecture in that it provides suggestions on how to property architect your applications. I specifically use the word “suggestions” because, obviously, you can use RobotLegs however you want. But if you’re not going to use it the RobotLeg’s way, then why use RobotLegs in the first place? As I’ve said before, you can get DI and messaging buses and host of other nifty utilities from other frameworks – frameworks that are specifically designed with no architecture style embedded (which was always one of the leading cons with Cairngorm) allowing you to use presentation models, mediators (and in a way that makes sense to you) or any other pattern, or nothing at all. No reason to beat around the bush… I’m specifically referring to Swiz, Parsley, and SpringActionscript (it’s been too long since I’ve looked at Mate to categorize it one way or another).

Maybe one day I will, but for now, I simply don’t grok RobotLegs.

Tuesday, April 17, 2012

Using defaults.css in Flex Library Projects

In many of the development departments that I contract and consult with, it's very common to see the use of internal Flex Library projects to help separate the code base. However, it's rare that I see defaults.css and manifest.xml files in use with those projects. I thought I'd spend some time talking about them; what they do and why you should use them. This post will just deal with defaults.css and then I'll talk about manifest files in the next post.

When creating library projects to hold custom components, it's common to want to set default styles. This is even more important when writing to the Spark component architecture with skin files. You don't want the users of your components to have to add a properties or css to hook up the default skin files to their components.

I've seen some instances where the component developer sets these styles in the component's constructor. This seems to work fine with most styles, but it's problematic with skin files. For example, specifying a skin file in the component's constructor disables the ability to set a different skin as an attribute when defining the component as an MXML tag.

Another common approach is setting up static initializers in your components that look up style declarations and set defaults when certain declarations aren't found. I've seen no issues with this method but it's quite a bit more work involved compared to using a defaults.css.

Things would be much easier if you could specify a style sheet for your library projects to use. The problem is that there's no primary Application file, like in regular Flex projects, to hook a style sheet into. This is the problem that a defaults.css solves. If you've ever browsed the Flex SDK file system, you probably know that the SDK is really just a set of various library projects. The SDK libs that contain visual components (such as ths mx and spark libs) each have their own defaults.css file in the library source root. These are what gives the components their default look and feel without you having to specify any css yourself. This is a technique you can use with your own library projects.

The rules of using a defaults.css are very simple. And there's really only two rules.

  1. The file must be named "defaults.css" - all lower case.
  2. The file must be in the root of the project's source.
As for rule #2, if you're using FlashBuilder's default source directory, the file must be placed directly in the "src" folder. If you're using maven conventions, then it will probably be located in the "src/main/flex" package.

That's really all there is to it. You define default styles and skins for your project's components as normal.

Monday, April 9, 2012

Flex CollapsiblePanel Component

Yea, I know. Everyone and their mother have created a collapsible panel component in Flex. However, this particular component is actually just one part of a larger component I've been working on. Figured it wouldn't hurt to release it as a standalone component. Other than that, there's nothing special about it.

Either scripts and active content are not permitted to run or Adobe Flash Player version 11.1.0 or greater is not installed.

Get Adobe Flash Player

Source  code located at: