Why should you use MXML? Given that Flex Builder doesn't require the use of MXML, why not write everything out in Actionscript, especially if that's what you are used to?
I was asked a question like this recently, and I'm sure others have asked similar questions. I expected to find a simple answer in searching, but I could only find more general articles. Did I miss an obvious post or page?
I wrote parts of the answer below and then expanded on it for everyone to read. I've grown so used to using MXML with Actionscript that I had to think about my answer for a bit to express what I now take for granted.
Here's the advantages I see in MXML:
1. The declarative nature makes it a lot less verbose for setting up visual components, and it's easier to picture the layout. A Canvas within the Canvas can easily be seen in MXML, while addChild() scripting is harder to visualize.
2. It's easier to separate your view code from the rest of your code. MXML is almost completely visual components, which solves the V in MVC.
3. There's a lot of shortcuts and syntactic sugar in MXML to help in writing code. Styles can be put into CSS, and styles and events can be set as attributes. Embeds (and the other @ directives) are less verbose than the equivalent Actionscript metadata. Binding with curly brackets is easier to write and read.
And here's a few potential reasons to not to use MXML:
1. You aren't using any of the Flex framework classes. I don't agree with this one, personally, as you still get the benefits mentioned above.
2. You're creating a super small widget, and the size of your application will be slightly bigger with MXML. I believe that MXML will add a very small amount of size, due to some generated code, but I don't know the exact amount.
3. You want to use all of your code inside of Flash Authoring. There's an emphases on the word all here. Often you can separate out your utilities or components in ActionScript and still use MXML in places.
Comments (7)
Hello, really interesting article I'm new in flex, could you please be more details with example of simple application ex. form with a couple of buttons, Labels, one MXML, in pure As3.
Thanks in advanced,
Could be a part II from this article,
Thanks,
Tom
Posted by Tom Adler | April 23, 2007 5:37 AM
Posted on April 23, 2007 05:37
Quoting Ted Patrick:
"Over time I have come to appreciate the subtleties in MXML and ActionScript as they work perfectly together. The twist comes when you realize that there is no different between MXML and ActionScript 3 classes, they are just classes and are 100% interchangeable."
Ted on flex:
http://www.onflex.org/ted/2007/02/code-behind-in-flex-2.php
Posted by creacog | April 23, 2007 11:11 AM
Posted on April 23, 2007 11:11
"1. You aren't using any of the Flex framework classes. I don't agree with this one, personally, as you still get the benefits mentioned above."
If you aint using the Flex framework, then you wouldn't be creating a Flex project and therefore you couldn't use MXML. You cannot use MXML with anything but Flex projects.
"2. You're creating a super small widget, and the size of your application will be slightly bigger with MXML. I believe that MXML will add a very small amount of size, due to some generated code, but I don't know the exact amount."
Again you probably wouldn't be using Flex for something very small that you were concerd about the filesize, as any use of Flex requires the framework and the filesize that comes along with it.
"3. You want to use all of your code inside of Flash Authoring. There's an emphases on the word all here. Often you can separate out your utilities or components in ActionScript and still use MXML in places."
One of the biggest things against MXML for me is that everything you reate with it has to be public, which isn't good!
You cannot use the Flex framework inside Flash.
Reason 1 for using MXML is a good point. Reason 2 is not really true, you could just as easily seperate your view code fomr logic if you used AS alone.
The main reason for using MXML is the speed gains in development it gives. MXML is a lot quicker to write and therefore productivity is increased.
Try creatting 2 classes the same in MXML and AS. You will write a lot less code in the MXML class.
Posted by Tink | April 23, 2007 11:51 AM
Posted on April 23, 2007 11:51
Sorry i put this is the wrong order
"You cannot use the Flex framework inside Flash."
was my answer to reason 3 of why not to use it and...
"One of the biggest things against MXML for me is that everything you reate with it has to be public, which isn't good!"
Is the crappest thing about MXML.
Posted by Tink | April 23, 2007 11:57 AM
Posted on April 23, 2007 11:57
Tom, that'd be a good page to have. I don't have time for this myself, but I'd be happy to link to anybody who creates this.
creacog, take a look at the output from the "-keep" compiler option to get an idea of what's going on in MXML. An AS class is being created, but a lot of code is autogenerated for you in MXML.
Tink, I'm positive that we had non-framework support in 1.5, and I thought we allowed Sprite or something similar to be the base tag in Flex 2. Are you positive this isn't the case?
You can't use the Flex framework SWC in Authoring? I didn't know that, but I haven't dealt with it. That's too bad.
That's interesting that you consider the public variables to be the biggest problem with MXML. Since I generally just put visible components in the MXML, I haven't been too bothered by this. It's something that I think is fixable, from the compiler's point of view, although not a simple fix. It's definitely something to keep bugging Adobe about. :)
Your public variable comment reminds me of one of my problems with using MXML as components, which is that I don't have a constructor with arguments or any other way to hint to the compiler that certain attributes must be set. I have let Adobe know about this request.
Posted by Brian Deitte | April 23, 2007 6:19 PM
Posted on April 23, 2007 18:19
I say that anything defined in MXML being public is the biggest problem as it totally defies the point of having anything else internal, protected or private.
Lets say you have a class that defined a few DataGrid's a ComboBox and a List. These are all defined in MXML and are therefore public.
You then write a load of code that is private/protected etc to get these to work and display the content u want.
I then access the components from somewhere that i shouldn't and bugger all your work that is private/protected etc up.
Posted by Tink | April 26, 2007 9:07 PM
Posted on April 26, 2007 21:07
I'd have to say that I have grown in my love for MXML vs. AS.
1) I started using different states for item renderers and utilizing the {} on the data property. This has become a breeze now. I will be posting on my blog shortly about this. Not a GREAT reason why to use it over AS but thought I would throw that out there.
2) Implementing accessibilities via MXML is so much easier as generally the complexity of what is READ vs SEEN is much greater. This means to implement and UPDATE that data for a screen reader becomes a lot more code in AS. Again I will be posting on this on the blog soon too.
A few things that I don't like about MXML
1) Like Tink, I hate the whole public thing. Mainly for the fact that when I go to seeing all the properties listed in the code hints popup (what is this called BTW?) I see all the internal view stuff for that instance. That just pisses me off really.
2) Setting default class styles WITHOUT overriding the default styles css seems difficult to do in MXML
3) The rest is piddly complaints but A) you cant organize your scripts' imports B) no property linkage between an MXML file and its script's source AS file. I could go on.
My general rule of thumb is this: If you are making a VIEW, as in a page then I would go for the MXML approach because it allows easier visualization of the layout. If you are making a component to be reused, then I suggest going the AS route, unless it has a complex layout itself.
Posted by jwopitz | May 22, 2007 4:28 PM
Posted on May 22, 2007 16:28