I have a Button object in my application that glows when a certain condition is true. When that condition is false, the glow Effect must be removed. When I initially took a stab at this, I was using the setStyle() method of the Button object in an attempt to set the showEffect property of the Button. With this method, I needed to hide and then immediately show the Button. This felt like a hack, and it was…

<mx:Button id="messageButton" label="Simple Button"
      showEffect="{glowEffect}"
      toolTip="Click to read the alert" />

<mx:Script>
   <![CDATA[

      public function glowElement(condition:Boolean):void
      {
         messageButton.visible = false;
         if (condition == true)
         {
            messageButton.setStyle("showEffect", glowEffect);
         } else {
            messageButton.setStyle("showEffect", "");
         }
         messageButton.visible = true;
      }

   ]]>
</mx:Script>

This information took me a while to find, so I’m publishing an article to make the info more available. Most examples you find involve effects being added, or assigned, based on user gestures or standard events.

However, if you want to remove an effect while the control to which it is applied has not changed its state in any way, the proper way is to set the target property of the effect to the control to which you want to apply it.

<mx:Glow id="glowEffect" target="{messageButton}"
        duration="1000" repeatCount="0" repeatDelay="2000"
        alphaFrom="1.0" alphaTo="0.25"
        color="0xFF0000"/>

<mx:Button id="messageButton" label="Simple Button"
      toolTip="Click to read the alert" />

Then when some condition is met in your application, you simply call the end() and play() methods of the effect.

<mx:Script>
   <![CDATA[

      public function glowElement(condition:Boolean):void
      {
         if (condition == true)
         {
            glowEffect.end();
         } else {
            glowEffect.play();
         }
      }

   ]]>
</mx:Script>

Actually, it *almost* has nothing to do with ColdFusion, it’s just that I have ColdFusion setup on my machine and that’s the server I use with Flex apps.

For a ColdFusion server, the WEB-INF\flex\messaging-config.xml file has an additional adapter – called cfgateway – set up as default adapter for destinations.

<adapters>
    <adapter-definition id="cfgateway" class="coldfusion.flex.CFEventGatewayAdapter" default="true" />
    <adapter-definition id="actionscript" class="flex.messaging.services.messaging.adapters.ActionScriptAdapter"/>
    <adapter-definition id="jms" class="flex.messaging.services.messaging.adapters.JMSAdapter"/>
</adapters>

So when I created a destination for the quick chat application used in the Introduction to the Flex Message Service article on the Adobe Developer Connection site, it was using the cfgateway adapter by default and causing all kinds of havoc when I tried to run the app.

Therefore, if you are using ColdFusion, just make sure you specify the actionscript adapter when you create destinations for FMS in your messaging-config.xml file.

<destination id="MyTransientTopic">
   <adapter ref="actionscript" />
   <properties>
      <server>
         <durable>false</durable>
      </server>
   </properties>
   <channels>
      <channel ref="java-polling-amf"/>
   </channels>
</destination>

Do It Fast And Do It Well

Those are the two things I’ve always wanted from a wireframing tool. I just want to sit down, and with the image in my head, be able to dump it on the screen in a matter of minutes. No tool – and I’ve looked at many tools over the years – provided me with both features. Most often, it was the “do it fast” that failed.

Finally!

Not so with Balsamiq Mockups. This is a tools written by people who use it and you can tell. It’s got a good, if not exhaustive, library of elements. It’s got a highly intelligent editor. The properties are minimal, but on target. Most importantly, you can export/save the wireframe in the formats that architects and interactive engineers use.

Example

The folks internally wanted me to throw together a quick Flex app for effort metrics on our team. After talking about basic requirements, I had an image in my head of what the UI might look like. Nothing is more frustrating that having this image in your head and (unless you use paper and pencil) not being able to realize it for 45 minutes.

I did this mockup in just around 8 minutes.

Recommend

I very rarely endorse a product publicly, and I really have to love it to do so. This is one of those cases. I highly recommend that you demo this product, and if you are ever responsible for coming up with wireframes, conceptual designs, or just any kind of visual aid for architecting applications, you will love this app.

Just when I start to regain my faith in humanity, all I need to do is one of two things to destroy it again:

1. Read the comments on YouTube. If you’ve never done it, give it a try. It shows how abjectly immature, ugly, vindictive, petty, hateful, and ignorant the human race has the capacity to be.
2. Watch the show Millionaire Matchmaker on Bravo. This is my guilty, little pleasure when it comes to TV. The show’s an absolute train wreck because it shows how horrible some parents are at raising men. The men in the club either view women as commodities that they can custom order, have no respect for women, or simply don’t understand what a woman wants (and believe it or not, guys, it’s not that complex).

Application Design 201

Granularity is a well-known topic in software development. Another common concept is encapsulation. There’s books, magazine articles, and blog posts about these topics going back decades (well, not the blog posts).

One challenge we’ve had recently is trying to apply these concepts to a Flex application that uses modules. We want a global data model that modules can access, but have no way to access its internal mechanisms (i.e. no public variables).

The Shell

The core idea is that we want a common data model loaded into a basic Flex app – the Shell – which has no functionality, in and of itself, other than to load and unload modules that contain the business functionality.

This common data would then need to be accessible to every module that got loaded into the Shell – regardless of whether the module needed it or not.

The Interface

First thing we need is establish an interface that each module can use to identify itself so that when the Shell loads it, the Shell recognizes that it should send its global data model to the module.

People and places have had their names changed to protect their identity…

package com.widget.common.interfaces
{
   public interface ICoolModule
   {
      function getModuleController():Class
      function setGlobalModel(model:Class):void
   }
}

The key method defined for this mechanism is the setGlobalModel() method. This is the method that it called by the Shell (shown below) when it loads a module to ensure that each module has a reference to the global data model.

The CoolModule

I then extended the basic Flex Module class, so that I could implement the ICoolModule interface and provide basic functionality for accessing the global data model

CoolModule.as

package com.widget.common.components
{
   import com.widget.common.interfaces.ICoolModule;

   import mx.core.Singleton;
   import mx.modules.Module;

   public class CoolModule extends Module implements ICoolModule
   {
      [Bindable] public var _globalModel:*;

      public function CoolModule()
      {
         super();
      }

      public function getModuleController():Class
      {
         return null;
      }

      public function setGlobalModel(globalModelLocator:Class):void
      {
          _globalModel = Singleton.getInstance("IModelLocator") as globalModelLocator;
      }
   }
}

Now when I create a new module, it’s a CoolModule instead of the base Module.

Module1.mxml

<component:CoolModule xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:component="com.widget.common.components.*">

Loading the Module

So now that we’ve set up things on the Module end, let’s see how the Shell actually injects its model into each Module. I’ve got a command that handles loading modules with a commandSuccess() method that handles the coupling (significantly stripped down version here just to show the relevent code).

LoadModuleCommand.as

package com.widget.thisApp.business.commands
{
   import com.widget.thisApp.model.ModelLocator;

   public class ModuleLoaderCommand extends AbstractCommand implements ICustomCommand
   {
      ...
      public function commandSuccess(event:Event):void
      {
         if(_component is ICoolModule)
         {
            var coolModule:ICoolModule = _component as ICoolModule;
            ...
            coolModule.setGlobalModel(ModelLocator);
         }
      }
      ...
   }
}

Now, for those who were paying attention, you may have figured out the key to all of this is that the ModelLocator is a singleton. As long as the module gets loaded into the current application and security domain…

module.load(ApplicationDomain.currentDomain, SecurityDomain.currentDomain);

…then it can access the Model singleton.

Conclusion

We’ve found that while module-parent, and module-module, communication is certainly not elegantly built into the Flex framework, it is possible with a little bit of grunt work. I’m hoping that as the Flex SDK matures and becomes more feature-rich that this feature become more robust.