Comments on: How to get rid of mx:Script blocks in your MXML http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/ Gamedev 2.0 Fri, 19 Mar 2010 13:45:59 -0700 http://wordpress.org/?v=2.9 hourly 1 By: Troy http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/comment-page-1/#comment-9128 Troy Wed, 11 Feb 2009 00:04:28 +0000 http://troygilbert.com/?p=122#comment-9128 The contents of the mxml.as file are a cut-n-paste of what you'd normally have between the <mx :Script> blocks.</mx> The contents of the mxml.as file are a cut-n-paste of what you’d normally have between the blocks.

]]> By: Rob http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/comment-page-1/#comment-9127 Rob Tue, 10 Feb 2009 23:53:14 +0000 http://troygilbert.com/?p=122#comment-9127 Thank you! This is exactly what I was looking for, and you are right about this topic being one that isn't really google friendly! I haven't actually tried this yet, but as I read this I'm wondering what the actual code block inside of the mxml.as file is...is it a package? Thank you! This is exactly what I was looking for, and you are right about this topic being one that isn’t really google friendly!

I haven’t actually tried this yet, but as I read this I’m wondering what the actual code block inside of the mxml.as file is…is it a package?

]]> By: Troy http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/comment-page-1/#comment-7736 Troy Tue, 23 Dec 2008 21:09:39 +0000 http://troygilbert.com/?p=122#comment-7736 Odd... in a recent project, this failed to work for me. Perhaps the Flex IDE gets confused at a certain scale of project? In test projects, the aforementioned splitting and importing worked like a charm (code-hinting, etc.), but in a recent larger-scale project it didn't work at all. Hurumph! Odd… in a recent project, this failed to work for me. Perhaps the Flex IDE gets confused at a certain scale of project? In test projects, the aforementioned splitting and importing worked like a charm (code-hinting, etc.), but in a recent larger-scale project it didn’t work at all. Hurumph!

]]> By: Troy http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/comment-page-1/#comment-7735 Troy Tue, 23 Dec 2008 21:07:17 +0000 http://troygilbert.com/?p=122#comment-7735 I like the convenience of having the AS and MXML in the same file, but don't like some of the artifacts -- most of them faults of the IDE. There's also the argument that strictly speaking, mark-up (declarative) and code (imperative) should be distinct units. I like the convenience of having the AS and MXML in the same file, but don’t like some of the artifacts — most of them faults of the IDE.

There’s also the argument that strictly speaking, mark-up (declarative) and code (imperative) should be distinct units.

]]> By: Tony Fendall http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/comment-page-1/#comment-7693 Tony Fendall Wed, 17 Dec 2008 20:52:09 +0000 http://troygilbert.com/?p=122#comment-7693 I think the one thing people miss in these discussions, is the advantages of having related bits code close together. I personally like the fact that my components and the code which directly interfaces with those components, are both in the same file. It makes it easy to develop without having to switch back and forth between multiple files as I go I think the one thing people miss in these discussions, is the advantages of having related bits code close together.

I personally like the fact that my components and the code which directly interfaces with those components, are both in the same file. It makes it easy to develop without having to switch back and forth between multiple files as I go

]]> By: Troy http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/comment-page-1/#comment-6052 Troy Mon, 01 Sep 2008 22:00:21 +0000 http://troygilbert.com/?p=122#comment-6052 Doubling the amount of files is not a big deal because that's the simplest granularity to work with version control at. If you're working solo, then yes, it can be unnecessary, but in a team environment it wouldn't be too much of a burden. And even with good MVC practices, you can still have scenarios where you have plenty of declarative MXML and plenty of imperative AS3... for those situations, this can be useful. Doubling the amount of files is not a big deal because that’s the simplest granularity to work with version control at. If you’re working solo, then yes, it can be unnecessary, but in a team environment it wouldn’t be too much of a burden.

And even with good MVC practices, you can still have scenarios where you have plenty of declarative MXML and plenty of imperative AS3… for those situations, this can be useful.

]]> By: ryan miller http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/comment-page-1/#comment-6010 ryan miller Sun, 31 Aug 2008 21:15:17 +0000 http://troygilbert.com/?p=122#comment-6010 yes, but now you've doubled the amount of FILES in your project, which I would find annoying. I've never even considered the script block in my MXML to be a big problem. Maybe because I've always used some kind of MVC framework, it's never gotten out of control. Also, if your script block is getting huge, that's a good indicator that you need to break up your MXML into sub-components. yes, but now you’ve doubled the amount of FILES in your project, which I would find annoying. I’ve never even considered the script block in my MXML to be a big problem. Maybe because I’ve always used some kind of MVC framework, it’s never gotten out of control. Also, if your script block is getting huge, that’s a good indicator that you need to break up your MXML into sub-components.

]]> By: Troy http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/comment-page-1/#comment-5974 Troy Sun, 31 Aug 2008 02:32:28 +0000 http://troygilbert.com/?p=122#comment-5974 You're right, it is just a plain old text import, not a distinct compilation unit. The cool (and unexpected) discovery is the fact that the Flex Builder editor considers the import and does the appropriate context auto-complete. You’re right, it is just a plain old text import, not a distinct compilation unit. The cool (and unexpected) discovery is the fact that the Flex Builder editor considers the import and does the appropriate context auto-complete.

]]> By: Patrick http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/comment-page-1/#comment-5973 Patrick Sat, 30 Aug 2008 23:00:04 +0000 http://troygilbert.com/?p=122#comment-5973 It does seem to good to be true. Coming from more of a layman's perspective, it seems like a simple code importing like you'd see in C . Seems like it should work, no? It does seem to good to be true. Coming from more of a layman’s perspective, it seems like a simple code importing like you’d see in C . Seems like it should work, no?

]]>