Building multimarket applications with Gugga Flash Framework.

Creating applications with dynamic structure.

With this new article we would like to offer you a flexible solution for creating a Multimarket-Multilanguage Flash Applications using GuggaFF. We will see how such RIAs can achieve a highly flexible and extensible structure accommodating future changes and updates. Based on our own experience, those kind of applications are usually requested to serve specific business reasons providing customized information to many markets in different languages. Let summarize the requirements for our application

• provide customized information and functionality to more then one market in more then one language


• allow for transparent update of information without the need to recompile the application


• ability to quickly release or disable whole sections of the application during its lifespan


• build and release new markets and languages without jeopardizing the existing functionality and without rewriting the application


• allow for creating Accessible versions of the applications reusing the existing content


• allow for transparent introduction of a content management system to support the application

Sounds familiar ….?
Ok let’s look at the two important aspects of our application that make it so unique as a requirement.

Market
A very common scenario is that different markets involve different structure of the application at the same time there is usually a significant overlap and single section is found among more than one market. Hence, market determines a set of sections with specific structure.
Please, remember that Gugga Flash Framework introduces Sections and SectionsControllers as the building blocks of an application.
Take a look at them, if they are new to you!

Language
Language is usually a function of the content displayed in the site. We will assume that all the content in our application will be external to it and will either be held in static XML files or in a Data Base.

Our goal is to create a single application which supports variable sections structure, in order to represent different markets. We strive to reach the lowest development cost in the long term and preserve high quality on a large scale.

The main architectural problems our solution is faced with are:

• How to define flexible application structure, which also allows transparent creation of new markets?


• How to implement an application which supports variable section structures?

How to define flexible application structure, which also allows transparent creation of new markets

Our best approach in defining the sections structure is to use xml format. It is hierarchical and matches the composite structure of the sections. Its declarative style allows even non-developer to create and control it. More importantly, the xml format brings formal sense to the key abstraction of an application structure. It also ensures that the application is completely abstracted of its current structure. For convenience proposes we will call that xml file structure.xml

Let’s start with declaring the main building block of our application - the section within the structure.xml. We will create a

node which will basically need:

• id – identifier of the section. It will be used in the section paths used by GuggaFF navigation mechanism
  Please, remember that every section within the composite is identified by a dot-notated section path. NavigationCommands are used to navigate section paths.
  


• type – on_stage, lazy_attach or lazy_load depending on that if the section is on the application stage or in the application library or in external swf file. GuggaFF supports all types of sections by registerChildSection, registerLazyAttachSection and registerLazyLoadSection methods of the SectionsController class. The on_stage type of section is not the best approach if we want a flexible solution but in some very special cases (ex. when we want to abstract a block of sections which always go together) we can use it. This kind of sections are opening faster, because they are loaded and initialized in advance.


• instance – For on_stage type of sections.


• symbol_identifier – For lazy_attach type of sections.


• swf_path – For lazy_load type of sections.

Here is a sample node of a generic section declaration:

<section id="Home" symbol_identifier="HomeSection" type="lazy_attach">
<section id=”SubSection” … </section>
</section>
If we could point any drawbacks of this solution, it is that we should have separate structures even for identical markets. But this is a cheap price to be paid!

How to implement an application which supports variable section structures





In GuggaFF every SectionsController registers its child sections. Given that, we need SectionsControllers which accept structure data(coming from structure.xml) which they will use to register their child sections. We will subclass SectionsController and this will bring a new quality to the composite entity – the ability to be created dynamically.

Here is some pseudo code to illustrate the idea.

Interface extension for composite nodes:

interface sections.IBaseSection extends ISection 

{
   public function setStructureData(aData : SectionStructureData) : Void;
}

Subclass of SectionsController to carry out the structure data and register child sections:

class configuration.SectionStructureData 

{
   public var ID : String;
   public var Type : String;

   public var SymbolIdentifier : String;
   public var Swf : String;

   public var Instance : String;
   public var Subsections : Array;

   public var SectionPath : String;
}

Subclass of SectionsController to carry out the structure data and register child sections:

class sections.BaseSectionsController extends SectionsController implements IBaseSection 

{
   public function setStructureData(aData : SectionStructureData) : Void 
   {

      mStructureData = aData;
      
      var subsectionsStructureData : Array = aData.Subsections;

      for (var i : Number = 0; i < subsectionsStructureData.length; i++)
      {

         var data : SectionStructureData = 
            SectionStructureData(subsectionsStructureData[i]);

         
         if(data.Type != "on_stage")
         {
            mSectionLoadersCount++;
            var sectionLoader : ISectionLoader = 
               createSectionLoader(data, "sectionLoader_"  + data.ID + "_" + mSectionLoadersCount);

               
            registerLazySection(sectionLoader, data.ID, true);
         }
         else

         {
            var section : Object = registerChildSection(data.Instance, data.ID);

            IBaseSection(section).setStructureData(data);
         }
         
         mSubsectionsStructureData.add(data.ID, data);
      }
   }

   private function onLazyTargetSectionUIInitialized(ev) : Void 
   {
      var section : IBaseSection = IBaseSection(ev.section);

      var data : SectionStructureData = SectionStructureData(
         mSubsectionsStructureData[mTargetSectionID]);

      section.setStructureData(data);
   }
}

To use the structre functionality of the BaseSectionsController from classes which derives from SectionsController (ex. ApplicationController), we can use the Bridge pattern.

These pseudo-implementations create the foundation of our solution for applications with dynamic structure. Every section which derives from IBaseSection or BaseSectionsController will be of a full value for the application with dynamic structure.

In next postings we will explain additional aspects of the multimarket applications like, strategies for implementing sections and components, skinning and creating accessible version of a flash site build using GuggaFF.