XPComponents and Flux

Someone suggested that with so much happening in the Flash world at the moment I should talk about the future direction of XPComponents.

This basically means talking about Flux!

Flux is the code name for a project we are currently working on.

Flux stands for a FLash User interface defined in Xml.

Might sound similar to Flex, I mean that’s Flash and XML right? True, they are similar products but I would describe them as siblings i.e. related but not competitors. Flux differs most significantly from Flex in that Flux is compiled at run time whereas Flex is compiled at author time, additionally all code behind in Flux is contained in actionscript class files not in scriptlets in the XML. I see both approaches as having there advantages and disadvantages, some situations will be best suited to Flex but I believabe others will be better served by Flux, I don't really see that there will be much overlap.

A typical Flux application consist of several precompiled libraries containing the XP3 component framework, plus your application specific code library and an xml file containing the definition of the overall application structure and screen definitions.

It will be possible for an application to be made up of more than one custom library/XML i.e. to have a Form or a group of Forms in a separate library and a separate XML file so that it will be possible to share Forms across different applications without needing to have the Form compiled into your application.

Much of the power of Flux comes from leverageing the existing capabilities of the XP3 framework with its layout managers, data binding, forms and application architecture.

The typical workflow that we imagine with Flux will be to create your application class files in Eclipse (i.e. ASDT, Zorn, or PowerFlasher), at the same time define your UI in XML, then compile your actionscript using MTASC, copy the compiled files plus XML to server and run.

The idea is basically similar to how you would handle a JSP or HTML application today, the interface is defined in an xml file then rendered at run time when a form is requested. Your own code behind will then exist in a compiled library and will be loaded and associated with the interface as it is rendered. The XML file will be modifiable after the application is compiled i.e. after being deployed, making simple layout changes trivial.

The foot print of Flux applications is generally very small, each Form will only be a few kb maybe in the region of 1 or 2 kb (obviously dependent on the amount of code you write) plus a few hundred bytes for the xml UI definition. The XP3 system libraries obviously are larger than this but then they will be cached on the client so they will only be needed to download once rather than with every application or Form.

Ultimately we hope to have a Flux Form designer that can be integrated with Eclipse though this currently has a low priority and wont be in Flux 1.0 .

Flux is currently under development, we don’t yet have a planned launch date but it will probably be sometime in October.

XPComponents will still continue to be targeted at both Flash IDE and Eclipse development, Flux will probably be sold as an add-on product that will targeted primarily for Eclipse based development.

For anyone interested in XPCharting, we have plans for substantial development of the charting package once we get our hands on Flash8. We are hoping that the improved graphic capabilities of Flash8 will provide the basis for major enhancements particular in user interactivity as well as improved rendering making more complex charts practical.