A whole class of RIA applications is getting judiciously ignored by technology vendors like Adobe and Microsoft with the argument that these are way too custom to be utilized in any direction. In the recent years both vendors were focusing their efforts on streamlining the enterprise RIAs, both neglecting the class of applications that was previously the predominant type of RIA. I’m talking about marketing platform applications or Rich User Experiences that are not focused on providing a particular business function. Such applications most typically are not extensively using common UI controls and usually they don’t have to deal with visualizing and manipulating large sets of data in grids and charts.
Adobe have done a great job with Flex (and in the years to come it will hopefully improve)! But Flex comes with a certain weight that makes it nearly impossible to use when we have to develop the class of applications that I want to stress on. The overhead of the framework is too big to be ignored. Our main concern is that this will eventually result in poorer user experiences, because of initial download times. But even if we circumvent this issue in some way (check my article on Totally Custom Preloaders), the SWF will still include code dependencies that are used nowhere in the application. Not to mention that the whole component model is too heavy and complicated and will eventually stand in our way when we have to implement a totally custom experience.
Introducing FLit
But on the other hand Flex comes with a set of tools and concept that we really love and still want to be able to use. So what we end up doing in our free time in Obecto is a framework that would enable us to use Flex for really custom Flash apps with a minimal overhead from the framework. And we called this framework FLit - a light-weight Flex for Flash apps. We’ve developing it open source from line 1 - so feel free to check out the source from Google Code. There you’ll find some samples too!
Why we call it FLit?
First, FL stands for Flash. We want to build plain AS3 projects without the need to use <mx:Application> as a root object for our apps, and we want it to be as fast and as small as a plain AS3 project could be.
How do we use Flex in FLit?
As you might guess FL also stands for Flex, but we only use a small subset of the Flex Framework, like Data Binding and MXML, and nothing else - no UIComponent, no Flex Application. How do we succeed in using MXML inside of a plain AS3 project? Well, this is a topic for another post.
We are also using a concept pretty close to the view contract in Spark, thus enabling the separation of concerns between the designer and the developer.
What do we mean by lite?
We understand liteness as to have minimum dependencies between components, thus there are no components in the framework that will induce as dependencies a substantial part of the framework itself.
We understand liteness as the ability to include only those concern that interest you and not some behavior hard-coded in the framework.
We also understand liteness as having a lite build process. Previously when building custom Flash apps we needed to use the designer machine and the designer productivity tools for the build. With FLit this is not the case - the designer is responsible only in preparing assets that must contain the parts specified in the view contract, so the productivity tools are not used for the build. So, this is also a pretty lite skinning process.
The current state of FLit
FLit is in early experimentation phase. Maybe this sample somewhat summarizes what’s inside the framework now? You can also check out the sample’s code!
A summary of features:
● light-weight base component
● light-weight base container
● view contract specification through metadata tags
● skin asset
● several layout strategies
● transition manager that supports declarative transitions between states
● tasks (an idea which originated from the GuggaFF) - Sequence and Parallel are also tasks
● declarative input validators
● skin-able button component
● tweening engine
9 Comments
Pretty cool idea. I am developing a project called Digizex, which is an open-source CMS for Flex and Flash, but at its core it is really just an elegant and lite-weight way of combining Flash and Flex.
My thought is that for web apps, flex is too heavy for most of the site. However, you may wish to provide the user a path to enter flex-heavy parts of the site while maintaining a fluid interface. With Digizex, entering the CMS means loading Flex at runtime, and this provides a wysiwyg cms interface whether your main app is CS3, AS3, or Flex-Based.
http://code.google.com/p/digizex/
Hi, Gil,
Thanks for the reply! I really like the concept of build-in content management - it somewhat makes more sense to edit the content as you see it.
Have you considered an interaction similar to this one?
In FLit I do not pose the question of how to combine Flash and Flex in the way you do it with Digizex - if I need to use some forms and screens with Flex controls, I’ll just load a Flex SWF into my FLit app.
Off course there could be all sorts of side effects. I’m curious did you ran in such cases, like e.g. you’re loading your Flex app into a container that’s inside a larger container and when your Flex content opens a pop-up, does the disable cover covers the whole stage or just the area of the container in which you’ve loaded the Flex SWF? How’s positioning working in such situations?
Can you link me to the fragment of the code which loads the Digizex module inside the Flash app?
Vladimir, thanks for the CMSBox link, I haven’t seen that before. But no, Digizex is a different premise than CMSBox. Digizex is built for Flash/Flex Developers who already have their own workflow, whereas CMSBox looks like it’s for the average user who is creating somewhat generic sites (plz correct me if I’m wrong). The Digizex’s CMS solves the following problem: Do you have a database-driven SWF for which you need content management, but you don’t want to write your own code for user management, authentication, and then have to deal with how to integrate that CMS into your SWF?
You’re correct about there being issues with Flash/Flex container sizes. I have not tried to address these issues yet, but for a CMS specifically, it doesn’t matter much…. When loading Flex at runtime into an AS3 core, the flex container covers (either fully or partially) the underlying AS3 containers. Digizex detects when all popups have closed and hides the Flex container as needed.
The Digizex class is compiled with your main SWF and loads the Digizex Shell (when the hotkey is detected):
http://code.google.com/p/digizex/source/browse/trunk/src/com/digizex/Digizex.as
When the shell is loaded, CmsStageManager (which is part of the Digizex shell) handles mouse-overs for any component that needs to be CMS managed
http://code.google.com/p/digizex/source/browse/trunk/src/com/digizex/shell/view/components/CmsStageManager.as
And the CmsStageMediator (also part of the Digizex shell) handles loading of Digizex Modules
http://code.google.com/p/digizex/source/browse/trunk/src/com/digizex/shell/view/CmsStageMediator.as
Loading the Digizex Shell does create a Flex container, but that container remains hidden until a Digizex module creates a popup window.
Just wanted to add one more thing — doesn’t FLit do what CS4 should have done to replace CS3’s .fla file? MXML doesn’t have to be heavy and you’ve proved it.
You’re right in a way! MXML doesn’t have to be heavy - and this must somewhat affect Flash Catalyst in the direction in which with it you would be able to produce either Flash or Flex apps depending on the requirements.
I see the MXML as the connection link in the designer-developer work-flow. I think Adobe see it in the same way too, but still they had not the time to provide a more light-weight framework - so in the current state of affairs, if you want MXML you gotta use also a Flex Application. This is the issue FLit tries to solve.
But Flash CS4 is moving back towards an animation tool instead of being a mixed tool for creating applications and all kinds of Flash Content. So I agree the FLA file makes no sense for application development, but probably it still makes sense for plain Flash content, such as heavy timeline animations.
One more thing - Gil, thanks to the links!
You’re right about CMSBox - it doesn’t just manage content but also rearrange it and produce to an extend of being a development tool. So, I agree with you on that!
I can’t get your form example to run in FB4. First, it doesn’t like the name “states” on TransitionManager. Then, topLevelSprite seems to be missing. Any help?
It is pretty straight-forward to get the samples running (but I’ve done this only in Eclipse with the Flex Builder 3 plugin):
1. Install the Subclipse plugin.
2. Open the SVN Repository Explorer perspective.
3. Add the FLit Repository - use the information in the FLit Google Code page.
4. Expand the trunk - there you’ll find the flit, sampleComponents and the samples directories.
5. Right click on flit and choose Import… - follow the steps in the wizard to add the framework library project to your workspace.
6. Right click on sampleComponents and choose Import… - follow the steps in the wizard to add the sample components library project to your workspace. (You need a library project to use MXML inside - in a plain AS3 project the use of MXML gives a compilation error).
7. Right click on samples and choose Import… - follow the steps in the wizard to add the samples AS3 project to your workspace. This project contains only the Application files which are the entry point to the FLit applications.
Thanks for trying FLit!
Incoming Links
Leave a Reply