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 Mon, 23 Apr 2012 13:14:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: BrianbishopIreland http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/comment-page-1/#comment-24621 BrianbishopIreland Tue, 23 Nov 2010 17:51:00 +0000 http://troygilbert.com/?p=122#comment-24621 If the values are being referenced in the mxml, they will have to be in {} e.g. {model.currentCard}, and this doesnt allow for ctrl+space for intelliSense anyway. Also, this will compile even when 'model' is in a seperate source file, its only a problem if the file is run and the source is not available If the values are being referenced in the mxml, they will have to be in {} e.g. {model.currentCard}, and this doesnt allow for ctrl+space for intelliSense anyway. Also, this will compile even when ‘model’ is in a seperate source file, its only a problem if the file is run and the source is not available

]]> By: BrianbishopIreland http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/comment-page-1/#comment-24622 BrianbishopIreland Tue, 23 Nov 2010 17:51:00 +0000 http://troygilbert.com/?p=122#comment-24622 If the values are being referenced in the mxml, they will have to be in {} e.g. {model.currentCard}, and this doesnt allow for ctrl+space for intelliSense anyway. Also, this will compile even when 'model' is in a seperate source file, its only a problem if the file is run and the source is not available If the values are being referenced in the mxml, they will have to be in {} e.g. {model.currentCard}, and this doesnt allow for ctrl+space for intelliSense anyway. Also, this will compile even when ‘model’ is in a seperate source file, its only a problem if the file is run and the source is not available

]]> By: Jamie http://troygilbert.com/2008/08/how-to-get-rid-of-mxscript-blocks-in-your-mxml/comment-page-1/#comment-24610 Jamie Mon, 11 Oct 2010 10:34:00 +0000 http://troygilbert.com/?p=122#comment-24610 I like the concept behind this approach, but how would it work practically? I mean, any components set out in your mxml aren't going to be referencable in the as file version, are they? I like the concept behind this approach, but how would it work practically? I mean, any components set out in your mxml aren’t going to be referencable in the as file version, are they?

]]> 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.

]]>