MXML allows you to create and change visual components very quickly without a whole lot of nonsense. Of course you could write everything in AS3, but that logic leads us to writing applications in asm, which no one does. Most importantly, components "out-of-the-box" lend themselves better to the changing world of requirements as opposed to hand written stuff.
In your description of your application, I didn't really see anything that would say "Don't use MXML". Flex apps using MXML are used to do all of the above and much more, you should checkout Tour de Flex and look at the source code.
PS. The two technologies aren't mutually exclusive, MXML compiles down to AS3, you can use the keep-generated-something-I-forget option to see what it is actually doing.
Well... you make a strong argument!
I downloaded Tour de Flex so I'll check that out.
So... in my case, I guess I'd build out the framework in MXML, then dynamically populate/turn on/off objects in AS3 after the fact then? I'll give it a go and see how that works out for me.
1 person found this helpful
an important point to remember is that MXML IS ActionScript - just written in a different form. When you compile a flex app, the MXML is converted to AS and then the AS is compiled. (if you add -keep-generated-actionscript to the compiler options you can see all the AS files that are created)
Oh yeah, I'm aware of that but thanks for the reminder! I'm just thinking about how to write out all the code. Is that normally how it's done? MXML skeleton then use ActionScript in another file to do all the logic for it? Or would the ActionScript be included in the same MXML file?
Guess I'll have to get started on the tutorials!
I still like the idea of writing it all in pure AS3 but... guess I have to get with the times.
Thanks for all the input!
you can include the AS inside a script tag in the MXML file but yeah, its best practise to seperate the logic into another file.
as a side note, if you are doing mobile work then its best to avoid MXML as much as possible (for performance)
1 person found this helpful
There's a method called "coding behind" which tends to be the thing that gets touted when working in Flex the most and one that's work googling. I think the key here is what Ubuntu Penguin was talking about - the visual side of stuff. If you're using sub-classes of Flex components for your on screen components use MXML. You can code in Actionscript inside those files, you can use AS3 interfaces in MXML files as well (using implements=), and you can sub-class. So you basically get everything you get in pure AS3 anyway, with some minor overhead from what the Flex Compiler needs to do (the major overhead being the actual Flex framework code itself!).
However, for all you backend stuff (remote objects, xml reading and generation, and all the non-visual stuff) I would stick with custom classes in AS3. Do remember though there is a "gotcha" with events in custom classes - if you want them to bubble you will need to do the bubbling yourself! Taking that into consideration though this is the path that I've adopted and that I would reccomend.
mick.powell wrote:Do remember though there is a "gotcha" with events in custom classes - if you want them to bubble you will need to do the bubbling yourself!
..that's news to me. It matters not whether you have custom classes or any other class - events work the same way.
Sorry - let me qualify that - "custom classes that are not part of the
display object hierarchy". Eg Create you own custom class that doesn't
extend anything but that Implements iEventDispatcher - Create another class
that will be a child of the first (again implementing IEventDispatcher) -
fire an event using dispatchEvent on an instance the child class - the
instance of the parent class will not get the event, even though you have
added a listener and the event is bubbling. Unless something has changed
recently, that has always been the case.
And by "added a listener" I mean added a listener to the parent - not the