One of the things I like a lot about Parsley are all its extenstion points and available hooks to extends its native functionalities or default behaviours. In these regards a very useful extension point is, Tom explained a while ago, the different configuration mechanisms.

As explained in the documentation you can use a combined configuration mechanism to separate more dynamic or change-prone definitions from the more static ones. You could use an XML-based context defintion for the former and an MXML-based context definition for the latter.

While the XML-based context definition might work in most of the cases it might not be the best solution in some scenarios due to its verbosity.

Imagine I have an AIR2 based application which creates an HTTPServer instance. The server instance is created an managed by a Parsley Context:

The second constructor parameter, 5000, is the port the server will be listening to and the third-one, 0.0.0.0, is the network interface where the server will be binded to.
These 2 parameters are potentially prone to change whereas the rest of the definition will be very static and rarely change. In my case these parameters should be configurable and maintained by IT administrators or even final users.

Moving this definition to a runtime configuration mechanism seems like the right thing. The main problem of moving this into an XML-based context is that it’d be too verbose and meaningless to the the targeted users who should maitain and drive the changes, thus making the configuration system of the application too weak and error-prone while exposing things that shouldn’t be changed (at least by these users).

What I would like to do is define in a more static way the server creation instance, making it safer to undesired configurations, but make more dynamic some of its arguments:

Then we could define the port and host parameters using any other mechanism.

My approach has been to create a properties file based configuation. I create config.properties like:

And then the following combined configuration mechanism:

This way the Parsley Context is built using an standard mxml approach together with a properties file based configuation. The PropertiesConfig implementation uses ContextBuilderProcessor and AsyncConfigurationProcessor extensions, load and parse the specified properties file and inject the property definitions into the context as simple strings. These definitions can then be used elsewhere normally.

You can find attached the entire implementation. Note that I implemented this against trunk (v.2.3.M1-snapshot) so it might not work out-of-the-box for other versions.

This technique could be used in a wide range of scenarios. You could define RemoteObjects and ChannelSet in an MXML compiled configuration file but inject from a properties file the url of the Channel. i.e.

In the config.properties:

And the declare the ContextBuilder as:

Note, as suggested by Jens, that there might be scenarios where a tag like ObjectRef is not a good fit (like when using some of the built-in Flex tags like mx:RemoteObject). Being able to use a plain Flex binding on a simple MXML attribute might be a nice alternative to having “heavyweight” top-level String objects.
Other very intersting ways to achieve this same behaviour suggested by Jens (all kudos to him):

1. Use XML Configuration declaring strings like:

2. Create a custom tag that does the above in a more concise syntax using the Spicelib XML-Object-Mapper and a Parsley XMLConfigurationNamespace. You can see an example of this approach in Cairngorm3 Module library

3. Use the approach of an Environment class holding these values in the XML file, but use a custom tag in MXML:

The PropertyRef tag would require a bit of work (and it would be different for Parsley 2.2 and 2.3 due to some changes in internal APIs.

Download PropertiesConfig for Parsley..

For simple String concatenation like:

You can alwayus use StringUtil.substitue, which will help you having a wider vision of the message being built:

When creating multi-line Strings, things can easily get uglier:

Not to say that this could get worse. A way to make it a little bit more readable would be using the StringUtil substitution technique:

The problem with this is that there’s still too much infrastructure to create the base template and it’s difficult, at first sight, to see where are the substitution tokens. On the other hand, the templated text by itself might not have that much relevance in the code and might distract developers from other imporntant things.

A nice way to achieve the same result consists in externalizing the template to a text file and get some help from the compiler:

Where yourTemplate.txt is a simple text file with the template itself:

Note that using the [Embed] metadata instructs the compiler to link the file content at compile time, making our code completely synchronous.

Also note that we’re substituting the parameters using the order, it’d would fairly easy to do a named-parameter subsitution instead (i.e. using tokens like ${var1})

Finally, in MXML you can use this other technique to compile an external text file:

One way to implement it, would be as an extended concept of a template component as explained in my previous post. It would basically be a template component with 2 customizable areas: the frontView and the backView. As a developer I’d then use it like:

The interesting thing about this component is that there’re a bunch of different ways to present 2 panels and to transition between them i.e. flip, wipe, zoom, etc. If we encapsulate the logic of having 2 areas or content holders we can extract the presentation or view customizations into skins.

See sample fullScreen
Browse code.

The component is implemented using states, although it could be implemented without using states to prevent the views to be mutually exclusive, the base idea would be essentially the same: define contentHolders where we addElements set in certain properties.

A very interesting feature we still to add is deferred instantiation of the frontView and backView. By typing frontView and backView as IDeferredInstance will prevent the application from paying the cost of initializing the views until the user actually wants to see them. This means that if the user doesn’t click on the button the back view won’t be instantiated.

See sample fullScreen
Browse code.

If you use this component make sure you grab the one with deferred instantiation.

This is just a proof of concept and the code might have some problems. You can use it at your own risk.

In Flex3 you could use the technique explained in the Flex documentation in combination with [DefaultProperty] metadata. The technique basically consists in creating a subclass of a Container component who defines properties with a general data type that lets the component user specify an object of a concrete data type and then reparents it.

Flex4 Skins, by definition, serve the purpose of a templating system. If you consider the example of a s:Panel you have the PanelSkin where you can really easily change and adapt the template and where and how the provided / customizable content will be placed.

If you have to create a templated component with just one customizable area, maybe the best approach to create it would be to use an s:SkinnableComponent. In the following example I’ve created a very simple template that places a header an a footer around a given component.

Where TemplateSkin1 is:

The SkinnableContainer base class provides a series of functionalities like creationPolicy and layout property proxying or deferred instantiation that makes very easy the task of creating templated components.

See sample fullScreen
Browse code.

In more complex scenarios where the template has more than one customizable area SkinnableContainer might not be the best choice. You can find further information about this scenario in the DualPanel component post.

The stacktrace of these exceptiosn, normally, looks like the lines below:

Today, snooping around the UIComponent class, I’ve found a nice unexpected thing. Basically the invalidation pattern in the SDK is built around the LayoutManager and the UIComponent classes. The callLater method is the responsible to delay the execution of certain functionalities to the next frame. callLater implementation relies on the RENDER and ENTER_FRAME frames. The handler for these events is the method callLaterDispatcher.

Here’s the surprise. If UIComponentGlobals.catchCallLaterExceptions is true, the execution of the validation cycle will be wrapped with a try..catch and a DynamicEvent will be dispatched through the systemManager with information about the error.

This opens the doors for at least catch the error and log it. In some cases, depending on the severity of the error and if the application is not too corrupted, we’ll even be able to display a message to the user notifying him the error. This is not a fix to FP-1499 nor FP-444 but under some circumstances it can be really helpful if combined with great logging practices as explained by Tom.

I’ve created a simple class that hooks into the systemManager, listens for the callLaterError event and logs it using the standard SDK logging mechanism. The AsyncErrorLogger is MXML friendly so that it can be instantiated in the root application. It provides an enable property to switch the behavior on and off. Additionally the property redispatchErrorEvent, which by default is false, redispatches the error causing the traditional flash player error dialog to appear (in debugger player versions) and not fail silently.

Here’s an example on how to use it:

Here’s the code. You can download the class from here as well.