"My advice here is to always provide a way to do all configuration easily with a programmatic interface, and then treat a separate configuration file as an optional feature. You can easily build configuration file handling to use the programmatic interface. If you are writing a component you then leave it up to your user whether to use the programmatic interface, your configuration file format, or to write their own custom configuration file format and tie it into the programmatic interface" - Martin Fowler

The application of this design principle is particularly effective in Parsley. While some frameworks are restricted to specific configuration mechanisms, Parsley provides programmatic interfaces for synchronous and asynchronous configuration, and several out-of-the-box implementations. These interfaces provide an extension-point so developers can plug-in their own configuration processors when the need arises.

Configuration Processors

In Parsley, a configuration processor uses some form of configuration data to build up a registry of object definitions. This process is abstracted by the following interfaces:

• ConfigurationProcessor
• AsynConfigurationProcessor

Parsley has a number of standard implementations, including the following two most commonly used:

• ActionScriptConfigurationProcessor
• XmlConfigurationProcessor

The developer manual has a section explaining how to extend the framework with a new configuration processor:

• Custom Configuration Mechanisms

Example: Modular Configuation Processor

There are various reasons to write a custom configuration processor. Perhaps you want to support your own particular configuration files, loaded and processed at runtime. However, these interfaces open up some other doors for more interesting forms of configuration. For example, they can be used to process configuration data from a compiled module.

Consider a large, modular application. Let's say the application consists of a Flex shell application that loads 20 modules, and 10 of these rely on the same set of shared services. It's undesirable to compile these services into the shell application, where they could be inherited by the modules, since the shell should have no knowledge of these lower level details. Instead they could be compiled into a module and the shell application could load that module at start-up, so the services are available for inheritance, but there is no dependency imposed on the shell.

This can be achieved quite simply by writing a new configuration processor, something like this:

package com.adobe
{
     import flash.events.ErrorEvent;
     import flash.events.Event;
     import flash.events.EventDispatcher;

     import mx.events.ModuleEvent;
     import mx.modules.IModuleInfo;
     import mx.modules.ModuleManager;
     import mx.utils.StringUtil;

     import org.spicefactory.parsley.core.builder.AsyncConfigurationProcessor;
     import org.spicefactory.parsley.core.builder.ConfigurationProcessor;
     import org.spicefactory.parsley.core.registry.ObjectDefinitionRegistry;

     public class ModularConfigurationProcessor 
          extends EventDispatcher 
          implements AsyncConfigurationProcessor
     {
          private static const MODULE_LOADING_ERROR : String = 
               "Unable to load the module at URL {0} due to {1}";
          private static const MODULE_INCOMPATIBLE_ERROR : String = 
               "The module doesn't implement the ConfigurationProcessor interface.";

          private var url : String;
          private var module : IModuleInfo;
          private var registry : ObjectDefinitionRegistry;

          public function ModularConfigurationProcessor( url : String )
          {
               this.url = url;
          }

          public function cancel() : void
          {
               module.removeEventListener( ModuleEvent.READY, moduleReadyHandler );
               module.removeEventListener( ModuleEvent.ERROR, moduleErrorHandler );
          }

          public function processConfiguration(
               registry : ObjectDefinitionRegistry ) : void
          {
               this.registry = registry;
               module = ModuleManager.getModule( url );
               module.addEventListener( ModuleEvent.READY, moduleReadyHandler );
               module.addEventListener( ModuleEvent.ERROR, moduleErrorHandler );
               module.load( registry.domain );
          }

          private function moduleReadyHandler( event : ModuleEvent ) : void
          {
               try
               {
                    processConfigurationWithModule();
                    dispatchEvent( new Event( Event.COMPLETE ) );
               }
               catch ( e : Error )
               {
                    dispatchErrorEvent( e.message );
               }

          }

          private function processConfigurationWithModule() : void
          {
               var instance : Object = module.factory.create();

               if ( instance is ConfigurationProcessor )
               {
                    ConfigurationProcessor( instance ).processConfiguration( registry );
               }
               else
               {
                    throw new Error( MODULE_INCOMPATIBLE_ERROR );
               }
          }

          private function moduleErrorHandler( event : ModuleEvent ) : void
          {
               dispatchErrorEvent( MODULE_LOADING_ERROR, url, event.errorText );
          }

          private function dispatchErrorEvent( message : String, ... rest ) : void
          {
               dispatchEvent( new ErrorEvent(
                    ErrorEvent.ERROR,
                    false,
                    false,
                    StringUtil.substitute( message, rest ) );
          }
     }
}

The processor is initialized with the module URL. It loads the module, creates an instance, then checks whether the module itself is a configuration processor. If so, it delegates configuration processing to the module. Here's an example module:

package com.adobe
{
    import mx.modules.ModuleBase;

    import org.spicefactory.parsley.asconfig.processor.ActionScriptConfigurationProcessor;
    import org.spicefactory.parsley.core.builder.ConfigurationProcessor;
    import org.spicefactory.parsley.core.registry.ObjectDefinitionRegistry;

    public class MyModule extends ModuleBase implements ConfigurationProcessor
    {
        public function processConfiguration(
            registry : ObjectDefinitionRegistry ) : void
        {
            new ActionScriptConfigurationProcessor(
                [ MyModuleConfiguration ] ).processConfiguration( registry );
        }
    }
}

Parsley's extension points can be taken a little further by writing a complementary configuration tag:

package com.adobe
{
    public class ModularConfig implements ContextBuilderProcessor 
    {
        public var url : String;

        public function processBuilder( builder : CompositeContextBuilder ) : void 
        {
            builder.addProcessor(
                new ModularConfigurationProcessor( url ) );
        }
    }
}

So now a modular configuration can be easily combined with other forms of Parsley configuration using the usual MXML tags:

  <sf:ContextBuilder>
     <sf:FlexConfig type="{ MyShellApplicationConfig }"/>
     <adobe:ModularConfig url="MyModularConfig.swf"/>
     <adobe:ModularConfig url="MyOtherModularConfig.swf"/>
  </sfConfigBuilder>

  ...

Conclusion

When creating a framework, it is wise to define generic interfaces for configuration processing, so that different formats can be used where appropriate. In many cases programmatic configuration with MXML is the simplest and most desirable option, but there are several valid cases for configuration from XML and other kinds of file (including SWFs) loaded at runtime. The configuration interfaces provided by Parsley satisfy this requirement nicely.

In the meantime, I'll mention again that this content is available via iTunes as a podcast and on Vimeo. On the podcast, I'm catching up slowly with episodes, so it will be a month or so before I can get all of my older content up there.

I'll be busy banging away on all kinds of exciting new things until I can return to this, but if nothing else, know that my heart is in this and I am going to continue to post content as often as I can. Wish me the best in clearing my calendar!

Cheers, Dennis </dennis/>

Adobe Beginner Classes

Apple是如此描述Flash：能夠跨平台及跨瀏覽器且立即部署豐富的網站內容標準。

可是這樣的遺漏卻發生在iPhone及iPad，當Steve Jobs正眉飛色舞的展示iPad如何炫麗的瀏覽網頁時卻發現原本應該秀出Flash內容的地方成為一處空白。

為什麼？"因為Apple不想要它在這兒",Adrian Ludwig,Flash platform的Group Manager如此說。

這是真的嗎？

"這不是錢或者是技術的因素，在其他相似的裝置上我們已經成功讓Flash在上面跑，而且免費授權給製造商"。Ludwig描述著。

Apple目前的應用程式商店適用於iPhone當然也包括iPad，而防止其他類似的免費應用程式經由Flash進來打亂其佈局，當然它的app無法跨平台，而這是Flash所能做到的。

目前有個變通方式是會有個轉檔工具把Flash轉成iPhone app的格式，不過Apple畢竟還是有權利對這樣的應用程式是否上架做決定。

而針對這樣的變局，Apple也併購了一家專做線上行動廣告的公司，想要取代原本Flash在這塊市場上的應用。不過Apple在iPad上的策略有點在砸自己的腳，畢竟使用者可以忍受iPhone無法秀Flash，但在可以順暢的瀏覽網頁為主軸的iPad上，如果要在有85%的網站上都使用Flash的情況下宣稱自己是對網站友善，這就有些站不住腳。

除非等到Apple願意改變心意，短期內你還是會看到很多缺著Flash的網頁！

引用於: http://www.nbcbayarea.com/news/local-beat/Why-Doesnt-the-iPad-Do-Flash-82967272.html

All the links in the slide set are active in the downloadable PDF.

You can download the slides directly from the link below, or preview the slides in the Acrobat.com window.

Acrobat_9_Healthcare.pdf (620K PDF)

For more on load-testing LiveCycle Workspace ES applications, see here.