Building multimarket applications with Gugga Flash Framework.

[sotirov....@gmail.com]

We have posted a new article in the GuggaFF blog about 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.

http://www.gugga.com/flashblog/index.html

[peper]

The idea of declarative creation of sections structure is great. I
think I'll look at it closer. On the other hand sometimes we meet some
non-standard requirements, so it should be possible to combine the XML
style with standard style.

I was thinking about making some code generation software based on
Valocity to generarte Sections, subsections etc. classes, navigation
code, and some jsfl script to create standard movie clip structure
wireframe with properly set linkage.

As to multilingual contents - I made some reasearch.
I was using standard "Strings" panel but combinig it with share
libraries was very difficult, and a bit advanced sites were compiling
up to 10 minutes on core duo!
I decided to create similiar but more flexible mechanism :

1. There is a LangManager - central class, which does the trick :D
2. Abstract LangClients are registered to lang manager - the simpler
is TextFieldLangClient. Lang client has getId, setId, getTextm setText
methods.
3. On the other "end" LangManager uses LangProvider - abstract class
which provides the strings. There can be DatabaseLangProvider,
XMLLangProvider and simple StaticLangProvider with hardcoded strings.

Of course it makes sens for providing some not-content texts -
navigation elements, titles etc. Contents are provided by CMS via f.e.
AMFPHP and it's a standard solution.

The problem is, that every TextField have to be registered in AS:

LangManager.addTextField(txt1,"txt1");

I'm thinking about making a kind of Strings Panel to Flash IDE (it can
generate some code) or using flash.Locale class - maybe extending it.

What do You think ? Maybe we cn join our efforts ?

[Branimir Angelov]

The code generation idea sound very interesting and we will appreciate
if you create a new thread for this and give more detailed information
about it.

About the multilingual content, your flexible modification on the
approach introduced by mx framework is very good solution. Now we want
to introduce one more technique, which comes directly from one of the
main ideas behind the section abstraction - each section should follow
the rule for logical encapsulation. So one very simple, but also a
powerful solution is to externalize the section's data and abstract it
by data object. Then each section relies on its data manager to provide
it with the appropriately localized data. On the other hand the data
manger is responsible for feeding and combining localized data from web
service, XML, or some other service and constructing the expected
section data object.

Let's take a look at one simple example. If we put the section's
'static' data (ex. data which doesn't come from CMS) in a separate XML
file for each section, we can simply organize these XML files in
'localized' folder structure (ex. resources/{language}/data/home.xml
which holds the 'static' data for the Home section). So the Home
section's data manager loads and parses home.xml file for the current
language, combines it with 'dynamic' data from other services (ex. the
web service of the CMS), constructs the Home section's data object and
then passes it to the Home section. This approach is very flexible
because we can combine 'static' and 'dynamic' data transparently for the
section. The organization and separation of the 'static' data (in
separate xml files) makes this solution very scalable and maintainable.
This technique is also very useful when we have to generate an
accessible HTML version of the site because we can use simple XSLT
transformations for that.

We can combine this approach with a module called Global Literals
Manager which is accessible from every class in the application, and it
is responsible for handling the localization of all literals which are
common for the site. (ex. 'previous' and 'next' labels if we have a
paging component).

We will try to give more detailed explanation for this localization
technique in some of the next posts in our blog.

Sincerely
Branimir, Gugga Team