MXML vs. Actionscript
I had an interesting conversation this morning with a colleague, who is also a Flex/Actionscript developer, about how we end up using very little MXML when building enterprise level RIA applications. That’s not to say that we don’t leverage the classes that are encapsulated inside of the flex framework, but there is no question that 90% of our code is written in Actionscript. The other 10% are simple MXML files that have no purpose other than to instantiate our Actionscript components on the stage. I think as the Flex developer grows, evolution has it that he or she would move toward the use of Actionscript more than MXML.
A comment I made during this converstaion was that Flex/MXML was great for building little RIA “widgets” that use the built in flex components, which can all be skinned to your heart’s desire. However, it is definitely not well-suited for enterprise level RIA applications because there is too much flexibility (pardon the pun), where we often see programmers literally taking a framework (flex) and language (actionscript 3) that essentially forces you into some form of an object-oriented design, then flipping it on its back to where we see these mxml files that are reminiscent of procedural programming, complete with plenty of inline Actionscript and random switches from mxml to straight Actionscript and back again. This tends to be mostly due to a lack of knowledge on using events and multiple design patterns in a larger application, which takes a while to pick up.
Don’t get me wrong, Flex Builder is definitely the tool of choice for coding RIA applications, but I think the general rule of thumb is that any application that is more than just a “widget”, is going to end up about 80% – 90% Actionscript files and 10% – 20% MXML files. That’s a good way to tell right off the bat if an application is using abstraction and encapsulation of the client-side business logic and behavior versus strictly display. I’ll get more into layering applications in a later blog. For now, here are a few books worth taking a look at if you’re a flex developer on a journey toward learning how to build large-scale RIA apps. All books I recommend are from my personal collection, and I never recommend a book that I haven’t read in its entirety. In other words, I’m not trying to make some cash off an Amazon affiliate program here.
There aren’t too many out there yet on more advanced subjects in Actionscript 3.0, but these 3 will surely help you take it to the next level. Note that the first one I am listing, I attribute some of my most valuable learning to this book and I strongly recommend it to any Actionscript developer aspiring to be an expert at their trade:
AdvancED Flex Application Development; Building Rich Media X
Authors: R Blank, Hasan Otuome, Omar Gonzalez, Chris Charlton
Publisher: Friends of ED
Amazon Link
Actionscript 3.0 Design Patterns
Authors: William Sanders, Chandima Cumaranatunge
Publisher: O’Reilly Media
Amazon Link
Object-Oriented ActionScript 3.0
Authors: Peter Elst, Sas Jacobs, Todd Yard
Publisher: Friends of ED
Amazon Link
Possibly Related Posts:
- Flash Camp Phoenix a Huge Success
- Best Drunk on Software Episode Ever
- Enterprise Flex and the Swiz Framework Architecture, Part 3: Using Autowire and Mediate
- “Flex 4 in Action” (Early Access Edition) Now Available!
- Designing (RED)Wire, Part 3: Advanced Styling Methods for Enhanced User Experience with Adobe Flex and AIR
Posted by Dan Orlando on September 29th, 2008 :: Filed under General
Tags :: Actionscript, design patterns, enterprise applications, Flex, flex vs actionscript, mxml, object-oriented programming, OOP, RIA development
You can leave a response, or trackback from your own site.
March 29th, 2009
Good Article
Can you clear me one thing,which one is better one MXMl or AS when considering Performance?
March 31st, 2009
Well, neither is better when considering performance because MXML compiles to ActionScript classes before it renders to bytecode to run in the Flash Virtual Machine. That is why a Flex application (SWF) can be decompiled, but you will only see the ActionScript classes. Look at it this way, MXML is simply a convenient way of declaring ActionScript objects using a custom XML namespace. So whether you are building in MXML or ActionScript, the end result will ALWAYS be ActionScript.
April 23rd, 2009
Great post! I’ve been scanning the web for quite some time trying to get a hold of how to use MXML and how not to use it. I’m still not convinced that there’s any need for it at all… Could you please ellaborate on what the “10%” MXML of your apps really do? Is it used for view layouts?
I’m trying to find out how to reach maximum productivity (claimed to be found using Flex/MXML) and still maintain solid and good code in your RIA… Any other thoughs on this?
Thanks!
April 23rd, 2009
[...] together with AS code. I’ve scanned the web for articles, and have found a few interesting. This one, by Dan Orlando, seemed to be on the same track as myself. Also, I’ve previously come across [...]
April 27th, 2009
Kristofer, I read your entry on your blog, which I was able to find from the track-back that links here that you included. You seem to be on the right track. Allow me to first encourage you to keep exploring; the more you develop applications in Flex and as long as you always approach them with an architectural strategy, what you will find is that it will become obvious when you should use MXML and when to code in AS. Generally speaking, MXML becomes most useful at the view in the MVC architectural pattern. Since you are able to make object declarations and bind to properties that are available through getters and setters, it opens up a whole new paradigm in design patterns (which is good ONLY if it is used to increase simplicity, as opposed to complexity).
If there is one thing you take away from this, I would want it to be this:
When you make an MXML declaration, all you are doing is instantiating an ActionScript Class.
If you think about that for a moment, and I mean really take some time to understand that statement – all of a sudden you will be able to see how MXML can increase productivity when used in the proper context (most often at the view layer, but this is by no means a rule) and it will become a natural instinct to know when to create a new Actionscript class or interface; versus a new MXML component, module, or application.
May 14th, 2009
Hi again Dan,
Thanks for your last post!
I’ve been messing around a bit more with MXML and Flex in a little project at home. It feels like I’m getting the hang of it, actually. Of course, it’ll take a little while to get comfortable with the available tags, but that’s just a matter of time.
I guess I know the answer to this is “no”, but do you see any downside of mixing your view classes; some as MXML and some as pure ActionScript? Could it make the code base more confusing?
I suppose it shouldn’t, as you pointed out; MXML is really the same thing as an AS class…
Regards,
Kristofer
May 16th, 2009
I’ve never had any problems mixing AS and MXML on the view layer. It really depends on your personal preference though. Often AS view classes are supporting classes to MXML files, like “helper” classes or “factory” classes. However, many times I have coded “item renderers” as AS rather than MXML because for some reason every time I have to put together a list-based component, the requirements for what is shown in the list is consistently unusual, and always requires the flexibility of coding the renderers in ActionScript…that has only been my experience though, and is only because the requirements I always get are so outlandish.
In most of the Flex books, you’ll find that the author will usually do something like mash an image and a label together in an mxml file as the itemrenderer, for example, so in response to your question, either way is usually fine and does not cause a problem for managing the a large code base.
September 29th, 2009
[...] together with AS code. I’ve scanned the web for articles, and have found a few interesting. This one, by Dan Orlando, seemed to be on the same track as myself. Also, I’ve previously come across [...]
October 18th, 2009
Hi again Dan,
Hope everything is well! Some time has passed since our discussion and I’ve learned quite a lot since. I’ve made a blog post on this matter that I hope you’ll find interesting:
http://blog.sommestad.net/2009/10/presentation-on-how-to-evolve-in-development-of-large-flash-applications
Regards,
Kristofer