unicode support in flash/flex? yes. RTL support in the flash player? nope.

The String data type represents a sequence of 16-bit characters. Strings are stored internally as Unicode characters, using the UTF-16 format.

By default, text encoding is in the UTF-8 format. You can change the encoding to other formats (ISO, ASCII, UTF-16, and so on) as needed.

You can use the UTF-8 encoding format to ensure maximum platform compatibility. UTF-8 provides a unique number for every character in a file, and it is platform-, program-, and language-independent. If you specify an encoding format, it must match the file encoding you use.

To use Line Chart to show 2 series :

Data points on the DateTimeAxis support the String, Number, or Date data types.

1] Date: If the value of the data point is an instance of a Date object, it already represents an absolute datetime value and needs no interpretation. It is possible to pass a Date object as a data value if you use the parseFunction property of the 2] DateTimeAxis. That function returns a Date object. For more information, see Using parseFunction.
3] String: You can use any format that the Date.parse() method supports. The supported formats are:
4] Day Month Date Hours:Minutes:Seconds GMT Year (for example, "Tue Feb 1 12:00:00 GMT-0800 2005")
5] Day Month Date Year Hours:Minutes:Seconds AM|PM (for example, "Tue Feb 1 2005 12:00:00 AM")
6] Day Month Date Year (for example, "Tue Feb 1 2005")
7] Month/Day/Year (for example, "02/01/2005")
8] Month/Year (for example, "02/01/2005")
You can also write custom logic that takes any string and returns a date using the parseFunction property of the DateTimeAxis.
9] Number: If you use a number, it is assumed to be the number of milliseconds since Midnight, 1/1/1970. For example, 543387600000. To get this value on an existing Date object, use the Date object's getTime() method.
The following example uses a string value for the date that matches the MM/DD/YYYY format

the example uses a string value and parseFunction:
------------------------------------------------------------------------
the parseFunction property of the DateTimeAxis tag to customize the value of the data points. With this method, you specify a method that accepts a String and returns a Date object.

The following example shows a parse function that creates a new Date object out of strings in the data provider that match the "YYYY, MM, DD" pattern:


[Bindable]
public var aapl:Array = [
{date: "2005, 8, 1", close: 42.71},
{date: "2005, 8, 2", close: 42.99},
{date: "2005, 8, 3", close: 44}
];

public function myParseFunction(s:String):Date {
// Get an array of Strings from the comma-separated String passed in.
var a:Array = s.split(",");
trace("y: " + a[0]);
trace("m: " + a[1]);
trace("d: " + a[2]);
// Create the new Date object.
var newDate:Date = new Date(a[0],a[1],a[2]);
return newDate;
}
]]>

Apollo - Flash to jump beyond the browser

The goal of Apollo, which will be available as a free download early next year, is to overcome some of the limitations in today?s Web applications, Lynch said. Right now, Flash programs run within a Web browser. Apollo is client-based software that will run Flash applications separately from a browser, whether online or offline, he said.?

http://weblogs.macromedia.com/mc/archives/2006/06/oh_apollo_techn.cfm

a question about "more-code" trick.

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.

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

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.

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.

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!

Messaging from HTML to Flex 2

just check this link...
http://weblogs.macromedia.com/khoyt/archives/2006/03/flex_2_messagin.cfm

Resizing Flex Overlaying HTML

Christophe Coenraets recently posted an example of laying HTML content over Flex content in an IFRAME. The reasoning for this is that while the Flash Player does offer some HTML rendering abilities, these abilities pale in comparison to the browser. This makes sense of course, as displaying HTML is what browsers were designed to do.

Inspired by the post, I recalled a customer conversation a few months back where the inverse was desired. The customer wanted to place Flex content over HTML content. Normally this might sound like a perfect opportunity to use a DIV or IFRAME in the opposite role of Christophe's example. The trick to this was however, that the customer wanted to be able to "roll up" the Flex content to a smaller area over the HTML content when the Flex content required less emphasis.

The test case for this was a combo-box, rendered and populated by Flex, overlaying HTML content. Only the main face of the combo-box would be visible until the drop-down was triggered. Once the drop-down was triggered, Flex needed to expand its visible area to accommodate the list. This would then block the underlying HTML content. The inverse was required to happen when an item was selected from the drop-down and the list was returned to its "hidden" state.

My solution to this was to watch for the mouse down event on the combo-box (not the open event as that would be too late) and then tell the containing HTML page to resize the viewable Flex space via a JavaScript call. When the viewable Flex space was changed, the application's resize event was called. When the application had resized itself, the combo-box was then instructed to show the drop-down via the open method. When a selection was made, the inverse chain of events was followed.

In the end the customer seemed quite thrilled with the solution, and overall I think the effect itself is pretty neat. Posted here for reference and for the sake of posterity, I've included the commented source (both MXML and HTML) as well as the obligatory Captivate recording.

FLEX :: Part 1 - The hidden costs!

I've been racking my brains on how to approach this post, as i feel its very easy to go down the whole "FLEX price sux" path and reasons why. I'll try to keep it in point form, and hopefully show you some of the hidden costs behind FLEX, and why 12k USD will be its so called "death".

The one selling point..

Macromedia will and have pushed the one major selling point behind FLEX and that is:

"..its ability to create a Flash based application in minimal time and effort..."

I've been using FLEX since its first Beta, and I can honestly tell you this is the truth. FLEX will save you a bucket load of time and money to create an application that would normally cost you triple even more, via the Flash MX IDE approach.

No more Flash development bottlenecks in your RIA projects, in that instead of having a sole Flash MX developer working for days on rendering a screen that talks to Coldfusion, you can have many developers working on the code and produce the same results in less time and better yet, can adhere to existing development practices (CVS etc).

FLEX saves us 8k (AUD)

You may hear this a lot, but I'll take a stab at it anyway. We worked out a project that would roughly take us 3 months to do in Flash MX 2004. We then worked that same project out (approx) in FLEX, and compared the guesstimate prices, and in the end we figure (being generous) we would save around 8K in costs.

8K for one project, FLEX has almost paid for itself you say? yes that is true, in that eventually you in theory could end up getting FLEX to pay for itself.

FLEX now costs us 50k+ (AUD)

Sadly though, we assumed the development team was up to date with FLEX as a language! furthermore we assumed we had the server hardware already in place.

So in order to just get started with FLEX, we first have to outlay 24k USD for two licenses (we will need two production copies, one for eCommerce and one for internal). Then we will need to train our developers, lets say a team of 3 others on how to use FLEX as a language at around $3k AUD p.p. (based on the existing CFMX Fast Track / Advanced courses here in Australia). So that brings the tally up around 33k so far! Now we have to send them down to Sydney (as Flex trainers are only situated in Sydney at the moment), so that means accommodation and flights, luckily we are a tourism bureau and get cheaper deals, but none the less lets put that down to around 3k in total (meals etc).

Now heres the kicker, we spend a small fortune on hardware which could easily climb based on existing servers from 5k on wards, so lets just assume we spend 10k for 2 basic servers. Its now a hassle to get the IT System administrator to understand FLEX as a server entity, and get the appropriate monitoring systems in place, and overall preliminary training to our system administrators (as lets face it they will want to test it for security holes etc first). So lets just say over a year, we spend around 4k? in Human resource time and energy.

So right about now roughly we have hit the 50k (AUD) mark probably more.

So far we haven't even BEGUN the development of the projects. Its also going to be slow going initially as despite learning the language it still takes a developer a bit of time to understand what they have learnt fully.

As you can see the more you look into adopting FLEX the more you start to wonder if its really worth the "Saving time" solution. Add extra insult to injury, and pray you haven't got anyone within your organization that remembers Spectra as a product! (yes it too was kind of a "saving time / developer costs" solution and you will have an even harder time selling FLEX to your purchasing officer.

FLEX price impact.

Ok, lets be fair, regardless of what price FLEX sells at, it still will need those initial startup costs, but if you were to shave off 12k off that 50k price tag, it starts looking a lot better (i.e. sell FLEX for 6k) as we can slowly ease into the product without a major outlay of initial cash. Instead at 24k for just the server, management will want a faster return on their initial investment, and if you cannot deliver or they are too narrow sighted, it could cost you your job!

Now here comes the one crucial ingredient for in my mind, FLEX to truly succeed.

DEVELOPMENT COMMUNITY

I first learned of FLASH MX via communities like Blogs, and my local CFUG. I then switched from DHTML over to Flash MX, it hurt like buggery, but i ended up mastering Flash to suite my needs. I came from a web development agency background into an Enterprise level organization like Tourism Queensland.

Ignoring users like me (who at the end of the day end being on the yes/no decision group), in the end has no gain. As if you are going to ignore your existing bread and butter providers, the people who buy and user Flash/Coldfusion etc, then you are effectively asking for newer players to enter the field.

Is that a bad thing? no, not really, as hell we could do with some more smarties in the MX side of things.

Sadly though, in order to invite these new players, you first have to have a wider spectrum of users actually using the product and putting it out there for display. Flash Player by far should have illustrated this in that it started out as a nice cute player, but eventually small shop developers started to use it for more then just animation, they started making APPLICATIONS.

The Internet shifted, its role behind mundane animation into full blown 100% intensive flash based websites grew! we then asked for the ability to allow Flash to talk back and forth to products like Coldfusion, once again, small shop developers helped shape the products.

Now Macromedia have pretty much ignored these types of customers, and instead are setting there sights higher, more towards the fat cats of the industry if you will. In allowing them to shortcut their way into what it is we have been trying and screaming to do since day one, the ability to create rich Internet based applications with minimal time and effort.

FLEX current price model will make it impossible for a larger existing number of companies to build and deploy FLEX applications. This is a big risk for a large company as not only is it unapproachable for smaller projects in large organizations to afford it, it will also stifle what could be a vibrant FLEX based development community.

In the end this will piss a lot of the existing client base off, as lets face it, unless you have a ignoramus who doesn't know better or politically motivated person in the purchasing hot seat, many large companies will shy from its purchase.

IS FLASH/FLEX THE ANSWER?

Big question commonly asked, "can flash handle this..." in truth, if you are going after the Enterprise pitch, you can't walk in with "We are working really hard on the Flash Player to handle less CPU footprint and more data". You also can't expect the flow of FLEX to have restrictions on say tag nesting, or use taglibs 80% of the time, then revert to ActionScripting.

Nope, I'm sorry for 12k USD, I would expect a far more mature product. Its just pure silliness to ask such a bold price tag, for a product that is really at the end of the day immature. It still needs more features to make it reasonably attractive to large companies (i.e. Flash Paper for one), its also too solidly built around the V2 Framework, which many Java developers WILL find very annoying to use.

SUMMARY.
In all honesty, 2-6k USD would of been a far easier price tag for FLEX, as it wouldn't have the inflated ego it currently has, and lets face it we wouldn't place such a high demand on its capabilities.

To me, by putting a higher price tag on the product, its going to place itself on the chopping block every time a bug is found, or it can't do this or that, or its missing a feature resulting in a negative impact overall.

Not only that, if there aren't enough user base behind the product, the overall HR issue will be a big one at that, in that large companies will want to hire FLEX developers, and they will most likely be slim pickings if the market isn't strong enough in the development community at present (try hiring a CFMX programmer in Australia, you get a few resumes, but overall great and the good ones ask for loads of $$ - because they know they can)

It truly saddens me to see this fantastic product, be pushed aside due to Price tag, especially after all the work the MM Dev team put into it and i guess i despite this post having a negative FLEX feel to it, i do extend my appreciation to Libby and her co-Macromedians for the huge effort they put into the product. They did listen to our wishes and bugs, and Royale Beta 1 wasn't as sexy as FLEX currently is to day, and thats a testament to both the beta testers and the Macromedia team.

Its just frustrating as hell, to loose it due to some monkey somewhere in Macromedia decided they could squeeze a few extra dollars, to build a nice share price for this Quarter. I hope it was all worth it, and time will tell who is right and who are wrong.

Flex vs Other...

Product seems dodge? Ie would you walk up to management, armed with this product and simply ask "hey can we use this as the face for our entire server-side architecture? and give it to our existing stakeholders" - if you can, great use it, if you can't ...its a no brainer.

To me the reasons for FLEX existence in many ways is to entice Enterprise level corporations into adopting a quasi "thin client". In that, give a user a bare bones machine, and ask them to utilize the power of a networked application for day to day business. I can see the $$$ rackup in regards to savings associated with FLEX vs "other thin client" technologies, but it also has limitations *not just price tag*.

Firstly, we aren't really bringing much to the table all said and done are we? all we are presenting is a newer way to describe our a user interface works with a pre-set model? We are kind of trading in an existing proprietary solution for another in the hope we can maintain future proof for our business applications.

Typically in situations like this, a lot of web-top applications have been rolled in HTML mixed with JS/CSS (aka DHTML) to allow a shared and uniform approach to development of a concept, without constraints of a major support over-head (installations, versioning, licensing etc). Works a treat has its flaws (ie we just can't quite fully emulate client-top technology, but we are close) but the general purpose of FLEX to me is a "development nicety" to it. In that, it simply put; allows developers *no matter what size/skilled* to present a UI over a browser/exe wrapper over a large platform base. It boils down to fingers on keyboards, FLEX gives you a corporation the power to simply cut your man-hours down by allowing less code-monkeys punching out UI code and more business code (sometimes there is an overlap).

So comparing SnappMX to Flex, is like comparing a Porsche to a boat? both get you in places but each have limitations and different experiences.

I totally hate the price tag, mossyblog.com illustrates this, but i still consider FLEX to be a nice newbie to the world of XML flavored UI. Its mature enough to get some traction, in many ways it may just entice some Enterprise bean counters to the possibility of emulating "thin clients aka network computers" via a web browser, but it's still got a lot of work ahead of it. I'd bank on it for now, hopefully price models will change and it may open up to a wider audience *one can dream*, but if Macromedia are preaching it as a sales success, then that in turn means more investment being put into it does it not? which to me is a better bet (large team who can reach out and touch the flash player team etc seems a more comfortable bet aswell). So look past the product, look to what governs its development and how tangible the bankroll funding it is? Macromedia could go bust tomorrow, very unlikely but *could happen* but its a gamble worth taking.

Dunno, Fuel for thought in my opinion? if you have to ask yourself why should i buy flex vs continuing what I am doing now, consider its payoffs and letdowns and assess whether it is better then DHTML for example. Its got limitations aswell, but how many people still work in it daily? how many apps currently use it still and more importantly (despite its flaws), how will FireFox add to its weight? It opens up Mac potential? and you can still mix-it up 30% flash 70% dhtml? (grids, keyboard listeners etc) so what gains do you have with FLEX? If your a SOE IE for the next 3 years or more, is it a worthwhile investment still?

I hate the price tag, but i love the product and thats that :D . I am currently writing a CFMX/DHTML version of FLEX, its no way as sexy but the objective is to allow me and my team, future teams to use a series of CFMX based custom tags to deploy traditional web-top applications while maintaining there own UI presence. Its not even worth comparing against FLEX, but I'm not alone in this quest (how many other CFMX teams use XML to describe UI?) so people will look to other alternatives to FLEX, its just as simple as that.

Look at www.bindows.net ? yes its DHTML, yes it requires IE, but its attracting some developers to it, and in an IE environment it works pretty nicely (UI feedback etc).

Scott. http://www.mossyblog.com

Flex is hard to master

Since I am now in FLEX land (yay!) MossyBlog will no doubt have tonnes of FLEX based posts in the next few weeks. So bare with me as I retrace my steps with FLEX.

I've found FLEX hard to master, and I say that not in terms of the language but more on how do I use it effeciently and effectively.

Its been years since I've dreamed of being able to use a bunch of pre-built controls to shortcut a lot of my work via XML (the number of projects I've created and dropped from that concept alone is huge! - nearly 800mb to be exact) so now that I finally have it? how do I use it? In Flex you can do a number of amazing things with your UI and have been as of late finding myself emulating past UI done via HTML or extending the FlexStore concept further but in the end? It feels like all I am not using the product effectively.

See the purpose of FLEX for me was to make life easier for the user, not for the developer. I look at FLEX as a tool that can take a typical web application and transport it into this "thing" that is beyond its years, sort of a good hard look at the future of "Remote Applications". Yet, I still find myself using it much in the way of a typical web application today.

I've searched the web high and low for some UI concepts to steal (not graphically, just layout management) and I've got a handful of good concepts that i'll make use of, but I don't know, i need more inspiration in its use. I crave it, and now DEMAND it hehe.

I have thought many times of using my domain "Designersblock.com" to showcase not just the typical "Cool websites" but also "Cool User Interfaces", once that when you load up software you look at the UI more then what the software does! heh.

At anyrate, the art of mastering FLEX isn't about cutting code, its also got a large amount of User Interface Design and Development, as you can't use the excuses "well its a web-app" or "hey I can't do that due to technology limitations" anymore, as you have open slatter with FLEX (except your only limitation really is Screen size).

What FLEX cannot do.

I had lunch with an friend just before *cough* Darryl * cough*, and he mentioned that FLEX has XYZ limitations (valid ones at that). Got me thinking about throwing down the gauntlet and having a FLEX-off (hehe) where someone truly test FLEX against what it can and can't do.

Rather then doing that, instead in your own words - what can't FLEX do ?

My List so far:

* File Upload - Really this is more Operating System controlled anyway but none the less, its valid.
* DataLoad - In FLEX or Flash Player for that matter, you cannot present like 1000 rows of data inside a grid, instead you have to break it up into portions.

In truth thats the only two things i can think of at this point, feel free to share and lets see how well FLEX can FLEX its muscles

FLEX, its more of a guideline then a code.

I've been working on a framework guidelines for FLEX development, more so to do with how one uses coding conventions and overall separation/categorization of views within a FLEX application. In many ways, when developing in FLEX we simply label a portion of the code a "view" and leave it at that. We may name the mxml file according to its semantic value, something like "UserForm.mxml" may be a common occurrence.

To, me there needs a little more work in terms of understanding how you plan to separate your views and various other "parts" of the puzzle.

To do this, I took a few pages out of the Apple User Experience Guidelines and IKEA DIY kits.

Firstly, the Apple User Experience Guidelines is probably one of the most freely yet comprehensive XD docos online, and better yet its freely available. It help folks determine what type of "Dialog" windows they are using and keep an eye out for a lot of consistency. Remembering, that in FLEX world your in this mutated world of part-browser-ware and part-thick-ware, so traditional useability guidelines sort of hold but also don't?

So that helps in keeping your UI partitioning in check.

Another very cool, yet overlooked aspect of what we do in FLEX is that we can live out the dream of what XHTML was hinting at doing, in that we *CAN* if we want to, build our own xml based vocabulary that has correct semantic value in terms of describing our user interface. At present, I've seen quite a few folks wrap up a bunch of "Dialog" windows inside mxml files and leave it at that? but in truth, what separates them from one another? custom toolbars? custom icons? custom settings .. what I've personally done is laid out my MXML in such a way that at first glance within the tags, I know what I'm using. In no way shape or form have I got metrics in the main mxml files (i.e. why spend countless lines of code attaching marginTop or width="100%", I've simply extended the various tags and put in place autoMetrics capabilities)

On top of that, I can have tags like mb:SheetDialog or /mb:UtilityWindow instead of "ScottsSpecialWindow.mxml" so keep in mind, the framework is there for you to play around in, and I encourage personally extending the existing functionality

So how does IKEA fit into the overall equation? well not for the bloody blueprints at any rate.. no, I'm talking more in line with how they provide you with the pieces and allow you the "Furniture Engineer' the power of assembly. Can you honestly say that if you handed your code-base to another FLEX developer, they know where certain assets can be found? and in what areas they are used?

I guess from my perspective, I never under value the power of having a nicely formatted directory. If I need to access a dialog view, for the module "Invoice Tracking" wouldn't it be much more efficient to look in the /com/mossyblog/modules/invoicetrackingmanager/views/dialogs/ vs. /com/mossyblog/invoicetrackingmanager/views

Small thing, but yet easily accessible to the naked eye.

In a nutshell, I'm all for promoting the power of FLEX, but also the power you have to build onto FLEX in such a way that you can walk away with subset of the original language that has a some nice semantics upheld in terms of application descriptive code.

Don't gamble your career with FLEX 2.0.

It's not long now until FLEX 2.0 Framework gets dispersed amongst thine fellow developers, and there is going to be a lot of excitement surrounding any who reach out and touch it.

My advice is this, if you do plan on getting involved with the new "sexy" technology from Macromedia, be careful and don't gamble your current position on the product. FLEX may look easy on the surface (I mean its XML and JavaScripty style language, how hard can it be?) but in reality it will take a fair amount of learning to get a grasp of how it works and why it works in the way it does. Look at how things like E4X plays a role in the overall equation?

ActionScript 3.0 will also change peoples perception of how things have been done in the past and present (look at the ECMA docs now, and see how new syntax applies) so you will need to set aside a lot of time just for trial and error stages.

I say this out loud as I know many of you are looking to get the next XYZ product out the door in a FLASH format as it now gives a lot more potential in design and execution. Yes it will do that and more.

The Web Application Paradigm has shifted dramatically and with all new things, there is change and with change that requires learning. So if your upper tier walks up to you post its release and says the magic words "Lets build this in FLEX 2.0", what should your reply be if you are still new to it?".

"I'll get on it, but its new and requires some effort adjusting to its language and how to use it in a manner that's efficient"

FLEX 2.0 can offer dramatic increase in Rapid Development but *ONLY* after you *get* how it works.

Try and avoid frameworks for now, Cairngorm is a great step forward but unless you understand what the hell it does and what problems it does in fact solve, avoid it until you get on your feet and feel confident you can take on the next step, framework emergence.

I personally had a luxury with FLEX 1.0, I was given 6 months straight to "learn it", while working at Tourism Queensland. My old boss was fairly liberal in that regard as he could see the pay off in the end, a rare leader in this industry if you ask me.

I've been fortunate enough to be given a lot of time to immerse myself fully in the Macromedia technologies and even today, I have the luxury of time to simply sit down and study if I choose to. I say this as, most of you won't have this so don't feel as if you need to catch-up or pass us "beard strokers" in the learning curve. Take your time, don't take too many risks up front and just enjoy the new found luv, of that which is FLEX 2.0 suite.

I personally cannot wait to see what others do with the technology and with more people joining our small nit FLEX community, its going to be massive in terms of potential.

Remember, "go beyond the browser" (thats omniEffect's motto btw).

Did you know Adobe has a lot of power now?

It's true, it has a lot of power now and my biggest overall concern is how the hell will all this goodness be explained to the un-informed? Marketing strategies is more my forte now and I look around at the overwhelming technology centered on Flash.

It may surprise a lot of people, but I've recently been dumb founded by the level of ignorance centered on Flash outside the web-blog community in large, very large enterprise level companies.

It's still an unknown, not so much its existence but its overall use!

I've often had to start a rant off, by saying "oh yeah, flash is very powerful technology, did you know you can now ..." and trail off with some long winded rant about video and audio. I get glazed looks and often, skeptic's looking at me as if I'm some raving loon talking in a totally different language. One throw away reply, given to me was "Flash? No, sorry we are a Microsoft shop" - which left me worried.

I mention all this as despite the new toys we have, there is a lot of ground to cover in terms of marketing this product. It's no wonder we see a lot of folks comparing FLASH to AJAX, or downgrading Coldfusion as this "simplistic toy" and leave the conversation at that!

Marketing strategies tend to get overlooked in a lot of speeches from the Adobe camp, in that I've not really read or heard any conversation piece centered on how they plan to spread the wider message. It may be early days, but I'd like to see more information, as much as they can of course, on how they plan to market the technologies in the one breathe.

How do you spread the word about Breeze? Or Coldfusion and Flash working side by side? What about Flash Media Server 2 and Coldfusion? Adobe LifeCycle and FLEX 2?

One way, was to come up with a competition, which I guess on the surface looked appealing. Dig a little deeper and you find out its US and Canada friendly, outside these regions its "thank's guy's, but later..".

Adobe Australia have assured me, that there is something in the wind for Aussies, which is great but it wasn't just about getting my fellow countryman involved. No, I saw it more of as opportunity to get the world wide audience involved, see if we can un-earth some unknown(s) as to be honest, I'll actually be disappointed if the prize goes to some "graph" / "dashboard" RIA built by someone within the blog community who is already so well known it wouldn't come as a shock that they won.

I'm more inclined to see more new talent, see more radical theories applied and more importantly some living breathing prototypes on the table. In having these, the marketing burden can be slightly reduced and hopefully it will open more folk's eyes up to the power that Adobe holds now.

There is a lot of power, the real trick for Adobe is figuring out how to illustrate this in digestible form for all to see.

One strategy is they could steal some ideas from Oracle by creating a "Who Caught John Blade?" style approach to stringing the entire product range together. How about giving the folks at Nectarine some money and get them to extend the "Flash" character into a monthly cartoon for all to enjoy?

There is a lot more they could be doing, cheaply, to market the concepts to one and all? Yet it just seems overwhelming as to how.. I don't envy their marketing department that's for sure.