Summary
We've been working on an XML syntax for generating compositions of rich UI components from web apps, rendering them in the ubiquitous Flash VM, and binding them to remote data and services. Previously code-named Royale, it enters beta with the official product name "Macromedia Flex."
Advertisement
I have a confession to make: I completely believe in the benefits of Rich Internet Applications, whether Flash-based or not, but I want to develop them differently than my own company has previously allowed. I personally dislike developing in the Flash authoring tool. Now, I think my friends on that team have done a brilliant job at building for the designer/scripter community, but that community doesn't really include me. I personally don't use the Flash timeline, I'm not much of a visual designer, and I don't quite get some of the APIs and terminology (like using the "stage" to develop "movies").
Enter Flex.
Developed in your favorite IDE (or in our DreamWeaver-based visual editing tool, as you might expect) and deployed into a Java web tier (a .NET version is also likely), the resulting rich clients are rendered in our ubiquitous Flash VM. The client-side components might take advantage of client-side storage, client-side validation and the like. But they also might bind simply and directly to remote web services, remote Java constructs (JavaBeans such as Struts models, for example, or even EJBs), or to REST-based resources such as XML files delivered over HTTP. The syntax currently referred to as MXML simplifies all of this. By the way, I have a feeling the product managers aren't done renaming things yet so if the syntax is named differently in a final release, remembering I told you it was originally 'MXML' may eventually win you some geek trivia contests.
The Syntax
Want to use this syntax to generate a rich, smart datagrid amid your otherwise JSP-based web app? Can do, our syntax is happy inside or alongside JSP.
Want to use some SVG inside MXML? Sure, go right ahead.
Want to style some of the components using CSS? Sure thing, go to it.
Want to add logic that can't be accommodated in standard XML, some client-side glue code that you don't really need in a full-blown remote Java service? How about using simple script -- JavaScript, actually, but with support for ECMAScript classes should you need it (for better or worse we call this ActionScript).
Want to bind to an existing Struts JavaBean-based data model? Go ahead.
Want to bind to a set of SOAP-based web service inputs and outputs? Very easy, services are first-class citizens at the highest level of the syntax.
Want to create the UI components themselves in Flex? Ok, you can use simple script to do so.
Want to keep using Flash MX authoring, or continue working with creative designers who use Flash authoring? Sure, you can use the components that these folks whip up.
Want to use Eclipse, or IntelliJ, or emacs to craft your rich apps? Go right ahead. Since the syntax is schema-based, you'll also get smart editing in some of your favorite non-Macromedia development tools.
Courting the Comparisons
Comparisons might reasonably be made to XAML and to XUL. XAML links CLR-based types in a way similar to our linkage of script-based classes and rich components, and XUL is a great way to arrange components, style them using CSS, and handle events using script within a Mozilla container.
XAML and MXML diverge from XUL in supporting a fairly different services model and data model (XUL goes with RDF in extensive and sophisticated ways, whereas we try to stick with XML Schema), rendering to a vector graphics layer to abstract hardware and other dependencies, and not requiring the deployment of a container like Mozilla (although I guess XAML might require an even larger container -- Longhorn). We also allow the creation of new components by developers using script and by designers using our Flash authoring tool, and I think that XUL component creation requires use of XPCOM. Some of the UI syntax is very similar, but it would be wrong of us to pretend this is literally XUL when that's the only deep similarity.
XUL and MXML diverge from XAML in that we can be cross-platform, deploy even to pre-Longhorn Windows systems, and are very web-centric; XAML targeting Avalon appears to be aimed primarily at desktop applications -- this suggested by Chris Anderson, a Microsoft architect whose blog I enjoy. If it's primarily for desktop apps, I interpret it as an intended replacement for .NET Windows Forms. I didn't hear much about XAML and Avalon for web applications, and talk of the browser was mostly absent from Microsoft's PDC. But despite the real need for a smarter client (Central, anyone?) I don't think cross-platform browser-based web apps are likely to die any time soon, so it's a good thing that you can get the richness within a browser.
In future entries I hope to dig down deeper into the Flex syntax and runtime services, and take a look at how it compares to similar options. It seems to me that we could have bent over backwards to extend XAML or XUL to a similar end, but I'm not sure doing so would produce exactly what developers want: a simple way to produce cross-platform, rich and smart, service-oriented clients that can be managed within existing server-side infrastructure and target an existing ubiquitous client.
It will be interesting, though, to hear if I'm wrong and we should make more use of XAML or XUL. I'm an engineer, and don't speak for my company here on these pages, and don't have a stake in any religious battles. I am interested in hearing genuine technical feedback, though, that suggest changes we ought to make or stupid things we ought to fix. Macromedia is not a small company, and not everyone "gets it" in the same way, so whether obscenely offended or quietly constructive, please make sure we're getting it with Flex.
On the one hand, I don't think there is enough prior art to worry about compatibility. There are not enough XUL developers, for example, who want to leverage XUL skills in Flex.
On the other hand, since XUL is so similar, it makes sense to adopt a subset of XUL, thereby making XUL the free version of Flex. One of the things holding Macromedia back is the pay-wall between users and developers. You can't experiment with, or dabble in Flash without spending hundreds of dollars. If a significant subset of XUL was portable to Flex, then Macromedia could say: "Look, go prototype and play with XUL. Then, when you want all the bells and whistles, pay for Flex."
Thank you for the info, I have checked the source code samples but couldn't find hints on the use of SVG in Flex. Does Flex support multiple namespace documents? Is SVG (or a subset of SVG) is represented in its own namespace in an MXML file? If multiple namespaces is supported, is it likely to have third party tags for supporting other xml grammars (such as MathML)? I understand that there will be an xml based alternative to CSS2, which looks similar to the styling tags used in XAML. This would facilitate the programmatic generation of MXML files. If I am not wrong, there can be two ways to develop UI components, one using the Flash IDE and one using code editors (bypassing totally the Flash IDE). The second approach looks quite promising. Hopefully, there will be a developer's edition of Flex. Regards,
Thanks for your input, it's appreciated. While no official pricing for Flex has been announced, I'm a proponent of developer and academic editions (not just trials) that might be available without hitting the pay-wall you refer to, so that developers can continue working and experimenting indefinitely. Sounds like this might be something that would suit you, so Macromedia product managers take note...
You are correct, you can develop the UI components in either Flex (using MXML) and bypass the Flash IDE altogether, or you can create components in the Flash IDE and then use them in Flex if you like.
As far as SVG goes, we can support inline SVG using multiple namespaces, but when we did so some usability issues surfaced in the language. So in the beta version, SVG is imported from an external file by way of attribute references, and not dropped into the MXML directly. We may not resolve the language usability issues for the first release of Flex, so inline SVG might not be available until a subsequent release. We're trying to be extremely careful to get the MXML app model right rather than just drop a bunch of existing syntaxes into a new syntax; but that said, SVG still has an important role in the new model.
I will post some samples, including some that make use of SVG, in the next few days.
I've enjoyed watching the buzz that has surrounded Macromedia Flex since it's recent announcement. The product is going to fill a significant gap in the enterprise web application developer's tool box.
However, I'd like to know if Macromedia has any plans to publish a specification for the the Flex Presentation Server and allow for competition from other vendors in this space and perhaps even an open-source reference implementation.
I'm guessing that such plans are not in the works. I'm wondering how willing the current J2EE community is going to be to adopting a solution that ties them to one vendor. Given your involvement in the JCP and in the development of Macromedia's JRun product, I'm sure that you're very well acquainted with the fact that the notion of being able to deploy a J2EE web app on Tomcat/WebSphere/WebLogic/JRun/Resin/"you-name-it" is a religious tenent held near and dear to the hearts of J2EE enterprise developers. How does Macromedia plan to convince them to surrender their freedom of choice and adopt a single-vendor solution? I believe this model will be met with much less resistance in the .NET community, but J2EE enterprise developers are going to be a much harder sell.
There is precedent for Macromedia opening up the field to other vendors (opening the SWF format, resulting in the now defunct Adobe LiveMotion product). Perhaps this is something Macromedia may want to consider in order to create wider adoption and push Flex into the mainstream of J2EE enterprise development?
This is a good topic, one that has come up internally much more often lately, which I view as a good thing. While this is a little vague, I guess I'd say that I see real momentum toward this at an appropriately high strategic and business level internally -- and I write this as someone who is usually extremely skeptical about a commercial software business person's grasp of standardization and openness.
Just to be sure we're on the same page about what we're talking about, particularly with regard to vendor lock-in:
Flex is intended to be deployed into any servlet engine (Tomcat, WebSphere, etc.) and into ASP.NET as well, and it needn't be developed with our tools; Eclipse, IntelliJ, emacs, etc, can be used instead. Since we will continue to document the SWF format it will be possible for folks to create their own compilers and even runtimes for it, as they do today, in both open source and commercial organizations. It's issues with regard to the openness of Flash Player VM itself, and of standardization of things like MXML that are more of an issue with Flex. Since MXML is ECMAScript, it is standards-based, but the new declarative syntax on the whole is another issue. And opening up the player itself is an even more sensitive and thorny issue.
We are discussing steps we can take to help customers avoid the lock-in to Macromedia, and discussing how best to pursue openness and stadnardization with regard to our technologies. We engineers certainly believe in this, and I think that layer of executive management which ultimately makes the decisions regarding these things have become much more interested in openness and standardization than they have been here historically. Too, partnerships with companies like IBM (who has been working with us on Flex) help steer us wisely with regard to standards. It's true we have opened up the SWF format, but that's not quite enough in my opinion, and I think it's perfectly reasonable for us all to expect more.
Previous Topic
