File Upload Using Flex/Central/Java

Inspired by Matt Chotin's recent guest post, I decided to take a moment to document file upload using a Flex application deployed in Central leveraging a Java application server. The biggest challenge is that there's a lot of moving parts, but the implementation is actually quite easy. Let's take a look at the Java servlet, the Flex application and the Central hooks. And as always, at the end there's a Captivate demo, of course!

The servlet, all nineteen lines of it, is pretty straightforward. I didn't account for anything more than a single file upload, and my error management is atrocious, but this sets the groundwork. If there's something that's not covered that you have questions about or would like to see the code for, just drop me an email and I'll see what I can do to update the example.

I've been a fan of the multipart request library at Servlets.com since it was published and I use it here again. Why? When Central makes a file upload it does so through HTTP POST, very much like a file upload done through classic HTML. At the server we need to grab that binary stream and save it to disk. Rather than think about all the HTTP details and reinvent the wheel, this little (but exceptionally robust) library does the trick.

import com.oreilly.servlet.MultipartRequest;

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.IOException;
import java.io.PrintWriter;

public class UploadServlet extends HttpServlet {
protected void doGet( HttpServletRequest req, HttpServletResponse res ) throws ServletException, IOException {;}

protected void doPost( HttpServletRequest req, HttpServletResponse res ) throws ServletException, IOException {
MultipartRequest parts = new MultipartRequest( req, "C:\\MyUploadPath" );
PrintWriter out = res.getWriter();

out.print( "SUCCESS" );
out.close();
}
}

While the combo of Flex and Central and all the great file IO capabilities (and more) lead to an obviously huge amount of potential, my whiz-bang UI will consist of a Button and an Image. The Button will eventually trigger the file dialog and get the file upload going. Once the file upload is complete, the Image's source property is set to the location of that file on the server. The Image subsequently loads the file and displays it in the body of the application.

For the purposes of this demonstration I have set the Image control up to scale its contents and display them horizontally centered.






You'll notice that on the Button control I capture the click event and call the doUpload() method in the application. This method creates a Central FileReference object, and prompts the user to select a file. In this case, I've limited the file types to JPEG images. Before I start the upload I attach the application itself (probably not a best practice long term) as the listener for any problems that might arise during the file transfer.

The two methods that the application listens for are onUploadSuccess() and onUploadFailed(). There are a variety of other events that can be triggered, but for the purposes of getting a file to the server, and making sure it happened successfully, this will work just fine. Once the user selects a file, the upload process begins with a call to FileReference.upload() and specifying where in the world our upload servlet lives.

If the file has been transferred successfully then the onUploadSuccess() method will be called. The onUploadSuccess() method gets a couple arguments; a reference to the file that was uploaded and any textual response from the server. I could have been inventive and accounted for existing files of the same name, populating the image in a database, etc. at the server and returned a string as to where I can access that file. This would have shown up as the response argument. Instead, I'm lazy, and I use the file reference to get the name of the file and a static URL.

The onUploadFailed() method I've implemented is equally lazy - I simply alert the user to an error by telling them what the server tells me. Realistically, I might chose to pull the local file into Central's cache and work with it there, or behave as though I am working offline and store a reference to the file for access when the network has been restored. Once again the options are limitless.

private function doUpload( event:Object ):Void {
var file:FileReference = new FileReference();

// Ask the user to choose a file to upload
if( file.browse( ["JPEG Files", "*.jpg"] ) ) {
file.addListener( this );
file.upload( "http://myurl/servlet/MyUploadServlet" );
}
}

private function onUploadSuccess( ref:FileReference, response:String ):Void {
imgUpload.source = "http://myurl/myfilepath/" + ref.name;
}

private function onUploadFailed( ref:FileReference, error:String, response:String ):Void {
mx.controls.Alert.show( "Upload error: " + error );
}

That's all she wrote. Deploy that application and add native file upload to your bag o' tricks today!



Posted by khoyt at 03:45 PM | Comments (2)
December 11, 2004
Central/Flex Hex Editor

This one is from the category of "Just Because I Could" - a Hex Editor, written in Flex and deployed in Central (to allow for file IO). An editor of this nature can potentially represent a ton of data. The image file shown here weighs in at about 433 KB; it results in around 27,000 rows of hex data! Despite the obvious overhead, I'm eager to continue to add a few features as I have some future uses for portions of this application.

Since I'm not exactly sure just how useful this would be out there in the public domain (there's already a plethora of hex editors out there), I'm not releasing the code. If you're still interested in the source you can email me and we?ll talk.




Posted by khoyt at 06:36 PM | Comments (0)
December 06, 2004
File Explorer in Flex

Okay, this one's coming at you straight from the customer request files! Last week I had a customer ask for an example showing Tree control manipulation based off RemoteObject calls. The customer asked for an example where node data would be appended dynamically as data was returned. They were displaying hierarchical data specific to their business, so I went for the next best thing - system file data.

It turned out to be easy enough to emulate file system structure in a Tree control based off service call results, so I couldn't just stop there. I figured that I'd keep going and provide additional display metaphors. Windows Explorer displays additional file data in a grid, and upon deconstructing its behavior, reflects navigation in the tree in a somewhat complex fashion as well. The example is available for your convenience.

I implemented a simple Java object as the service, and that provides me with some convenience methods for accessing the data in the form I want/need. I'd likely refactor that code somewhat, so don't use it as a pure reference of what should be done on the server-side (outside of the pattern of providing a service adapter). I've also roughed in the MXML for direct file access through an address bar. I haven't hooked it up, but the code is there for you to expand upon if you so please.

My favorite part of the application is the formatting, totaling, and summation that take place at various points. In the following Captivate demonstration for example, you'll notice that right out of the gate there's a total for the number of objects, and their combined size (in GB) in the status bar. As the Tree is navigated, those values will change - and they're even intelligent about the units in which they display (not always GB). Formatting also takes place in the DataGrid through labelFunction properties on the DataGridColumns.




Posted by khoyt at 05:13 PM | Comments (3)
December 02, 2004
Clock Component in Flex

I've seen the occasional request for a clock component in Flex, and I'm wondering what some of the requirements might be. Are we talking an analog clock or more along the lines of a text field approach? The Windows system clock shows both in a fairly simple fashion - is this adequate? Just the analog clock? Just the masked text field? Since there are numerous analog clocks done in Flash throughout the community, I suspect the requirement is for the later of the two. If you have a need or interest in seeing a component of this nature, let me know by posting in the comments with your particular requirements. The more specific the better.

Posted by khoyt at 04:58 PM | Comments (2)
OS X Style Dialog Using Macromedia Flex

I recently found myself entranced with way OS X dialog boxes appear and disappear out of the top of the window to which they belong. Becoming fixed on the UI, as is often the case, I found myself compelled to see if I could duplicate the effect using Macromedia Flex. The basics didn't turn out to be that hard.

I've made my initial pass available for review and expansion. There are a few shortcomings I'd like to address, but as the year draws to a close, so do the number of spare hours I have in a day (smile).

Update [Dec 3, 2004] : The original example SWF file was built using the Developer Edition of Flex and as such was going to timeout after 48 hours. I've replaced the actual application SWF with a demonstration SWF created using Captivate.

* Future improvements might be: Use the Text control instead of Label which limits me to one line of text
* Externalize the icon as a property, and make a small default set available
* Allow for button definition along the lines of the Alert control
* Remove focus from the main UI in favor of a default button on the dialog

Error Branch between 7684 and 41198 around line 0

Error :

I am using Flex Builder 1.5, today when i compile a mxml file , i received the following error:
[exec] Error: Branch between 7684 and 41198 around line 0 exceeds 32K span.
If possible, please refactor this component.

Solution

This is an error that is produced in Flex 1.5 in order to alert you that
your code needs refactoring in order to decrease the number of visually
rendered mxml tags in a single file. There is more information in the FAQ
here, including how exactly to refactor your code:

http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt


This is an error that is produced in Flex 1.5 in order to alert you that
your code needs refactoring in order to decrease the number of visually
rendered mxml tags in a single file. There is more information in the FAQ
here, including how exactly to refactor your code:

http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt



well Question :
a question about "more-code" trick.I wonder if i can use the "more-code" trick only when i can compile the app with ?debug="true" in the URL. Now i can not even complie the file with "debug="true"".Does it mean that i must modify the structure?

You can use the "more-code" trick without the debug option.

How is the application structured? As I said in the faq, files containing both mxml tags and actionscript the near 2000 lines are in danger of hitting the limit. If a file is this large, the trick won't work, and you must actually refactor the file.

Note that including a file with a script tag will not help, it counts in the total line size.

The Blank Canvas.

It just sits there and stares at you; you have Adobe Photoshop open in one window and FLEX Builder in the other. You can kind of see the vision inside your head, but just can't quite convert the "wouldn't it be cools" into PIXELS immediately.

This is something I've faced on and off as with FLEX you basically have un-restricted access to how you want your User Interface (UI) displayed on screen and in a way that can be chrome focused or simply content focused.

My mates have called FLEX the "Unified View" it's the missing link to the puzzle of joining disparate systems together under one Unified View of your choosing. It furthermore, allows folks in large companies to have quite an agile "console" to view their intended context without placing too many restrictions on them.

As of late, getting back into the design mode, I've noted that there is a lot of "Glass" or "Apple-Candy" style UI floating around the shop. I look at the upcoming Windows Vista and get a sense of "hey when did Microsoft grow up design wise?" while at the same time, still to this day enjoy the experience of using OSX.

I like to take slices from both to be honest, a bit of OSX goodness mixed with Vista and see what I can come up with in FLEX. I've taken MS OFFICE 12 menu "ribbon" and ported the same design concept into FLEX and this now has opened up a lot in terms of much needed canvas. Armed with this menu, I can hide while still be proactive in displaying a lot of menu navigational items that are still "easy" to use. It will take of course time with regards to seeing how feasible and usable this approach is, but like a lot of the menu's we see today, there was always a user resistance at first.

I typically tend to start at the chrome level when designing UI, as the rest kind of fits into place as I go. I have a lot of books open with regards to Usability and Information architecture at the ready should I come up with a design that I flag as being potentially hazardous to the end user(s).

For me, the biggest joy I can walk away with in regards to FLEX is knowing that I can build a UI to suite a person's context while still sharing similar or the same amount of information.

A project recently comes to mind, where there are about 5 Line of Businesses that need to access the same data but on different levels and in different context. Some also require additional data from 3rd Party resources but overall there needs to be an application of the same branding in place.

The first knee jerk approach was to look it from a HTML perspective. I won't have that, because I'm the resident FLEX Evangelist so I've opted for FLEX 2. Armed with FLEX one is able to then present these specialized needs to the lines of business but at the same time - here's the kicker - share the same code blocks while also allowing the same data to be shared (Flex Enterprise Services).

It's a pretty product young FLEX, and can't wait to see more applications and more importantly sexy UI on top of FLEX.

Why Choose FLEX over HTML

A reader has asked me the million dollar question for the month, "How, in your opinion, will FLEX accomplish this better than HTML?" Now the "this" part could be anything you want it to be, but the core question still remains why is, FLEX better then HTML is or is it even better then HTML?

I find at times people tend to lump the word AJAX around to justify using HTML, and I appreciate their intentions but in reality AJAX is more to do with the remoting side of things, its if you will a decision gateway between two points. It helps get data from A to B but at the end of the day, you're still dealing with the same beast, HTML. HTML requires JavaScript to give it life and as a result everything we build with the two ends up "emulating" in some shape or form what we take for granted in software like Outlook or MS Word. Overall, we are dealing with injecting code into a DOM tree and hoping that memory is still "good" and the usability / accessibility is at a reasonable level.

What you tend to not read so much about the AJAX equation is the HTML side of things, how does one emulate a sortable grid? Sure we can keep asking a server-side solution for more packets of data as we scroll down or apply certain filters - even though its done in a fairly verbose manner - but at the end of the day, before we reach that point, we have to first and for most, build a User Interface framework. So set aside some time to either test existing ones and potentially extend them or if you suffer from NIHS (Not Invented Here Syndrome) off you go, build away and take some glory for something that probably already exists. Your team mates will think your hardcore, but eventually they'll wonder as to why you spent the better part of 2 weeks building something that is free or can be bought anyway?

FLEX and HTML should be compared side by side not FLEX and AJAX. FLEX via MXML only can still do quite a significant amount of things then HTML. Yet if you throw in JavaScript into the equation with regards to HTML, then it too becomes a new fashion accessory that all the kids love. At the same time you do this, to be fair, throw in ActionScript into the MXML mix and still compare the two?

FLEX is more manageable then HTML, its only real downside is the fact that the agent required to view it, has to be downloaded vs it being in built into the browser. Yet, Internet Explorer has the agent required already built in - well most of the time and granted its Flash 6.0 but the point is, the perception is "FLASH is a must to surf online, all the kids are doing it".

FLEX is quite new still and people are still weighing up the pro's and con's of why teams should adopt it and so that plays a crucial part in the overall question as to why use FLEX instead of business as usual with regards to HTML. HTML is easy, we all know it, its been in our view for at least a decade (and then some) so its something we can all trust and lets face it, no company really controls it do they?

One could argue the browser makers own HTML, but if one screws up, history has shown they will loose their user base as quick as saying the word "Netscape".

So which of the two is better?

My opinion is FLEX. FLEX offers you a decent footprint to move forward, it has to many connections or "to be continued" paths into to many powerful platforms not solely owned by Adobe but also even Microsoft. Hell, there is absolutely nothing stopping you from connecting a FLEX UI to say Microsoft Workflow Foundation Server (WFS), except your understanding of the mystic art of that which is "Remoting".

What is remoting? Well it's a way to send data between the User Interface and the Server in wait for it, "binary" form. Yes kids, those crazy cats over at Adobe/Macromedia space have come up with a novel way to send complex packets, serialized into binary which then gets transmitted down the pipe and deserialized at the other end into native formats of your choosing (Java/Coldfusion/.NET folks are loving this goodness that's for sure).

Now let's do the unthinkable, let's compare FLEX again to AJAX. The two can work with one another sure, but lately that's debateable or worst yet, unknown that they can infact work together if they want to. Yet, why bother? All said and done, FLEX can do a lot of the burden in terms of transmitting data packets of large sizes, in much smaller footprint formation whilst the JavaScript and HTML side of things tend to live in a simplified world of XML - aka - SOAP (which FLEX by the way can also consume as well but also in a manner that's much more efficient in parsing - E4X baby).

Look, I don't want to beat up on AJAX so much, I get its core principal and objective in life and do agree with it short of accepting it's still a viable choice. Five years ago, I would have loved the worlds attitude to it as it stands today, yet five years ago if you uttered the words DHTML in a development environment that wasn't in a strict Internet Explorer 5.5 and above Set Operating Environment (SOE) you would have been scolded or worse, assassinated on the spot.

Its too little to late, and FLEX is done its opening the web to more and more wonders such as video and audio for one (AV). AV isn't something that's solely reserved to movie trailers or expensive news promos, its also quite useful for screen sharing or eLearning. The kicker is you could use the technology you just built your software with to also teach people how to use that very software via radical yet still quite cost effective approaches.

FLEX is a framework built for free, yes free. There are addons which cost you a bit or then some, but hey nothing in life is 100% free and when it is, it usually means someone has to do some work at some point. None the less, it's a framework or a set of tools for you the developer to focus more of your energy on building the important stuff rather then yet another sortable datagrid or some button that has magic roll over effects.

You can also define your own language, you're not limted to the MXML approach. You simply extend FLEX components (which is extremely easy) and before you know it you've got a language that's semantically marked up to suite your business needs rather then having verbose equation.

To do this in HTML, it can be done but it requires some magic XLST mapping process or worst, CSS.

FLEX, you get it for free and it then opens you up to the ability to slice and dice the code to suite the context of your needs as well (sort of build the user interface for each user on the fly for their specific needs much like HTML world does websites).

Heres the final nicety involved with getting into bed with HTML vs. FLEX. It offers you the ability to translate your living breathing business processes (wether it's via BPEL, BPML or some crazy BPMN mix-up) and that in turn translates out to living breathing UI.

You could even do a drag/drop build on the fly UI that's not restricted by where tags are put and how they are put. It's the dream "Content Management System" technology in terms of User Interface.

HTML is good, it serves a purpose for large amounts of text and more suited to Document orientated approaches, anything outside of that is work and hard work at best.

The only justification left these days for why HTML? Simply put skill set. If no one in the room is yet up to speed with FLEX, then yes, stick with HTML as no use risking a projects outcome unless you have mastered the technology you intend to build it on - otherwise you're ignoring the problem and solving a technology one rather then having technology solve the problem.

Embedding HTML in a Flex Application

I updated the files for Embedding HTML in a Flex application in AS3 in this directory. I didn't test the files with beta 2, but they should work with the upcoming beta 3.

One important change is in the HTML wrapper, which was causing the HTML to sometimes disappear when using IE. There needs to be a parm setting wmode to opaque. I also updated the HTML wrapper to a newer version, and made a few other minor changes (which I would list, but it's been so long I've forgotten them...)

The migration text I promised a long time ago doesn't look like it'll ever get completed, so I'm just going to copy the 80% done version below for those interested.

When migrating Christophe's solution, Embedding HTML in a Flex application using an IFrame to Flex 2, I kept detailed notes of what I was doing. Below is the prettified version of these notes.

The Easy Changes

After writing this part of the migration explanation, I realized it wasn't really necessary, that it's easy for anybody to compile, see the errors, and look up in the help system any of the errors that come up. This worked very well, and I was easily able to figure out most of the issues I came across. But I kept writing things out, so here's the full migration info for those interested.

I took the compile-fix-repeat method of fixing the issues. A studying of a migration guides along with a more structured search and replace would make more sense for a large project, but I knew some of the issues already, and I'm only converting three files.

The first thing I did, without thinking, was change the mxml namespace from "http://www.macromedia.com/2003/mxml" to "http://www.macromedia.com/2005/mxml". The next change I made with my eyes closed was to add access modifiers to functions and type declarations variables. So "function moveIFrame()" became "private function moveIFrame()".

Adding a type declaration of Object to pt gave me the Error "Implicit coercion of a value with static type 'Object' to a possibly unrelated type 'flash.geom:Point'". This made it obvious that I needed to change:

var pt:Object={x:0, y:0};

to:

var pt:Point=new Point(0, 0);

After that, I compile the add and got the error "Overriding function that is not marked for override" in IFrame.mxml, which extends Canvas, on this method:

public function set visible(visible: Boolean): Void {

That's another thing I should done off the bat, which is add override to methods that override:

override public function set visible(visible: Boolean): Void {

Next I'm told that getURL doesn't exist:

getURL("javascript:hideIFrame()");

I search the help and see that this line now needs to be:

public var u:URLRequest = new URLRequest("javascript:hideIFrame()");
navigateToURL(u);

And I add "import flash.net.navigateToURL;" to the top of the Script block.

Next I saw "Type annotation is not a compile-time constant: Void", which means I needed to change Void to void everywhere I see it.

doLater() showed up as removed, so after searching the docs I changed this it to callLater, from:

doLater(this, 'moveIFrame')

to:

callLater(moveIFrame)

Dealing with HTML and ExternalInterface

At this point everything compiled fine. I put index.htm into the directory where the SWF was (since I couldn't tell Flex Builder to use a custom html wrapper) and then clicked on the file to display... nothing. Ah yes, the SWF name was different now, from IFrameDemo.mxml.swf to IFrameDemo.swf. So I load it again and... nothing. I load just the SWF and it displays. I take the script out of the HTML page and see this error from Flash:

SecurityError: Error #2051: Security sandbox violation: 'file:///C:/dev/flex/projects/iframe/IFrameDemo.swf' may not evaluate scripting URLs within 'file:///C:/dev/flex/projects/iframe/index2.htm'.

I remembered that there was a new restriction in Player 8 (and 8.5) where local files and network files could not be accessed in the same movie. I wondered if relative URLs were thought to be network files. Sure enough, when I loaded the SWF through JRun, I didn't get the error anymore. But the page within the page still didn't show up. I figured out that unlike getURL(), navigateToURL() would not work allow any frame to be given as the second argument. So I decided to go ahead and convert the navigateToURL() calls to ExternalInterface.

This took awhile. Converting the navigateToURL() calls was easy, as the ExternalInterface calls were very simple, like this:

ExternalInterface.call("loadIFrame", source);

But still the html page was not showing up. What was going on?

At this point I conceived my my "debugging strategy" in Javascript, which consisted of looking at Firefox's Javascript console and throwing alerts up as debug statements. Ug. Is there a better way to do this? After sifting through the methods, I figured out that only the first argument to moveIFrame had all of argument information in it. So I changed:

ExternalInterface.call("moveIFrame", pt.x+","+pt.y+","+this.width+","+this.height);

to:

ExternalInterface.call("moveIFrame", pt.x, pt.y, this.width, this.height);

Once changed, the html finally showed up. But the frame showed up in the upper left hand corner. localToGlobal did not look to be working correctly.

var newPt = this.localToGlobal(pt);

After this, everything finally worked!


Making Things Better

The one problem I had at first with the generated html in Flex Builder was that I didn't know there was a to interject Javascript into the page. (html-template)
Add the Javascript functions (moveFrame, etc). Added onMouseDown="document.body.focus();" to the embed, alhtough not sure if htat was needed. Also added + 'wmode="opaque"'
+ 'swLiveConnect="true"' to the embed. Added the iframe named 'myFrame'.

The Tree on the left still looked really odd. Apparently the......

Tried adding "rootVisible="false""

Change the change attribute value in Tree from :

iFrame.source=tree.selectedNode.attributes.path

to

iFrame.source=tree.selectedNode.path

I made a few cleanup changes. The VBScript and related Javascript method in index.htm were removed, since it was only needed for some commented-out fscommands. In IFrame.mxml, I added a check for ExternalInterface via ExternalInterface.available, throwing an Error if it wasn't available. In IFrameDemo.mxml, I added a third section of links for Flex sites.

Flex 2: What’s in it for Flash Developers?

Flex Myths from a Bygone Era

The top two myths about Flex-the-elder were the following:

Myth: You need to run Flex as a server

Truth: You could always create SWF files using the Flex compiler and deploy them without the Flex server. You would still need to purchase a server license for each computer you deployed Flex SWF files to.

Reason: The only reason I can fathom for perpetuating such a myth would be to increase the number of server licenses sold. Flex is a great compiler but a lousy server. By lousy, I mean that it doesn’t handle load well at all. It does, however, scale well through clustering. And we all know that the more you cluster, the more server licenses you have to buy.

Developers unfortunate enough to buy into this myth — mostly Java houses because it validated their belief in the superiority of all-things-Java by mirroring their existing workflow with JSP — probably ended up paying for lots of server licenses that would not have been necessary if they had deployed plain SWF files to the server. It is not inconceivable, thus, that many Java houses ended up paying quite handsomely for their vanity. Alas, vanity is usually a trait that comes with a high price tag, as opposed to the bargain-basement discounts that may be had through a sound investment in pragmatism.

Myth: Flex and Flash are very different beasts. Flex is for programmers, enterprise developers, software engineers and Flash is for “pixel pushers”.

As famously quoted in the Macromedia Press book on Flex, Macromedia was trying to carve a very limited niche for Flash Developers as people who create skins and perhaps components for the big boys to use in their “enterprise applications”. I experienced this first hand when my article for Macromedia Edge on “Migrating a Flash Application to Flex” was retitled without consultation at the last moment to “Tips for Using Flash Assets in Flex Applications“. (You can find an expanded, unedited version of my article here.) At the time, in line with its “enterprise” positioning of Flex, Macromedia did not want you to know that it was actually trivial to port a well-architected Flash application to Flex as it revealed how similar the two products were.

This new placement of the role of the Flash Developer at once displayed a lack of understanding of the complexities involved in UI and component design and development as well as an unexplainable amnesia with regards to the amazing applications work performed by Flash developers in the past. It also reflected well the arrogance of certain Java developers, who, possessing ultimate knowledge of The One True Way, were merely enlightening the primitive Flash natives with the wisdom of their gospel. In due time, the natives found that they had to teach the Enlightened Ones what a movie clip was, but that’s another story!

Truth: Flash and Flex are very similar indeed. Flex, at its core, is nothing more than a framework, written in ActionScript 3 (and previously, in ActionScript 2), that runs on the Flash Player. In compiling Flex applications, MXML is translated into ActionScript and that resulting ActionScript is compiled into SWF bytecode. Thus, for all intents and purposes, the Flex framework could have been written using the ActionScript editor in the Flash IDE! There is, of course, more to Flex than just the framework. There are the compilers, which compile MXML and ActionScript 3, a visual development tool, Flex Builder, and a server, Flex Data Services. Although, technically, there is little to differentiate the two, in terms of workflow, efficiency and use cases, there truly is a world of difference.

The primary advantage of using the Flex framework with Flash Builder over the Flash framework with the Flash IDE is the ability to declaratively create user interfaces. This tag-based, hierarchical, XML-based approach provides a number of key workflow and productivity enhancements over the layout of user interfaces in the Flash IDE. The first such advantage is that MXML files are text based as opposed to the binary FLA file format. This makes them easier to version control and, more importantly, to diff. The importance of this in team environments cannot be overstated. Secondly, the hierarchical structure of XML fits perfectly with the hierarchical structure of user interfaces and the component model in MXML provides a neatly encapsulated modular framework with an elegance that eludes other similar languages such as Microsoft’s XAML and Laszlo’s LZX. The Eclipse-based Flex Builder 2 tool itself also offers a huge productivity boost.

That is not to say that Flex is The Ultimate Answer To All Things Flash. The size of the framework itself is a major hindrance to the use of Flex in consumer-facing applications. The smallest Flex application weighs in at around 150kb due to the size of the Flex framework. Although is acceptable for intranet and business applications, it is not something you would use to create your blog. (300-400kb would probably be the minimum size of a real-world Flex application with branding, etc. and a considerable amount of code.)

Reason: Macromedia wanted to differentiate the two products as much as possible to justify the difference in price point between the two.

Flash Forward: Flex 2

I am very happy to see how Adobe is currently positioning Flex 2 and I’m impressed by the transparency with which they are approaching things. Their new approach with Flex 2 is a healthy, long-term one. I’ve said, more times than I can remember, that we need more developers on the Flash Platform and Flex 2 is just the framework and toolset to entice these people.

In looking for new developers for Flex, however, we should not ignore the fact that we have a large pool of Flash Developers who already know much about Flex (through their ActionScript and Flash knowledge) but perhaps are either not aware that they know as much as they do or have been frightened by the myths surrounding Flex in the past. It is imperative that we support Flash Developers who want to learn Flex and break down the misconception that Flex is a complicated tool that can only be understood by a handful of superhuman software engineers. Michael Koch’s article is a great step in this direction and I am glad to see Adobe doing the right thing with Flex 2.

Personally, I’m having more fun I’ve ever had in developing Flash applications since I started using ActionScript 3 and Flex 2.

For more on Flex and Flash, read Michael’s article on Adobe Edge. You can read more of my thoughts starting on the third page of that article.

Go to this link for superb videos:
http://www.adobe.com/newsletters/edge/may2006/index.html?sectionIndex=2

NoteTag: A Flex 2 sample application

NoteTag is the first public release from the Kiwi project.


NoteTag is a proof-of-concept by a new project at Adobe currently code-named Kiwi. The Kiwi Project is an exploration of Read/Write RSS and Web 2.0 components for Adobe Flex and the Adobe Engagement Platform.

NoteTag is a sample Flex 2 application that allows users to capture notes during meetings and assign tasks within those notes to individuals. Underneath the hood, NoteTag stores notes as blog entries, formats tasks using a microformat, and uses tags to link tasks (from notes) to people. NoteTag uses a preliminary set of Kiwi Project component libraries, including an AtomProtocol library, a simple TagServerProtocol library, and an extended RSSRW library that supports setting data in an RSS feed.

NoteTag is a proof-of-concept release. As such, the NoteTag source and the Kiwi Project component libraries (described below) are of experimental quality; we have released them as-is under the Adobe Labs license. NoteTag also includes the Cairngorm Framework from Adobe Consulting as a compiled SWC compatible with Flex 2 Beta 3. Cairngorm has its own license which is included in the Cairngorm folder inside the NoteTag ZIP file. We want to share our direction and listen to your feedback so that we can continue to incorporate it into our Read/Write RSS and web 2.0 Flex development strategy and planning.


Link:

http://labs.adobe.com/wiki/index.php/NoteTag

Adobe and Macromedia Sites Finally Merge

Last month the Adobe Web Design and Technology Group launched a new integrated external website, permanently retiring Macromedia.com.

The launch, which our team called Day Next, was just the first phase of a major, ongoing effort to fully integrate the Adobe.com and Macromedia.com websites.


Go to Link for details.
http://www.adobe.com/devnet/logged_in/rducot_daynext.html

A Ruby Script for Compiling Flex Applications

There have been a lot of posts recently about how to compile Flex applications and ActionScript projects from the command line (on Windows, Mac, and Linux). Mike Chambers has a nice summary(http://weblogs.macromedia.com/mesh/archives/2006/01/resources_for_c.html) which points to all the information you need to get going, and has a bash script(http://weblogs.macromedia.com/mesh/archives/2005/12/compiling_actio.html)which wraps the mxmlc compiler to make compilation easier.

I have some specific compilation needs, however, so I decided to write a Ruby script(http://weblogs.macromedia.com/cantrell/files/mxmlc.rb) to wrap the mxml compiler (I'm not a huge fan of bash once my scripts reach a certain level of complexity). Once you have the Flex environment set up, just download the script,(http://weblogs.macromedia.com/cantrell/files/mxmlc.rb)make sure it's in your path, configure it, and you can compile like this:

% mxmlc.rb MyApplication.mxml

The script has the following flags:

* -h Help. Prints out this help message.
* -t Tail. After compilation, tails the file specified by the TAIL_PATH variable. (Useful for debugging your application.)
* -o Open. After compilation, opens the generated swf in the application specified by the OPEN_APP variable. (This should probably be something like 'firefox' or 'safari'.)
* -s Show. Show the compilation command rather than actually running it. Useful for debugging if it's not working like you expect it to.
* -c Clean. Removes cache files before compilation so you compile the project completely from scratch.

Before running the script, you have to configure it by defining the following variables at the top:

* FLEX_PATH: The path to your Flex library installation.
* AS_LIB_PATH: Path to your ActionScript libraries. In other words, your classpath. You can specify multiple directories by separating them with a ':' character. You can also add a '$' character anywhere in any of the paths which essentially acts like a wildcard. For instance, if I added the directory /Users/cantrell/projects/$/src/actionscript, then the script would iterate through all the directories in /Users/cantrell/projects and add all those directories, plus /src/actionscript to the classpath. It's an easy way to include an entire source tree with one path. (If the generated directory doesn't actually exist, the script automatically leaves it out.)
* TAIL_PATH: The path to the file you want to tail if you pass in the -t flag.
* OPEN_APP: The application you want to open the resulting swf file in if you pass in the -o flag.

Also Check For this links :

Part 1
http://www.liverail.net/articles/2006/04/16/rubyonrails-1-1-and-flex-2-0-pt-1

Part 2
http://www.liverail.net/articles/2006/05/06/rubyonrails-1-1-and-flex-2-0-pt-2

Part 3
http://www.liverail.net/articles/2006/05/13/flex-and-rails-part-2-extra-time

JDJ Ria With Adobe Flex 2 and Java

Check this link for more information
http://jdj.sys-con.com/general/currentcover.htm

Learn From

Check out the Kiwi Team Blog where all sorts of good information is being posted. Brian Riggs has just added a great introduction to the architecture involved in a large Flex app. Definitely worth a read.
http://blogs.adobe.com/kiwi/

Flex a no-brainer?

I was thinking today about the Flex beta that's going on at the moment, and then thought about the target audience for Flex, i.e. people just like me. By this, I mean people with several years at the wheel of CF, HTML, CSS and JS with some basic flash knowledge.

Well, as far as I can see there is now no longer any valid reason for me to develop anything in Flash anymore now that Flex is around. It's exactly the same argument as CF vs Java. Why write something is Java when I can use a RAD tool like CF?

From a manager's point of view though I can see some possible problems, namely one of cost and confidence. Before, developers were convincing their managers to let them publish their companies first RIA's in Flash. They promised datagrids, large amounts of remotely accessed data and swizzy new interfaces.

However, what flash was actually capable of fell someway short, (although the improvements in Flash Player 8 made massive inroads into some of the main problems) which lost confidence somewhat in the platform as being able to provide RIA's (well, in my experience anyway) from a manager's point of view.

Now Flex is nearly here, and we're again trying to convince managers to re-tool and re-train for the new tools that are again using the Flash platform. Admittedly this is a RAD tool, and there are the great new data services available, but is it as clear cut for those who won't be actually cutting the code?

WebService Successful

The main problem people were having is related to the way of thinking that a traditional CF/HTML developer has. In HTML a select consists of values and labels:

However, in Flex, this isn't the case, each item of a select (or combo to give it it's correct name) is an object. This essentially means you can chuck pretty much anything you want at the combo, you just need to tell it what part of the object is the label value. (Remember, I said this would be enlightening).

So if we take some mxml (which answers the question):







You will see a webservice being called when the application has finishing loading, this then returns a load of objects, which are in turn bound to the combo's dataprovider. To get a label simply point Flex at the item in the object that represents your string label (in this case CATEGORYNAME) using the labelField attribute. This will give you your Combo with your labels.

So how do we get at the data? Well, remembering these are objects in the combo, the data is right there in each items relevant object (so in theory you can have loads of data fields in one combo!). To demonstrate this we have a label bound to the selected items CATEGORYID.

So, now you know. If you are a HTML/CF developer this would have probably been quite hard for you to figure out, due to the fundamental way this is different to HTML (which is partly the point of this test being first, as it is such as big difference and had me stumped for ages). If you knew Flex already, it should have been a walk in the park.