I think I’m the only Flex developer out there that doesn’t like code behind or <mx:Script> blocks. So I have my own way of doing things. What can I say? I’m a cowboy! ;)
I frequently code event handlers inline like:
<mx:Button> <mx:click> // do something // do something else </mx:click> </mx:Button>
I just don’t like having to find code that is only used in this one place somewhere else. This method is just more readable to me.
But there are times when you have some view logic code that needs to be reused within an MXML file. Many of us would typically put that code inside a <mx:Script> block or in a separate AS3 file (code behind). But I just don’t like either of those. When I code in MXML I like all my object instantiations to be declarative. I recently discovered that you can also define functions in MXML. (Of course the contents of the function is still AS3 and not declarative.) To do this you just use the <mx:Function> tag. But it’s a bit finicky. Unlike inline event handlers these must have a CDATA wrapper and you must still wrap the function. Here’s an example:
<mx:Function id="doSomething"> <![CDATA[ function():void { // do something // do something else } ]]> </mx:Function>
This is not as much of an improvement in readability over a single giant <mx:Script> block but I believe it is slightly more readable because there is a clear delimiter between different functions.
Call me crazy for not shoving all my AS3 code into a single place in MXML files. But I do think inline event handlers and declarative function definitions lead to more readable code.
BTW: I do still usually have a <mx:Script> block but it only contains my imports.
16 Comments
Freak. I still like you, though!
Dude, that’s tripped out. I think when I’m feeling in the flex experimentation mode Ill use this!
I’m not sure about this one. The fact that you have to declare two function declarations (one for mxml and one for AS) goes against the DRY methodology.
One is the identifier and one is the actual function. Kinda like when you say
var foo:Foo = new Foo();Foo is repeated. Personally I would totally prefer to only sayvar foo = new Foo();like in Python or Scala. But AS3 doesn’t give us that option (at least if you want to actually type the object).To quote Jerry Seinfeld, “I don’t want to be a cowboy.”
beautiful. I love it. You’re not the only one who doesn’t like code behinds (they sometimes have their place). The tag just makes everything . . . prettier. And I have never thought to use an action node for my logic. I love it. It may not be “convention” but I think my code is gonna look a bit different now.
Yeah, you are the only person I know, that codes purely in MXML. Respect though!
@Joseph
Haha. :) I do also write a ton of AS3.
Wow, have never seen that one before. In writing Chapter 7 of our Professional Flex 3 book, I thought I covered all the permutations of MXML and AS3 possible in one file. Good catch!
Yeah never knew you could do that. Not sure I will ever implement it, but nonetheless, nice to know.
Never seen a cowboy wearin’ glasses, if you catch my drift.
Nice! Love to see such a casual post generate so many comments.
I’m tagging this as ‘Not that i would, but nice to know i could’.
props
You can also reference an external AS file in the mx:Script tag, which makes the MXML cleaner – although that pushes the behaviour code further away (good for re-usable funcs tho’) – problem is ASDoc seems to barf on that style of programming ..
Maybe I’m missing something, but doesn’t this make the function anonymous? Meaning, no code hinting helping you to remember the actual signature of the function.
God I miss C#’s delegates. In fact, if I may digress, I miss the event architecture of C# altogether. I feel AS3 events are limited at best with their inherent dependance on strings (seriously, what is up with that?) and what not.
@Marcus Stade
You are right. This does get wrapped up in an anonymous function so code hinting and a few other things unfortunately break. In my uses those things didn’t impact me so I kept doing it. :)
Thanks for letting me know about C#’s delegates. I’ll have to check those out.
-James
Your no freak, I have been doing it like that for a while now OR we are both freaks. I tend to use inline and declarative functions in non implementation specific(re-useable) view components where the inline / declarative functions only contain behavioural logic for the component itself. I usually then extend the view component in real world use and provide implementation specific logic elsewhere … usually in a controller. Its good to see how other people like to code.
One Trackback
[...] Declarative Function Definitions in MXML (from James Ward – RIA Cowboy) [...]