Adobe Open Source
   Home     Projects     Source     Documentation     Forums    About
Welcome Guest | Sign In
 

Gumbo FxApplication - (Mini) Functional and Design Specification


This is a mini-spec that is undergoing flux currently as more FxApplication design issues are vetted.

Gumbo's FxApplication (mx.components.FxApplication) is an FxContainer designed to be the top-level container for new Gumbo applications. The new class was needed so FxApplication can hold Gumbo graphic elements directly. The new FxApplication class is not feature-complete, and we will be modifying it later on.

Major Differences

From a user's perspective the Gumbo FxApplication should be the same as the Halo Application. Major differences are pointed out below:

  • Top-level graphical elements are allowed since under the hood FxApplication is an FxContainer and all the children go into a Group
  • The default layout is BasicLayout (absolute), not vertical layout
  • To change the layout, instead of using layout="vertical", you have to set the layout property directly:
    <FxApplication>
      <layout><VerticalLayout /></layout>
    </FxApplication>
  • FxApplication is now an FxContainer, which is a FxComponent, so a new Skin can be applied.
  • There is no more application controlBar (it's skinnable!)
  • There is no more creation queue
  • backgroundColor is now a property and not a style. Once we have a proposal for skin styles, this will probably change.
  • Lots of styles are missing and will be added in time.

Unfinished Areas

There are a few unfinished areas that need to be revisited.

  • The compiler needs to be modified to support the new white default background color
  • The compiler modifications needed for the generated class files should be revisited
  • Need to remove the resetHistory and historyManagementEnabled properties and get rid of them
  • Need to revisit places where we do if (x is Application) or Application.application.propertyName and other uses of the old Application.

Usage example

<?xml version="1.0" encoding="utf-8"?>
<FxApplication xmlns="http://ns.adobe.com/mxml/2009"
             backgroundColor="white"
             width="800" height="600">
    <layout>
        <VerticalLayout />
    </layout>
    <Ellipse width="10" height="10" y="3">
        <fill>
            <RadialGradient>
                <GradientEntry color="0xAAAAAA" />
                <GradientEntry color="0x336699" />
            </RadialGradient>
        </fill>
    </Ellipse>
    <Button label="halo button" />
    <FxButton label="gumbo button" />
</FxApplication>

Flex SDK Project
Home
About
Versions
Downloads
Source
Bug Database
Submitting a Patch
Developer Documentation
Forums
License

Pages
Comments

Other Projects
BlazeDS
Cairngorm
Corelib
FlexUnit

More related projects ›
More Adobe projects ›
You must be logged in to comment.

I doubt this is a focus for you guys, but unloading and reloading Flex Applications into non-flex apps (just flash), and loading Flex apps into different application domains are two issues I'd love to be resolved. We develop in Flex, but have clients who want to load our software just from Flash.

Check out the Marshall plan. It's the SDK feature to support cross-versioning and support across multiple ApplicationDomains.

Why is there now a whole new method of styling and new classes? What benefits will this pose for programmers that now have had to convert to an entirely new language and syntax each time you jump to the next version number? (action-script 1, 2, 3 and now 4 are all different)?

At least with previous versions of Flex Building SDK, mxml language remained largely unchanged except for the namespace references (1999, 2002, 2004, 2005, and currently 2006). The only suggestion I had for this was storing the namespace URL in a separate file inside the project so that all the files of a given project would not need to be changed to reflect the new namespace location.

Now, however, with 2009 you not only changed the url, but the syntax as well!

So the real question is: how will companies be able to justify the substantial expense of paying for so many programming hours to have all their 3.0 code ported to the new 4.0? .... and 5.0, 6.0, etc?

 
Last Modified: 2008-11-04 11:32:43.0
Powered by Atlassian Confluence 2.7.1, the Enterprise Wiki.

Company | Online Privacy Policy | Terms of Use | Contact Us | Accessibility | Report Piracy | Permissions & Trademarks

Copyright @ 2008 Adobe Systems Incorporated.
Use of this website signifies your agreement to the Terms of Use and Online Privacy Policy.
Search powered by Google