Reputation: 1294
Just wanted to ask about what to do when using as includes (ie <fx:Script source="includes/my_as3_file.as" />
.
The problem is that in all of my files I'm using class-only modifiers, such as private, public protected, and FB sometimes protests regarding these. A friend told me that what he does is changing the file extension to .ias, but in this way, he loses code highlighting, content-assist and enabling breakpoints.
Thanks.
Upvotes: 0
Views: 2240
Reputation: 3285
I like to use something called a ViewHelper (posted a link)
http://www.kensodev.com/2010/08/19/keep-your-mxml-files-neat-with-view-helpers/
This way, the MXML file is pure MXML at all times, and the view helper is coupled and has a reference to the view meaning you can do something like this in your view helper
myView.dataGrid.visible = false;
And of course many more things.
Even when I use RobotLegs's mediators, I still use the view helper for all actions that concern the view such as animations, hiding and shoeing things, state changing and more. I use the mediators only to mediate with the RobotLegs framework (re-dispatch events) and listen to the eventDispatcher.
Upvotes: 2
Reputation: 4340
<fx:Script source="MyViewAS.as" />
Upvotes: 1
Reputation: 1
Renaming the .as file to .ias, in my opinion, is one of the worst solutions one can come up with ( it's just horrible ). I also kinda disagree with Marty, because in Flex 4, the architecture is different from Flex 3 ( although Spark is built on top of MX - if we were talking about Flex 3, then I'd agree with what Marty said ). In Flex 4, the Skin is now considered to be the "View" and class making use of the view is the "Controller"... meaning that things are now much better separated than they were in Flex 3, where a components kinda played the role of both the View and Controller ( http://www.slideshare.net/saurabhnarula/flex-4-skinning-2634949 ).
Coming back to the original problem: It's true that Flash Builder is not perfect, but if you know that you don't have any errors in your code and it keeps on throwing some weird stuff at you, then simply try closing it and starting it again ( Clean your project afterward ). Whenever I set an .as file as the source for my MXML component, I like to have the file next to the MXML class ( ex: MyMXMLComponent.mxml and MyMXMLComponentAS.as, both being at the same level - source="MyMXMLComponentAS.AS" ). This 99% of the time works fine, but really rarely, I might have also received some weird errors from Flash Builder ( which usually got solved by closing it and cleaning the project afterward - on a couple of occasions, there was actually an error in my code which seemed to totally confuse/crash the compiler and make it throw some really senseless error messages, so definitely try to make sure that your code is correct ).
Personally, I'd suggest that instead of using .as files, you try to use the "code behind" approach ( search on Google / Adobe for more info on this - I wanted to post a link, but since I'm a new user, I'm limited to 1 link / post... hah ). Using code behind, you will surely never run into the problems you might run into with .as file and you will surely never have problems with code hinting. In case you have never used code behind before, then it might feel "strange" at the beginning, but you'll get used to it and you'll surely not want to write code "the old way" ever again.
Upvotes: 0
Reputation: 29290
Personally, I'm not a fan of using includes. As you've mentioned, it tends to obfuscate what's actually going on within a view, and makes it difficult to quickly scan a file and grok it's behaviour.
One of the best practices I've always followed is to reduce the amount of code within an <fx: Script />
block to almost none.
If you are using an include file, this suggests that your views are very script-heavy, which can lead to poor code reuse, and difficulty in writing testable code.
Instead, consider using the Presentation Model pattern where the logic is moved out to a separate class. Alternatively, there's also the Mediator pattern, however personally I've found this leads to more heavily coupled code - though that's likely down to my crappy execution, than a failing of the pattern.
Upvotes: 1