The Flex Team’s Component Plans

There have been requests for public guidance on what components Adobe will be releasing in the future, especially since there are developers who would like to make or extend components on their own without then having Adobe duplicate their efforts. In that spirit we’d like to share our current thinking.

Note that these are forward-looking statements and therefore subject to change, but best represent our plans at the moment. The primary component areas we are focusing on include:

  • Enhancing the List-based components by adding functionality common to data grids and trees in other component libraries
  • Making enhancements to the existing Charting components (and their core framework), with a focus on expanding the API to afford greater control over axes, skinning, data hints, and other decorations.
  • Investigating new types of navigators in order to provide a best of breed solution for organizing information and processes.
  • Including some of the specialized text fields now available on the Exchange (e.g., autocomplete and masked input)

While there are many opportunities for both free and commercial components, there are several areas where we would particularly welcome community contribution, including:

  • Specialized components that address a particular UI need, such as a drawing surface
  • Components that provide better I18N support than is currently available in the core component library (e.g., the DateChooser/DateField controls)
  • Contributions to the scheduling framework currently posted on Labs
  • Utility libraries, adding to what is already available in as3corelib (http://code.google.com/p/as3corelib/); e.g., an XPath implementation building on top of the AS3 XML class that supports the W3C spec
  • Themes
  • Sample applications that demonstrate one or more concepts (big or small)
  • Flex Cookbook entries (http://www.adobe.com/go/flex_cookbook)

On a related note, we do intend to incorporate the recently released Ant tasks for the Flex Compiler and the Flex Compiler Shell into the SDK at some point in the future.

We hope that this helps clarify our plans. If you would like to double-check with us before beginning a new component or enhancing an existing one you can feel free to email Matt Chotin. With that said, in keeping inquiries confidential we will not be able to share whether we know if another party is already working on the same or similar component. We encourage you to use the public mailing lists and forums to investigate whether an investment in a particular component would be worthwhile.

Stay tuned for even more news on how Adobe intends to provide insight into future versions of Flex!

8 Responses to The Flex Team’s Component Plans

  1. takeyo says:

    I want to see a healthy set of Collections like java Collections API.

  2. The one thing I would like to beg for:Let’s eliminate the use of private variables within the framework components and just use mx_internal. I realize that the private vars are there because you don’t want us mucking about with these pieces; however, mx_internal still implies a ‘use at your own risk as this may change’ attitude without preventing the extension of certain components or causing some of us to come up with horribly ugly work-arounds.Right now, we are almost doubling the code size of our component library because it requires so much duplication of the Adobe framework code.Thanks,ML

  3. Mitch says:

    > I know an Object is a HashMap, but what if I want an object as the key?The flash.utils.Dictionary class does this doesn’t it? But I agree that more collections would be useful. I am definitely spoiled by the generic collections in .NET too 🙂

  4. Jonathan Bishop says:

    I would like to see a robust set of Collections like the java Collections API. I have implemented my own HashMap, but I’d like it to be supported at the API level. I know an Object is a HashMap, but what if I want an object as the key?I’d also like to see the eval() method come back or an equivalent. I’m still discovering what AS3 reflection can do.I would also like to see bug/kludge-free components be a top priority.-JB

  5. PaulH says:

    need more locale resources ‘someplace’. i’d love to see flex have the same locale resources as java (well better, i would like to suggest icu4j instead of core java) but frankly i wouldn’t where to put them. player? sdk? something serverside like cf?anyway more better i18n is always welcome 🙂

  6. Doug McCune says:

    It was mentioned at the “Meet the Flex team” event in SF that there are plans to distribute the framework classes separately, so they wouldn’t be included in the player but they would be cached on the client. If the client machine has viewed a Flex app with the normal framework component set, then it would download the component set once, then when your Flex app loads it would only load the new assets. I don’t know how close on the horizon this is, it seemed a ways off, maybe Flex 3 release?This is just my unofficial reporting of what was said at the event in SF.

  7. Phillip Kerman says:

    What is the current thinking about integrating the components into the player? Is it just so far “out there” for now or something that will never be considered?

  8. Chris Velevitch says:

    Why the distinction of “Flex” components? Does this mean the Flash 9 components aren’t the same as the “Flex” components? It erks me to see different sets of components based the the tools you use. Since both Flex and Flash target the same virtual machine, then the “components” are one in the same reguardless of which tool you use.