Include the plugin:

 <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
      <execution>
        <id>copy-dependencies</id>
        <phase>package</phase>
        <goals>
          <goal>copy-dependencies</goal>
        </goals>
        <configuration>
          <outputDirectory>${project.build.directory}/alternateLocation</outputDirectory>
          <overWriteReleases>false</overWriteReleases>
          <overWriteSnapshots>false</overWriteSnapshots>
          <overWriteIfNewer>true</overWriteIfNewer>
        </configuration>
      </execution>
    </executions>
  </plugin>

Invoke

mvn dependency:copy-dependencies

to copy all the dependencies of a project to the specified target folder.

mvn dependency:copy-dependencies -Dclassifer=sources

will copy all sources.

mvn dependency:analyze

shows information about used and unused declared dependencies.

mvn dependency:tree

gives an overview of the nested dependencies.

Here’s a useful little interactive cheatsheet I made to better remember all the functions inside the Flex lifecycle. I’ve never found the time to validate all the descriptive stuff so please use with care. Most of the information provided should be pretty accurate and should still be applicable to Flex 4.6. But again, be sure to double check.

This little tool visualizes the lifecycle of the Flex 4 Spark component model and hopefully helps to understand what happens behind the scened.

Basically it is an expanded stack trace with comments showing the most important method calls during the lifecycle’s birth, life and death phase including invalidation and validation.

Flex 4 Spark Lifecycle

Flex 4 Spark Lifecycle

Demo

It shows the method calls of the 3 relevant objects regarding the Spark component model, namely SkinnableComponent (in this case a Button), its SparkSkin and the associated BasicLayout.

The traced component (Button) is shown at the top. To the left you can invoke method calls like you would from client code to see what methods get called when and where. Right underneath you’ll find the current values of some important properties of the traced component.

Disclaimer:
The information provided here is based on my own experiments, tracing the source code of the Flex SDK (4) and the docs. Information hopefully is, but may not be accurate. So, in any case, please double check when relying on it.

Here’s a little thing I’ve thrown together a while ago. Pick and create football-formations.

It features a couple of custom components like a JerseyEditor, a simple Color-Picker a formation list and some custom item renders.

You can adjust the formations on the fly entering any system you like. Try 4-4-2 if you’re more in for a classical style, try 2-3-4-1 for an attacking lot or use drag and drop to adjust your own custom formation.

Clicking on a player opens up the editor so you can add your own players. And no, the colours of the jersey editor do not get passed over right now.

Adobe Flex Prototyping - A Footie Formation Builder

Demo

There are lots of features missing. It’s a prototype, source is available but not meant for production.

It’s been a while since Adobe managed to nuke its developer base with a single press release. In the past few months I’ve been repeatedly asked if I would still bet on Flex, so I might as well write it down. My short conclusion: Flex has a future but within a limited scope. I won’t sum up all my thoughts here, since Jesse Warden has already thoroughly written down the whole situation, which reflects my point of view quite well.

Fact is Flex (Spark!) is a wonderful (component) framework. Separation of concerns is very well done, the API has good granularity and flexibility, there’s a well defined component lifecycle that fosters reusability and the runtime performance is good enough.
Flex missed great components out of the box and compilation and refactoring should have been better.
Flex is a damn good Framework to do RIAs and it had and still has a damn good community to support it. However, in my point of view, the dependency on Adobe and the Flash Player is a burden and JS/HTML5/CSS3 is growing fast to replace it in many areas.

I guess it comes down to this:

If your application targets the Intranet and you do have control of the runtime environment and consistency of the runtime is critical to your application, then Flex is still the most productive, robust and easiest way to develop a rich client. Rich Trading and Banking applications come to mind and there’s enough money in it to support a career. In this type of scenario I can see Flex as the preferred RIA-Framework for many years to come. Further I think Flex is an excellent choice to do prototyping in complex scenarios.

In a consumer oriented market however, the Flash-Player and therefore Flex will continuously lose ground. Developing complex, consistent and maintainable RIAs in HTML and JavaScript is hard but many of the issues are being addressed by approaches like, Google Closure Tools, Ender, SASS, LESS and tons of great libraries like ExtJS, backbone.js, knockout.js, bootstrap.js and jQuery to name just a few.

Initially, the first time I turned towards Flash in 2001 to create onmodular was because I – like many others - was frustrated by the limited possibilities in the browser and by SUN Microsystems’ inability to establish the JVM in the browser. Enabling rich interactive content was the raison d’être of Flash. Later on, for many Java-Developers including me, Flex was a great framework for the view layer. Now, with wide HTML5-Adoption around the corner, both Flash and therefore Flex lose their reason of existence in many fields. If your focus is Web-Applications or Cross-Plattform Mobile Apps, it is definitely time to move on.

Also, no one should be too worried that the investment in Flex has been for nothing. Many of the paradigms that have been used in Flash or Flex reappear in JS/HTML5/CSS3. Migration is quite straightforward.

I’m writing this in response to the e-mails I get regarding the future of Flex. I’m writing this as well to let you know that I won’t reply to any request for support regarding the custom components you might find on this blog anymore. I still use Flex for prototyping and some commercial projects where applicable but I think it’s time to move on.

If you need some starting point and want to get the basics right I’d recommend

Javascript: The Good Parts

How Browsers work

Essential Javascript Design Patterns

From Flex to Sencha

Good luck and see you in the browser.

I decided to create a platform for city ratings and –rankings. I polished the whole thing a bit in the hope to attract some visitors. I wonder if I can get some peaks in traffic to see how this service will perform in GAE under load outside of a stress test.

To see what I’m talking abput, a first version is up and running at CityClash.org. To read about my experience with Google App Engine read on after the screenshot.

Building CityClash.org involved a couple of interesting aspects towards Google App Engine, the datastore and Spring MVC.

• The usual CRUD ops
• Transactions
• Joins & aggregation
• Long running processes
• REST-style with JSON response
• External API calls
• Developing for scalability

I used the SpringSource Tool suite with the GAE-Plugin for development. Setting up Spring with GAE was straightforward and worked as expected. Add the required jars and configure the spring project as you would normally do. Note, I’m referring to the MVC part of Spring and can’t speak for the other parts right now.

Spring 3 MVC

The REST-features and Ajax-simplifications in Spring MVC worked in GAE  just fine. This stuff is really well done in Spring and a joy to work with.

Task queues in GAE

Task queues in Google App Engine are a great way to speed up the user experience, by simply doing expensive work later and not during a user’s request. If some calculations need not to be done immediately task queues are worth considering.

When a city rating in CityClash comes in, I defer calculations of some statistical figures to a task queue. The user does not need to know about these figures immediately, it’s good enough when they get updated a couple of minutes later and the user gets a rather quick response.

Task queues are easy to set up. In a couple of lines you get a Queue from the Factory, create, configure the task and add it to the queue. The Queue will later invoke a HTTP-Request based on the Task. The actual work is then done in the handler that serves the request.

URL Fetch calling external apis

For Internationalization purposes I need to translate the city names to the local language. In CityClash.org I currently support German and English. Via Geocoding I get the English name but I need the German name as well. For Berne, Switzerland I need Bern, Schweiz too.

In Google Maps I could invoke another request asking for the German name, but I was a bit worried to get over the quota or get blocked for invoking too many requests at a rate too high. For this reason and for the fun of it, I decided to use the Google Translate API to get the localized name.

If CityClash gets a rating from a city that had not been rated before, the Google Translate API gets invoked and fetches the German name once. This is simple and straightforward. Use java.net.URL to open a connection and parse the stream. To not block the user’s request I put this step in a task queue as well.

Memcache

CC uses the cache as much as possible. I’m using the low level API. There’s not much to say about this. Put and get Serializable objects, use expiration and be sure to have a fallback if values in the cache get lost: it’s a cache not a permanent store.

Datastore

If you come from an SQL-background, then the datastore is probably the most difficult aspect to get used to. It took me a while to think out of the box and accept the limitations and embrace the blessings.

Here are a few key things to note from my newbie point of view and as of now:

• Loose the SQL-mindset. Forget about complex joins, nested queries and aggregation.
• What you get is sort of a distributed Hashtable, optimized for reads. The datastore is organized in a fashion, that lets it efficiently scan and read data. Stuff like filters (<,<=,= etc.), order by, ancestors or keys can be applied to the queries. But there are limitations of how you can combine the filters, orders etc. too.
• As to expect, reads are fast, especially when using keys.
• Don’t spoil this by trying to work around the limitations regarding joins and aggregation. Doings loads of calculations in memory to mimic such behavior won’t scale well and will cost you cycles.
• Instead store the data in a fashion that embraces the usage pattern.
  
• Try to do calculations once, when writing. Prepare the data for simple, efficient reads.
• If writing takes too long try to delegate some stuff to task queues and do the hard work later.
  
• Accept and embrace denormalization.
• Use task queues and cron jobs where possible to do long running processes in the background. In CC lots of aggregation is done in the background.
• Writes are expensive, since they may need reorganization. Be aware of contention.
• If writes have the potential to cause contention, consider sharding or use smaller entity groups.
  
• Transactions are there but only spanning over the same entity group . I tried to stay away of transactions alltogether – and denormalize.
• I stayed away from JDO and JPA because I could. Where’s the point of having another abstraction layer over a HashMap? I used the low level API in conjunction with objectify, which itself makes for a very good documentation on the datastore.
• There’s no full text search. The most you will get is a filter-order combination to mimick a sclaed-down LIKE on crutches.
  

Again, these are not necessarily best practices; they just reflect my take on the datastore of the appengine right now.

Mail

Sending mail is a no brainer and works straight out of the box. The only restriction is that the sender address of a message must be the email address of an administrator for the application.

Development Server

I have yet to discover any inconsistencies between the development server and the appengine in terms of behaviour. The test skeleton is pretty good too.

Flex

I didn’t bother to use the Spring Blaze integration. For the couple of requests and the few data I simply used the HTTPService. The new REST-full features paired with the JSON response made it easy to integrate Flex and Spring. Same applies to the Ajax-Calls through JQuery.

JSTL

My experience was, that there are some minor issues with JSTL inside GAE. For example, I could not get hold of an object-reference via the var attribute inside the forEach-Tag. Possibly my fault and I didn’t bother too much since the index-based approach using the varStatus-Attribute works fine. Further the formatNumber-Tag didn’t work since its implementation apparently needs a reference to the session. I did not want to turn on sessions (backed by memcache and the datastore) just for this, so I formatted the numbers in advance to be consumed by the page building.

Conclusion

So far I’m pretty impressed by GAE. It has restrictions and it took me some time to get used to the datastore first. But once you get the hang of it, things work out pretty straightforward.

And you get the advantages

• Scalability (can’t really judge on this right now),
• Pay for what you use
• Easy App versioning
• No Server-Management and maintenance.

While I can’t really judge on the first as of now, the last point especially, for me, is a real blessing.

After all, it depends whether your app can live within the constraints of GAE (mainly the datastore). I’d say Google App Engine is not the right tool for complex business applications as of now, but is a great environment for simple to moderately complex web-apps. For independent developers or startups the PaaS-approach might very well be the right thing.

Others don’t agree and I might change my opinion in 3 month or so after having seen CC run inside GAE for a while, but for now my first experience with google app engine was pretty pleasant.

The ruler can be scaled down or up by holding CTRL/SHIFT while clicking and can be moved by holding the ALT-Key and keeping the mouse button pressed. When scaling an animation is applied for smoother transitions. For the labels an array of Strings can be set, each one defining a division on the ruler. The number of subdivisions can be set as well

Simple ruler component. View source is enabled.

Custom GraphicElement to draw tick lines

Instead of using and FXG-Path element a custom GraphicElement has been created to draw the tick lines. This makes for a cleaner and more generic approach when drawing the ruler and reduces overhead when animation is applied while scaling.

Dynamic skin parts for the Labels

For the labels dynamic skin parts are used. Here’s a little recap on how to work with dynamic skin parts.

• Declare a dynamic skin part in the Declarations segment of the skin. Wrap it up in a Component and give the component an id.
• Declare the skin part in the component, referencing it via id in the skin. The type is of mx.core.IFactory.
• To create a dynamic skin part at runtime call createDynamicPartInstance([id of skin part]) from the component. This will return an instance of the desired skin part.
• In the component add this instance to the skin or a group within the skin.
• Optionally add it to an array for dynamically created instances for easier housekeeping.
• Any Listener is best added in partAdded() similar to adding behavior to static skin parts. When adding event listeners do not forget to remove them in partRemoved().
• A dynamic skin part can be removed at runtime by calling removeDynamicPartInstance([id of skin part], instance). You also need to manually remove the instance form the group you’ve added them.

If you need more information on dynamic skin parts, check out this great article by Florian Fesseler.

Now, it’s time for the GraphicElement.

Example using custom Graphic Elements. View source is enabled.

The GraphicElement and its subclasses are responsible to draw a significant amount of the Spark components graphics. FXG elements like Rect, Path, Line etc. all derive from GraphicElement.

A GraphicElement is actually neither a DisplayObject nor does it offer any form of interaction. Its super class is the EventDispatcher and it uses an internal DisplayObject to draw itself into. It does implement interfaces like IVisualElement and IGraphicElement and can therefore be laid out and displayed by Spark.

The internal display object used for drawing purposes is set and managed by Flex and multiple graphic elements can draw onto the same display object. Sharing display objects reduces overhead and in most cases leads to better performance.

This naturally has some implications which need to be considered when creating a custom GraphicElement

• A GraphicElement gets a DisplayObject to draw into and the display object might be shared. Both is managed by Flex.
• If a GraphicElement needs to be redrawn all other graphic elements that share the same DisplayObject will need to redraw themselves.
• If creating a custom GraphicElement which shares a display object with other graphic elements, make sure to not clear the graphics, as this would wipe out drawings that have formerly been made by other elements.
• Properties that are applied to the DisplayObject will be reflected by all graphic elements that share the same display object. Thus, the use of individual filters, color transformations, rotation etc. require the GraphicElement to own its own display object. The standard implementation takes care of this.
• Since GraphicElement is not a display object, we need to get a reference to the graphics object for drawing. We can get this reference form the drawnDisplayObject member.
• When drawing, the offset of the graphic element relative to its display object has to be taken into account.

Creating a custom GraphicElement

In most cases, there is no need to create a custom graphic element, as the FXG Path element can be used to draw most of the required paths. The FXG Path element takes a string of drawing commands, parses it and translates it to drawing commands that are applied to the display object.
This is well suited for static paths, e.g. the ones that are exported by Illustrator or Catalyst.

On the other hand, if a parameterized path is required we would need to dynamically build a string of graphic commands and Flex would need to parse them again, leading to unnecessary overhead. In such a case it might be better to create a custom GraphicElement that has the required properties and a drawing routine which takes them into account.

UPDATE: For the FXG-Path building approach see the great lightweight charts by Christophe Coenraets.

Creating a custom graphic element is straightforward, a few things must be considered though (see source in the example).

• Override the updateDisplayList() function to call the custom drawing routine, or the draw() function when using a StrokedElement or a FilledElement.
• Get the graphics object from (drawnDisplayObject as Sprite).graphics.
• Respect the coordinates of the GraphicElement relative to the one of its DisplayObject. The drawX and drawY properties of a GraphicElement store the required offset.
• Inside the drawing function do not clear the graphics since the element might use a shared display object and this would clear out graphics that have been drawn by other graphic elements.
• The GraphicElement class implements the IInvalidating interface and can therefore take part in the invalidation process. If a property is set that affects the drawing, call the required invalidation functions and do the update later in the validation pass.

Managing shared display object

The management of display objects for any GraphicElement is done by Flex via the Group that owns the element. In most cases there is no need to care about this, but if required, Flex offers some ways to indicate if a shared DisplayObject is ok to use or if an own display object is needed.

• Use needsDisplayObject() to indicate if a GraphicElement needs his own display object. The default implementation checks if any properties are used that require an own display object (rotation, color transformation, belnd modes etc.).
• Likewise canShareWithNext() and canShareWithPrevious() can be used to indicate if a GraphicElement can be drawn onto the same display object as the previous/next one in the queue.
• It is tempting to use the property displaySharingMode. This does not work as expected, as Flex uses this property to manage the objects and values set manually will be overwritten.
• If Flex needs to create a display object for a graphic element it calls its createDisplayObject() function. The default implementation returns an object of type InvalidatingSprite that implements the ISharedDisplayObject interface.

Interactivity

The purpose of the GraphicElement is to draw and manage graphics in an optimized manner (by sharing display objects). It is not an interactive element, the element is embedded within a Spark container and interaction should be done at a higher level.

To enable interactivity on a graphic element directly, a couple of things need to be done, which in most cases is actually bad practice. However, since this post is about inspecting the GraphicElement, let’s still see what needs to be done do to get interaction on a graphic element.

As mentioned above, the GraphicElement uses a DisplayObject to draw its graphics. The DisplayObject used by a GraphicElement is an InvalidatingSprite (extends from Sprite) that has the mouseEnabled and mouseChildren properties set to false. To get interactivity in a way that makes sense, we’d need to enable interaction on the InvalidatingSprite and disable display object sharing, as we do not want interaction to be affected by other graphic elements that share the same display object.

To turn on interactivity and to make sure interaction is not shared with other elements, we will need to

• override the createDisplayObject() function and
• set the mouseEnbled and mouseChildren properties of the returned DisplayObject to true
• add any listeners to the DisplayObject
• override needsDisplayObject() and return true
• likewise override canShareWithNext() and canShareWithPrevious() and return false

You’ll find the source code for this in the example. View source is enabled.

This of course undermines the attempt of Flex for optimization when drawing graphic elements. If interaction is needed directly on a custom graphic object it might be better to use a SpriteVisualElement that is in fact an interactive object. See the example of a ruler implemented as a SpriteVisualElelement.

Conclusion

The GraphicElement is Spark’s key class to do optimized drawing. If a parameterized path needs to be drawn that updates often, it might be a better choice to create a custom GraphicElement instead on relying on the FXG-Path element. Interactivity can be enforced but it is better to handle it on higher levels. If you need a really light weight visual element, that offers interaction and can still take part in the Spark layout process consider using SpriteVisualElement.

For more information on traversing GraphicElements (or IVisualElements in general) read this excellent write-up by Bill White.

In a project I created a custom PopUp, nothing fancy, just a couple of text inputs. When I tried to enable Tab key navigation I set the required properties but Flex would simply ignore tab key navigation to the input fields in the pop up.

The Documentation about the IFocusManager states that a pop up will get its own FocusManager and its own tab loop.

After some tracing I found that my pop up and its child weren’t included in the FocusManager as focus objects. In fact, there was no FocusManager for my pop up at all.

The reason for this is that when the PopUpMangerImpl is about to create and configure the pop up, it checks if the pop up is a IFocusManagerContainer so that focus can be added.

Unfortunately my popup was a Group which does not implement the IFocusManagerContainer interface. Naturally no FocusManager would be created.

If you want to use a Spark Group as your pop up, the solution is to create a new class that extends from Group and implements the IFocusManagerContainer. Then use this class as the container for the pop up.

.
.
.
public class AHPopUpGroup extends Group implements IFocusManagerContainer
	{
 
		public function AHPopUpGroup()
		{
			super();
		}
 
		/**
		 *  @private
		 *  Storage for the defaultButton property.
		 */
		private var _defaultButton:IFlexDisplayObject;
 
		[Inspectable(category="General")]
 
		/**
		 *  The Button control designated as the default button for the container.
		 *  When controls in the container have focus, pressing the
		 *  Enter key is the same as clicking this Button control.
		 *
		 *  @default null
		 */
		public function get defaultButton():IFlexDisplayObject
		{
			return _defaultButton;
		}
 
		/**
		 *  @private
		 */
		public function set defaultButton(value:IFlexDisplayObject):void
		{
			_defaultButton = value;
			ContainerGlobals.focusedContainer = null;
		}
 
	}
.
.
.

And the mxml for the pop up becomes something like this

.
.
.
 
		<!---
		Uses a Group that implements the IFocusManagerContainer
		-->
 
			.
			.
			.
			TextInput, Buttons etc now get focus on tab key navigation
			.
			.
			.
 
.
.
.

A class that gets less attention, but might be useful in a couple of scenarios to create a control alternatively, is the SpriteVisualElement class.

This example shows an implementation of a simple ruler by extending the SpriteVisualElement.

The SpriteVisualElement

The SpriteVisualElement is a display object that can be used inside spark containers.

It inherits from Sprite and implements the IVisualElement interface and can therefore take part in the spark layout process. This means, properties like height, width, top, right, bottom, left etc. can be used to lay out a SpriteVisualElement like an UIComponent.

As it inherits from Sprite you’ll get a reference to the Graphics object to draw onto and all the common events of a flash interactive object (mouse, gestures, focus etc.) - in other words, a flash sprite that can be used within the spark architecture.

The SpriteVisualElement is light-weight and might be the better choice to implement some interactive object if you can live without all the bells and whistles of the UIComponent. Less features, less overhead.

Use inside the Flex layout pass

Implementing the ruler is like coding a sprite in Flash but there’s a little additional work required to hook it up with the Spark layout pass.

During the layout pass Flex calls

• setLayoutBoundsSize(width:Number, height:Number, postLayoutTransform:Boolean=true)

We can override this function to call our drawing function.

override public function setLayoutBoundsSize(width:Number, height:Number, postLayoutTransform:Boolean=true):void 
{
	super.setLayoutBoundsSize(width, height, postLayoutTransform);
 
	//call our drawing function
	draw(width, height);
}

The ruler has properties for the number of divisions and subdivisions. Both require an update to the graphics so we need to tell Flex about this. We can achieve this by calling

• invalidateParentSizeAndDisplayList()

This will mark the parent component as invalid and will finally trigger a call to setLayoutBoundsSize on our object where we can redraw the graphics based on the updated values of the properties.

public function set divisions(value:int):void
{
	_divisions = Math.max(1, value);
	invalidateParentSizeAndDisplayList();
}

Conclusion

Depending on the requirements, you might want to - and usually do - use the full stack (SkinnableComponent/SparkSkin with nested components and FXG). Still, under some circumstances and regarding resources and performance, implementing a simple component as a SpriteVisualElement may be an option to be considered. Also note, a SpriteVisualElement can live within a spark container, thus you can add it to any skin and mix it up with FXG elements or Spark components.

Click here for the demo. View source is enabled.

For a current project, I needed more like a balloon help in place of tooltips and therefore decided not to use Flex default tooltips.

Regarding usability of the tooltips (balloon help) I want to be able to

• Display an optional tooltip title
• Display formatted tooltip text
• Display icons
• Colorize the tooltip based on the semantic of the invoking control
• Consistent Placement
• Have all title, text, styles for the tooltips stored in a central location
• Have the tooltips work in a generic and Flex-compliant way

Flex gives you a few ways to customize tooltips from registering your custom ToolTip class to intercepting Tooltip events where you can hook up the custom tooltip. All of these approaches fall either short of the requirements I had or would add additional overhead so I simply created a custom ToolTipManager that would alter the behaviour of the default ToolTipManager.

Here’s a demo of the final result, the approch is described further down.

Since I like to have all resources centralized, the approach I followed was to interpret the value of the tooltip- or the errorString property on a control not as the tooltip text to display but as a partial key to lookup title, text, styles etc. in a resource bundle. Form this partial key concrete keys would be derived to lookup the values for a controls tooltip.

For example

<s:Button label=”OK” tooltip=”ToolTipBundle.okButton” />

would point to the ResourceBundle named  ‘ToolTipBundle’ and within this to all entries of a key starting with tooltip.okButton. Then the values for title, text etc. will be looked up by the custom ToolTipManager implementation and be applied to the tooltip.

The first token in the tooltip property specifies the name of the resource bundle, the second token the partial key for looking up the entries in the resource bundle. If no second token is specified the id (if any) of the component is being used.

Entries in the resource bundle then refer to the partial key submitted and define the concrete values to use for the tooltip.

tooltip.okButton.title=Title of Tooltip
tooltip.okButton.text=Text for this tooltip
tooltip.okButton.styleName=CSS class to use for this tooltip
tooltip.okButton.placement=bottomRight|bottomLeft|topRight|topLeft
tooltip.okButton.color=Color of text
tooltip.okButton.chromeColor=Color of tooltip

Color and chromeColor are there for convenience but can also be set via the CSS class specified by styleName. If any of the entries are not specified fallbacks to default values are used.

To make this work some methods of the default ToolTipManager need to be overwritten

override mx_internal function initializeTip():void

This is where the cstom implementation looks up the values and assigns them to the tooltip.

Additionally there’s the

override mx_internal function positionTip():void

method to position the tooltip in a custom way.

The custom ToolTipManager implementation is registered at loading using a custom preloader class.

The custom Tooltip itself  is a simple SkinnableComponent associated with a SparkSkin. There’s a required skin part for the text and a dynamic skin part for the label that only gets added if any value for a title  is provided.

For both title and text a RichText component is used within the skin so that formatting the text in a rich way is possible. The associated skin is then responsible to draw the tooltip based on the provided placement.
Having set this up, usage of the custom tooltips for any app is simple.

<s:Application               
    preloader="com.hulstkamp.flex.spark.preloaders.CustomMixinPreloader">
</s:Application>

This will register the custom ToolTipManager.

For additional documentation see the source in the demo (view source is enabled).