Amid the talk about Macromedia Flex, several questions seem to be recurring. I'll offer quick and unofficial thoughts on five of them: how it relates to DHTML, XUL, SVG, JSF, and our existing Flash MX tool.
Disclaimer you will probably ignore:
I'm a software architect not a product manager, which means I write code and not marketing messages. My responses shouldn't be taken as any sort of official word from Macromedia. I'm just talking engineer-to-engineer here, rambling over a couple of virtual beers on Artima rather than offering official word from macromedia.com.
Regarding DHTML and Flex:
I agree that DHTML can be used to great effect, and over the years we've spent a good deal of time supporting and simplifying it in products like DreamWeaver. While Flex initially publishes only to the Flash VM, it's really about providing an app development model with the right service and data orientation for developers of server pages and templates to write, test, deploy and manage rich apps today. In my opinion, it's about getting the model and services right and not about pushing Flash itself (or any other client platform) as the be-all end-all.
That said, I do believe that Flash provides the only ubiquitous lightweight cross-platform client VM that can support the sorts of web clients we're wanting immediately -- not just for its rich vector graphic visuals and audio/video, but for sophisticated offline storage and push applications as well. That says nothing about what Flex may eventually target as a result of customer requests and requirements, though, nor does it speak to what the Flash VM itself may evolve into.
My own opinion is that we wouldn't be doing justice to the XUL community if we called our syntax by that name, because even aside from the runtime container differences it differs so significantly in its service, component, and data models. But...
If you think only about the syntax and not the rendering and compositing, though, and eliminate data binding and tag-based custom component creation, I think the base Flex UI syntax is very similar to that of XUL. This is a good thing because I personally like that portion of XUL, and I'd certainly be interested in figuring out how we could give back to the XUL community, or if despite the other differences a lot of folks really do view this as a version of XUL and want that name applied in some extended form. For some years I managed an open source project on sourceforge (something called PoolMan) and have contributed to many others, and I certainly believe everyone wins when folks give back where appropriate and where welcomed. It's not always possible seeing as how I work for a commercial software business, but I am willing to fight the fight where necessary and if it's really justified.
Regarding use of SVG:
SVG is supported in MXML, and at the very least in version 1.0 you'll be able to reference external SVG files. Inline SVG, however, is not guaranteed to be available. We can support multiple namespaces for MXML and SVG in the same document, but it posed language usability issues, so for the current beta this has been disabled.
Peter Farland, who worked with me on creating the Flash Remoting product (my first foray into Flash product development after developing the JRun 4 J2EE 1.3 server) is the engineer handling the SVG features. Pete was basically asked to implement a specific subset of SVG, but he found that distasteful so he pretty much implemented everything. It's great to be in an engineer-driven place, particularly when the engineers are so talented. Anyway, I wandered down the hall and asked for his response to the question. Here's Pete's word on the subject (imagine this spoken in an Australian accent): "The inline SVG feature has been disabled until language specific usability issues are sorted out. This is not guaranteed to be ready in 1.0. You can reference external SVG files for any Property attributed with [ImportResource], such as Image's src property."
Regarding use of Flash MX:
If you or your collaborators do use the Flash authoring environment you can still do so and export components you create into Flex. We also have a new DreamWeaver-like tool for visual Flex authoring. And you can continue using your ActionScript, both in Flex and in our classic tools. Flex gives you a simpler, smarter way to use MX components in an enterprise application. It's easier to link them to web services, easier to bind data to them, easier to create navigational flows through them, easier to unit test them, easier to share them through source control, easier to dynamically generate them, etc.
Flex makes it easier to quickly build robust rich apps without requiring a good deal of time and designer skill, and without requiring knowledge of the proprietary APIs Macromedia has previously released. It's standards-based and familiar to folks who've used server page or template frameworks in the web tier, and in the hands of wise web developers it produces behaviors that can be pretty incredible.
Regarding JavaServer Faces:
This past summer I spoke at a conference where I demo'd JavaServer Faces with a Flash JSF renderkit rendering a Flash-based rich datagrid in a page that was otherwise rendered with HTML form widgets. All were produced from a single JSF page using JSF tags. The Flash datagrid and the other widgets shared the same JavaBean data model -- the same server-side instance of the bean, actually. Flash can work with JSF. But Flex is not JSF, and they don't aim to address exactly the same goals.
JSF seems to be mostly about simplifying Model 2 MVC development for JSP applications. There's nothing specifically about web service bindings and the like but more importantly -- there's not much about smart clients. At best there is a delegated rendering model that might be exploited to supply client-side storage and client-side logic. But mostly the classic JSP model is assumed and simplified. I don't think this is an oversight by JSF, I think it's evidence that we're going after slightly different goals.
More deserves to be said of JSF, but this will have to suffice for now. As always, interested in feedback: If you're a JSF fan, please give me a yell.
I work for a Window & Door manufacturer who wants to provide a RIA product configurator out through a browser. With literally millions of product permutations, we've built our current Desktop configurator upon AMZI Prolog rule sets, VB, and an Access DB. Management desperately wants to go browser-based with the configurator, but DHTML isn't up to the task, and I've shaken with fear trying to introduce our hard core developers to the peculiarities of Flash MX.
So Flex looks great to me and possibly provides solutions for any number of problems, but we have one last irritating requirement...with many of our dealers existing in what I would deem the stone age, we also have to supply a "stand alone" or "disconnected" version of the configurator. Would we be able to distribute JRun (or another J2EEE server), our rule sets (or db) along with Flex and install it at the client so they don't HAVE to hit our servers? (I know I know we're defeating the the entire point of the 'net, but this requirement is written in stone...)
I heard mention of "disconnected" capabilities early on in one of Macromedia's Flex presentations, but it was not reffered to again, and when I called Macromedia, I was referred to the Beta program. That isn't much help, I want to be read about capabilities, not figure them out myself....any suggestions? Any insights?
As far as offline storage of data goes, I can think of a couple of options.
If you want the app to run in a browser, and if by offline you're referring to offline usage of a web browser, then you could use Flex to create UI consisting of components that read/write to a local storage facility. Your components would run in the browser, possibly cached while offline. The components access the local storage facility even while offline according to the scripts and events you have coded in Flex.
If you'd rather have your client run outside of a browser but still have it deployed through the web, then you might target something like Central, which has a more sophisticated offline storage facility than that which is available to Flash in a browser. Word of caution, though: developing Central applications currently requires usage of the Flash authoring tool, as Central 1.0 has not been updated to receive components generated by the Flex beta. I'm not sure whether we'll have the Central-Flex relationship completely hammered out in 1.0 versions, so my advice would be to pursue the first option if you're (understandably) averse to introducing engineers to the Flash IDE's eccentricities.
Would be interested to hear how it goes. If you do spend some time investigating Flex for the project, please drop me a note either here or on the Flex beta forum; a lot of us would be interested in your feedback.
One of the things that encouraged me to go with mozilla was xpcom: if i needed to write a component to capture (or exchange) data from a barcode scanner or card reader or firewire camera or straight to/from reiserfs, it was fairly simple, and fairly cross-platform.
How would Flex handle such client-side, (sometimes needed to be) cross platform plugin handling?
I'm basically assuming it won't, and trying to insure/pray/plead that 2way communication between browser and plugin works real well by flex ship.
This is a good question. I can imagine a way to do this via the shared datasource pattern, in which the device writes the data to the local object store to which Flash components are bound. This would require a library utility to handle the writing, but that's not a terribly difficult thing to build, as the Flash object store is file-backed, so a low-tech option is merely to write the data to the file in the format required. Rich components would then be able to pick up the data.
We need to think more about how best to support this sort of use case in Flex. Thanks for the input.
Could you tell me more about how Flex and JSF (or J2ee in general) can be used together, other than creating some sort of Flex Rendering Kit? Or is that the only way? We have an established J2EE Servlet/JSP architecture, will probably move to JSF. We have a few additional "rich client" requirements for our intranet apps that HTML/DHTML can't really satisfy. We use WSAD and I see that there is a Flex plugin in the works. Any comments? PD
I happened to be browsing a Google search on "flex configurators" and ran across your posting.
My name is Tony Baldwin and I am VP Strategic Relations for a company called Ntara www.ntara.com. We are actually in the end stages of developing a Flex-based product configurator that would be ideal for window and door manufacturers. In fact, my I am a former CIO for a window and door manufacturer so I know that market very well.
If you are still looking for this type of solution, please feel free to reach out to me at the contact information provided below. I look forward to your response.
Best regards, Tony Baldwin VP Strategic Alliances Ntara - www.ntara.com email@example.com 678-778-6905 (Mobile)
I am an Java programmer and not too familiar with Flash coding but we use Flash in our software.
Is the Flash JSF renderkit you created avaialble? I presume that it creates an actionscript to call Flash Widget. Is this true? If that is the case, we have to have a set of those Widegets to beging with. Is there one that comes with Flash MX 2004 or do we have to hand craft them first?
Also, I noted that IBM has FlashRenderkit for WebShere but I am not sure where to get it. If you happen to know the library, can you commont on and also tell me where to get it?
I understand your position on XUL however I would be curious to know if Macromedia has considered a way for third party developers to easily add authoring for toolkits like Mozilla XUL into Dreamweaver. The number of XML based GUI toolkits is only going to grow in my estimation, and I think that that would be the best way to give back to open source.
Need 3 Flex engineers in New York City: 1. You have to be living in New York City for now. 2. Work part time or full time with us. 3. Good at Adobe Flex technology. 4. Please contact us for other requirement and details.
Busycode Inc. is a top Adobe Flex shop who develops Flex/AIR applications for clients. For more info, please visit http://www.busycode.com