sybersnake

Comptibility: 3.0+

You can extend CSS’s basic functionality with Custom Data Types by adding your own code to line: 7808 ( function getStyle(styleProp:String)* ) of mx.core.UIComponent. I recommend doing this by copying paste the original UIComponent class, from your destination version of the Flex framework, into your project under the same package name. This will allow your version to override the compiled library version.

I’ve extended CSS with a custom protocol for a library engine I’ve dubbed ‘Fuze’ for the moment. The implementation of the protocol in the CSS file looks like this:

1

upSkin					: "Fuze(splashelements>ButtonSi)";

The reason why implementing the override on the UIComponent class is to interject some business logic to your protocol. In my example, the FuzeService takes the protocol and returns the proper library item.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public function getStyle(styleProp:String):*
{
    var ret:* = StyleManager.inheritingStyles[styleProp] ?
                            _inheritingStyles[styleProp] :
                            _nonInheritingStyles[styleProp];
 
    if ( ret is String && (ret as String).substr(0,5 ).toLowerCase() == "fuze(" )
    {
        if (FuzeService.hasLoaded( ret ))
        {
            // Cache it here.
            var clz:Class = FuzeService.getDefinitionByURI( ret );
 
            if ( StyleManager.inheritingStyles[styleProp] )
                _inheritingStyles[styleProp] = clz;
            else
                _nonInheritingStyles[styleProp] = clz
 
            return clz;
        }
        else
        {
            throw new IllegalArgumentException("The Requested Fuze Dynamic Skin Library Has Not Yet Loaded, Please check your code to make sure the library has loaded before you initialize any mx.* components using the CSS Fuze extension ");
        }
    }
 
    return ret;
}

I am a big fan of Signals/Slots and the Messaging Paradigm used by Cocoa. Since neither can really be implemented flawlessly in AS3(without some major potential performance issues down the road). I came up with a Hybrid Event Pattern solution I call the “Juki Event Pattern(JEP)”. Here is a PDF document outlining the pattern.

The major difference between JEP and the one adopted by Java/Flash is the fact that the events are exposed as public getter functions. This leads to whole new worlds of interface-required events. However, the pattern maintains full backwards compatibility with the built-in event pattern. JEP is an extension of the basic event pattern and requires a IEventDispatcher for the purpose of carrying out the actual dispatching.

A simple interface is used to “connect” a listener function or event to another event. Yes, I said you can connect one event to another. Also because the events are exposed as a public getter you could essentially wrap another event from a asset class and expose it as your own.(think about that for a moment). I have provided three connection options: “connect”, “connectAsSilent”, and “connectAsPassThrough”. Respectfully the operations are basic connect: where the event object is passed to the listener, where nothing is passed to the listener, where all arguments of the dispatch() method are passed to the listener.

Full disconnect.  As requested, I have provided the ability to disconnect from all listeners.  I also maintain a list of the listeners in a soft-linked Dictionary object.  This was also another request that I ended up finding useful for internal uses.

Dispatch log.  I made a decision early on that my primary problem with the default event pattern is that there is no way to tell if any specific event has already dispatched.  The problem here is sometimes a event only fires once.  Say, If it represents a “download complete”.  It fires once, if you fail to catch it, your screwed.  Normally, I’d say, check your code try to catch it earlier.  What if that wasn’t possible tho.  I maintain a array of the last arguments passed to the event and if it has dispatched yet.  Sadly, for memory purposes I have chosen not to capture dispatches outside of the JEP.  I may implement this as a “use as your own performance risk” feature later.

I just wanted to make a quick point.  If you ever find yourself requiring the ability to add a NON UIComponent/IUIComponent DisplayObject on the stage in Flex.  You can simply use a SWFLoader instance because it does not force UIComponent/IUIComponent type checking.

Below is a example I setup to load Image data as a Image as Class but this could be anything, Sprite, MovieClip, etc.

1
2
3
4
5

[Embed(source="images/myimage.jpg", mimeType="image/jpeg")]
public var tileExample:Class;
var loader3:SWFLoader = new SWFLoader();
loader3.addChild( new tileExample() );
loader3.y = 550; this.addChild( loader3 );

The new Styling Mechanism allows for a better control of shared Style Definition bases versus sharing the Proxy directly. The Style Definition will also signal all connected proxys of any changes. Style Proxies contain the local-only definition, including overrides and cache information for extended lookups. Changes can be “pushed” to the definition. The Proxies inherit automatically as parent/children in the DisplayList and can be turned off. The Master Style Dictionary can also load multiple CSS files. Expect tighter integration with the Theme Server for use with “groups” to define a fully inheritable solution for any desired use. There is also a new mechanism for “impact decisions” for the state of the DisplayObject. More later.