There’s been a whole lot of talk recently about code-behind on flexcoders, blogs and on IM. There’s lot of differing opinions and I thought I’d throw mine out there.
The idea of code behind is the seperate the logic from your UI. This sounds like a great idea in concept but in practice I’ve not found it to be that useful. I’ve experimented with various ways of implementing it and all of them make the code more difficult to manage (I generally find I have 10+ files open in Flex Builder at one time and any implementation of code behind doubles the amount of files). You end up switching between tabs just to develop one component.
The idea of seperating the two comes from having someone do your UI and someone else building the logic but, it just really isn’t the case that your going to have a designer doing your UI in Flex Builder. If they did, why the hell would they mess around with any of your code in a Script tag anyway?
I also don’t see why the great believers in code-behind don’t take this a step further. You could think of the code behind as your controller for your UI. All components required a UI and some logic, but that logic also requires some data, so why not have the UI, the controller (logic) and a model (data). Obviously this would result it three times as many files, and therefore more files to manage and constantly switch between.
So after me stating that I don’t find it that useful, thats not to say that it may never be useful, so lets have a look into the ways that it can be implemented.
The most common way I’m seeing code behind is using inheritance. Ted has a good description of this method. In my opinion, and from what I’ve picked up recently this isn’t code-behind. We can clearly see this is inheritance and inheritance isn’t code-behind, it’s inheritance. We all know that we can only inherit (extend) one class and therefore any ‘proper’ inheritance ends up being untidy.
Lets say we have a Accordian written using this method, we would have a Accordian.mxml that extends AccordianFunc.as. Eeek, immediately we can see a fallback here that we can’t name the files the same.
Lets extend this Accordian to change the UI and also add some new functionality. We now have a CustomAccordian.mxml file that extends CustomAccordianFunc.as. CustomAccordianFunc.as extends Accordian.mxml which extends AccordianFunc.as. Now although in theory we know CustomAccordian.mxml extends Accordian.mxml we can’t see this becuase we have been forced to extend CustomAccordianFunc.as to achieve our code-behind.
Using inheritance for out code-behind is making our code less readable. Ted points to this example in ASP.NET. I’m going to be as bold to say (yes I never learn) that if ASP.NET developers are forced to use inheritance for code-behind it because the language doesn’t really support code-behind.
Interestingly enough, if you wanted to use this inheritance method, the idea is to isolate code from the UI or designer, it would make more sense for the logic to extend the UI but this sound more like code-in-front! But then our CustomAccordian.mxml would have to extend AccordianFunc.as.
Code-behind in C# (I’m told) is about making partial classes. Now this sounds more like it! It sounds like code-behind has been considered here and there is a method to implement it without affect inheritence. Flex 2.0 also supports partial classes using the ‘source’ property in a Script tag.
Lets go back to our accordian example. We would have Accordian.mxml, with a Script tag and source property pointing to our accordian.as. Notice our accordian.as is lower case as it is not a class, and therefore we can name the files the same (except the case of the first character). This sounds a cleaner method already.
Lets extend this Accordian. This time we really can extend Accordian.mxml and it will be clear from looking in out CustomAccordian.mxml class what it extends.
This is code-behind! There is one class, and some code behind it providing logic, not 2 classes!! From within our CustomAccordian.mxml class we can clearly see what the superclass is, and we can also see where the logic is defined, and from looking a glance at our navigator we can see that they work together because they have the same name, they sit together because they have the same name, we can see which is the class because the first character in its name is uppercase and we can see the code-behind (not another class), because the first character in its name is lowercase.
If you can find a designer that isn't capable of scrolling past your script tag or is confused by some script in their MXML file, but its capable of using Flex Builder to build and skin UI's, does it make sense that he has to look in your class to find out what container or component your extending? No. It makes more sense for you to let then choose what they want to use as their base class (inheritance), and that you just add in code-behind using the script tag and its source property.
The point is that the view will be closed for publishing and designers will not have as much to sift through. From a developers point of view it’s so much more flexible. Are you really that worried about the amount of files?
I undertsand the point
“The idea of seperating the two comes from having someone do your UI and someone else building the logic but, it just really isn’t the case that you going to have a design doing your UI in Flex Builder.”
but I’m still yet to work with anyone who’s proficient enough to use Flex Builder but not capable of coding.
In my experience a designer designs in Flash, PS or Illustrator. Its then a very quick job for the dev to throw these components together in MXML (personally i find script view so much quicker than design view), and then add the logic to hook it togther. It would then be up to the developer to skin these components with either scripted skins or assets provided by the designer created in the programs mentioned previously.
I’d be ineterested to work with a designer who is proficient in laying out MXML and skinning the UI to look as they want though. But if they were effiecient in that, they would have some understand of Flex and wouldn’t be silly enough to start editing code, as they would understand what it was for. They would have to ‘sift through code’, they would go and edit the MXML directly, and if they where a designer, I’d woul presume in design view.
It’s not that I’m worried about the amount of files have I, it’s that in my experience this makes it more awkward to work.
I’m also not totally against it. What I am saying is that Flex provides a way to implement code-behind, you don’t need to mis-use inheritance.
Hi Tink,
Hows life, I have been watching most of these discussions with some interest since I have been trying to get a clear picture of efficient work flow and good practice.
It took about 18 months for this to evolve and propagate for RIA’s in AS2. Especially developing styles for large projects
So there is an evolving period for Flex 2 as well. Thanks for your intelligent contribution to the debate, and keep up the good work with MMUG, Yes I know its that long since I made it to a meeting, One of the pitfalls of working in the Midlands (but I hear a Clash tune running through my head)
What amazes me is how slow some of my colleagues are to see the potential in Flex. I sat in a meeting a few weeks ago to have one Developer describe it to a senior manager as “drag and drop flash for dummies”
(Rather rich considering all of his code is still written in AS1 and timeline based)
Code behind is a sollution to a problem which does not exist. Properly architecting an application, splitting responsibilities to where they should be and making use of databinding makes the reasons for code behind void.
By making sure your view renders, your controller makes descisions and having an explicit interface defined for the communication between those two you can still give the designer a view that has little code in it.
Favour composition over inheritance is a mantra in building apps, yet here we are injecting another layer of inheritance – with what gain?
as a side note, we used code behind 18 months ago on a large flex 1.5 project and we let it go as a usefull experiment but not one we will repeat.
I’d say the following:-
- (inheritance-based) Code behind in Visual Studio is a wonderful thing
- code behind in .NET has NOTHING to do with “partial classes” (support for partial classes didn’t arrive until the v2 framework but code behind’s been fundamental to ASP.NET from the very beginning (partial classes just keep the code that Visual Studio generates seperate from the code you write)
- managing class hierarchies is .NET a snap as Visual Studio provides support for the pattern and provides a “class” and “object browsers” to help you navigate, finad and override base classes’ methods
- Eclipse Java tools provides similar functionality for Java developers (check out the “Hierarchy view” and “Override/Implement methods”)
- Adding code behind support to Flex Builder sounds like a very good idea to me
This reminds me of a debate that raged over at Sho’s blog where he suggested the MVC pattern was harmful ( http://kuwamoto.org/2005/08/16/mvc-considered-harmful/ ). My 2 cents are that separation is important for a distributed project. While I agree that there are extra files created in the MVC pattern for more than one person it becomes harder to maintain and collaborate without a separation of code. As soon as I have the time I’d like to try the code behind technique as it looks like an interesting tool to add to the tool chest.
I would also like to add a point to the role of the designer and how I’ve observed it changing. Flex 2 is built to allow designers access to a UI builder with a rich set of transitions which is a crucial aspect of RIA design. A RIA Flash/Flex designer should provide not just a static Photoshop or Illustrator comp but ideally a tweened comp with basic state changes to give a feel of how the application will work. I know this is asking a lot from a designer but if it is not implemented by the designer then it’s the coder who is left to make these UI decisions. This seems to be one of those grey areas that will be worked out by the community in time.
The problem with your source attribute is that it can’t be a class, it has to be a flat AS file….therefore you cant extend or implement in it……
Why would u want to extend or implement it? Let me answer these seperately.
Extend
If you wanted to use the same logic for another UI class (not inheritance) you could would just set the source of that class to your AS file.
If you want to actually use inheritance, you would extend the UI and therefore the subclass would have access to the methods in your superclass supplied by the AS file.
Implement
You implement an interface. Your class would implement the interface, and whether the class complies to that interface, is up to the logic you write in the AS file.
The fact that it isn’t a class is correct. We are not talking about inheritance here, we are talking about code (not class) behind.
Personally, I like the idea of using code-behind for applying logic to a component, and then exposing the methods of that logic such that I can use partial classes to call them through event handlers. This way you minimize the dependencies created between code-behind and ui while still enabling the strict and code-transparency capabilities of code-behind.
What if you had an interface called Isavable, and it exposed methods and whatnot so that and item could serialize itself and save itself…you wanted to implement components to do so, and add some custom behavior….you still dont want to use a code behind…you’d rather give up the flexibility of implementing this interface for the sake of being stubborn? : )
I’m not sure we’re understanding each other.
“you still dont want to use a code behind”
I am talking about code-behind. You are talking about mis-using inheritance and calling it code-behind.
But to answer your question.
You have some components. Each of those components have some code-behind (i.e. an AS file) but they don’t comply to your interface. You now have a choice.
1. You implement the interface in each class and add code to your code-behind (AS file) to make sure that the component complies to the interface.
2. You extend these components and implement the interface in each subclass. Each subclass has its own code-behind (AS file) which makes sure the class complies to the interface.
Here’s one for you. You think with your inheritance that you’ve managed to sepertate the view from the logic (we know you haven’t because your logic is a DisplayObject). The designer decided to use a VBox as the base class. Because this seperation isn’t true, they would have to tell you that is the class they want as their base class (the designer cannot make the choice), and this choice has to be specified in your logic. The design changes a little and the base class now needs to be a HBox with a VBox inside it. The designer can’t update this, as he has already been forced to use inheritance to use your logic/view class. This is a view issue, yet for some reason your specifying it in your logic which in my eyes means that what your were aiming to achieve has failed. Your view isn’t seperated from your logic.
Why would you want to take/hide these design/layout decisions away from you designer, fail in the seperation of logic and view… you’d rather give up the flexibility of seperating these properly, than use a Script tag and its source property to achieve true code-behind for the sake of being to stubborn?
I never said that my method (and i say my method because it’s the one I’m talking about) had no flaws. I’m simply asserting that it in most ways is a better approach, is easier to implement, and will be easier to grasp for most people.
Well….the idea of inheritence is to use it only when what you’re building is specifically an extension of what already exists. You don’t build a class called “car” and later decide it extends “vessel” instead of “automobile.” These types of situations imply an architectural flaw than a development one. In your example, I would just extend canvas, which can in-turn compose of either a vbox OR an hbox.
If you assume that any custom ui element built to serve as a container for mxml components is an extension of canvas, then you should rarely encounter an inheritence problem.
Hey Eric.
I would say that most people when they appoach Flex start out by writing code in a Script block in the same class (like the Adobe examples). It’s a very simple step for users to cut out this code, stick it in a AS file and use that as the source property. It is also very quick and simple to transfer it back. I really don’t understand why you are so against using the source property of a script tag. We’re just going to have to agree to disagree, although I do take you comments onboard, and apprieciate you taking the time to post them.
Steve
“Well….the idea of inheritence is to use it only when what you’re building is specifically an extension of what already exists.”
Precisely the point! So using it to isolate logic isn’t the best approach.
I’m really not sure by what u meant by the changing what a class extends. What point of mine are you actually refering to?
I would also say, that assuming every piece of UI in your Flex project extends Canvas, and then putting the require contains in that, instead of using the required container to start with, is not the best approach.
If your really against using the source property of a script tag, for no valid reason i can see yet, and you really want to use classes, I would recommend using a ViewHelper class. At least this achieves what you set out to do with code-behind (i.e. isloate logic from UI). A ViewHelper doesn’t have to extend a DisplayObject, and it means that your designer can still have full control over their base class.
I’m using code behind (or whatever you want to call it) in some recent projects. It has helped me to make the leap from flash to Flex and here’s why. In Flash we learned that writing spaghetti code all over frames was bad. So we put all code on one frame. Then we used an include and externalized that code to a file. Then we started writing AS2 classes (at least I did) and linked them to a Movieclip. This – I think – was very tidy.
Now along comes Flex. Writing AS code into script tags seems messy, like writing code on frames. You end up with code all over your MXMl. I didn’t like that. MXML is my view and I don’t want tons of code in there. Tink suggest a src property but that smells like include to me. Same thing as writing code directly into MXML really.
So code behind or not, I like the approach of having an AS class alongside my MXML document. It feels to me like linking AS2 to a Movieclip. It feels right. and in my recent project it was also easy to manage that code – sure the fact that I have to use 2 different names for MXML and AS sucks but I hope Adobe will fix that. Then again, having Chat.mxml and ChatClass.as is not the end of the world.
Whether this is true code behind or not is secondary for me (doesn’t sound like it is), I just have a cosier feeling this way when I go to bed
Maybe I should also add that I never really work with a designer, I usually manage my apps myself. Lastly, I studied Aral’s tutorial and went from there: http://www.adobe.com/devnet/flex/quickstart/building_components_using_code_behind/
i guess that
1. Your not bothered about actually seperating view and functionality then means you used inheritence.
2. Your are happy that you can’t use the ‘private’ attribute when it your functionality as the class that extends it ‘the view’, needs to access it.
3. You happy with your functionality actually being a view class and the fact that users could create an instance of this functionality and add it to a display list.
1. yeah I guess I’m not bothered about that, but it very much feels to me that view and function is actually seperated. Afterall the MXML contains no functionality anymore, as is the case if I use script tags. the inheritance chain has so far not got in my way.
2. I guess you are referring to the fact that MXML elements need to be declared public in AS when using this so called code behind? That I am not happy about no and I think should be implemented differently (ie it should be possible to declare the MXML elements as private).
3. yeah, because it never happens. I’m the only user implementing this. If another developer had to use it I’d tell them about the methodology used and what to avoid. Maybe this works for me because I am not reusing code as much as I should or maybe I’m coding on a different level where these issues are seldomly encountered.
Overall the benefits outweigh any shortfalls for me with this setup. I prefer it to script tags or script source linking, even if it’s not as clean as it could be. In fact having script tags within MXML bothered me from day one when I first used Flex. But that’s not to say that any particular approach is wrong; it’s the same in Flash: there are many different ways to achieve the same result.
1. Yup your right, your MXML doesn’t contain any functionality. Unfortunately your functionality is a view item. An instance can be created, and added to the display list, without any errors. It may feel like the view and functionality are seperated, but they aint!
2. Nope I’m refering to the fact that you can’t write a method for the view to call and make it private, as because your using inheritence you can’t access anything that is private in your functionality.
3. Ah right. You might as well forget things like Singletons too then. The fact that you’d explain your code to other developers if they were involved doesn’t sound like yur methodology might not be the best?
What benefit does it have over using the source property of a script tag? I’ve listed some of the shortcomings of your approach, how about you pick some holes in mine?
As I said, 1. doesn’t concern me. It also doesn’t seem to concern Adobe as they are promoting this methodology.
2. I’m not sure if I am following here. So far anything I needed to do in my code I was able to do without issues. It may change for the worse but up until now it worked ok.
3. Yeah the methodology may have some flaws but none of these have surfaced so far for me. Not sure what Singletons have to do with it.
The benefit over a source tag for me is that I can code in a familiar way, using classes tied to an MXML file. This feels like the Flash way of linking an AS2 class to an MC. I like this setup and I don’t think it’s anything more than that.
I don’t see any need to pick holes in your approach, using the source property is perfectly fine. I just don’t like having lots of AS code amongst MXML, which is essentially what you are doing. The so called code behind methodology seems to split things up a little cleaner for me, using actual classes instead of just a bunch of methods and variables.
I’m happy to learn though, maybe I am missing something crucial. I know you are using lots of classes in your Flex projects and they look rock solid. I think it’s this part that confuses me, I wouldn’t feel that I knew where to draw the line between script tags and classes, ie when to use what and to what extend. Overall the more classes I can write the cleaner my project seems to become, and maybe that’s one reason I like to avoid script tags.
1. Ok, it doesn’t concern you thatsfine, but you admit the fact that you haven’t actually achieved what code behind id set out to do.
2. Lets say you have a button in your view. When the button is clicked it invokes a method in your functionality. Nothing else needs to know about this method, therefore you’d be best making it private. Your approach will stop you from being able to do this, as you can’t call private methods of a superclass.
3. You mentioned that your the only one looking at your code so these things don’t matter. So i mentioned Singletons and any other design patterns that are tried and tested as why would they matter either. You not looking for the best way, you looking for a way to make you feel cosy when u go bed.
Right, so you have an approach with holes in, I’m suggesting an approach with no holes I can see, yet you still stick to your approach. I would have thought it would make sense to use the approach which is least likely to cause problems, but obviously not.
I don’t actually think you undertsand what I am saying means your staill talking about having code in your MXML in your comment above. We are both talking about removing the code from your MXML (although I feel that is a solution to a problem that isn’t around). I’m writing some code, and pluging that into my class for its functionality (thats it, my code is just code). You writing a class and then using inheritance (not code, a class, not code behind, inheritance). You can’t create an instance of my code, as its just code, you can creat an instance or you so called code, which ideally you would never be able to, as it should just be providing functionality.
Before i finish my rant I’d wanted to say that just because you write more classes, it doesn’t make your project cleaner. There’s a fine line in planning what each clas should contain, not just write the most as possible.
And if you didn’t use a code behind approach you don’t nd up with code all over your MXML as you riginally stated. You end up with one tidy block of code in each MXML file. That said, If your want to use code behind and actually achieve what code behind is set out to do, don’t misuse inheritance, as its actually stopping you achieving what you set out to do, and has holes i the approach!
Actually, you can have the same name for both as and mxml files using code-bhind / inheitance:
MainApplication.mxml:
MainApplication.as
package codebehind
{
import mx.core.Application
public class MainApplication extends Application
{
public function MainApplication(){
trace(“Code behinded!!!”);
}
}
}
<?xml version=”1.0″ encoding=”utf-8″?>
<zemoga:MainApplication xmlns:zemoga=”codebehind.*” xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”absolute”>
</zemoga:MainApplication>
If you have 2 classes name the same in the same package but one is MXML and the other AS, when u create an instance i.e.
var mainApplication:MainApplication = new MainApplication();
..how the would Flash know which to create an instance of? It wouldn’t!
So if you were to do this, amont the other downfalls I meantion above, you would also have to put the so called code-behind in a different package.
Do you mean to place the MXML in the same folder/package along with the ActionScript inherited class?? Correct… obviusly is not possible… neither in ActionScript nor any other language such as c# or vb.net (if it is not a partial class). However, when you create codebehind classes in visual studio, the code behind class is not named like the file.
For example if you create a Default.aspx page, the generated code behind for the base class is named _Default:
Partial Class _Default : Inherits Page.
I think Visual Studio names the class with _ at the beginning to avoid that kind of situations (although it are a partial class).
So we have a Default.aspx class that inherits from _Default class that inherits from a class called Page that inherits from another class called TemplateControl that inherits from another class called Control that implements 6 interfaces. Beautiful!!
I really don’t matter to put the inherited class in another package. You have reason in a couple of thinks… but.. I have worked with visual studio/c# and vb.net for years, and it is comfortable for me to split the cs and the aspx and avoid spaghetti code. Thus, if you feel comfortable working with the src attribute of the script tag, that is good for you. But, a fact is a fact… and if Microsoft and Adobe recommends that practice…well I believe them.
For the record, I’ve started reverting my code (which uses the ‘code behind’ method described here as inheritance) back to Tink’s way of using MXML and src. Why? Because the inheritance way of ‘coding behind’ (the way that Tink believes is no good) created more problems for me in the long run that it solved. In fact Tink is right here (he’s usually wrong
and there is little to be gained from coding a Flex app in that way.
I still get to use lots of classes but I can now use MXML in the way it was intended and I have still some seperation of presentation and logic in seperate files. Ok, they are not classes as such but having tried it I know feel happy coding this way. Each to their own. I think the inheritance way has it’s place for small components here and there but you try and code a whole app in Flex that way (I tried) and then come back here to discuss further… It’s not a pleasant experience which is why I went back top using src. When you convert your project from ‘inheritance code behind’ to src you will also notice how little this takes – which again shows me that the extra leg work is a bit of a waste of time.
I never thought I’d say this but I’ve been converted. Thanks for saving me from the evil spirits Tink.
PS: the fact that Adobe says you should code in a certain way (which actually they don’t but merely suggest one way of doing things) does not mean it’s right
Detailed explanation and a complete application code is a merely suggest… hmmmmmmm
http://www.adobe.com/devnet/flex/quickstart/building_components_using_code_behind/
I don’t think working with script src is wrong… I don’t think working with code-behind / custom components it’s wrong… I only think that the last one option is the most comfortable for me…
I have made whole (and sophisticated) applications in Flex… I think the author of the article has enough experience as well… This method has worked for me and for another people. So, if it has not worked for you, may be is the way you have made the things… but again, if you feel comfortable working with script tags and it works for you, go ahead, but don’t say that working with code behind is NOT RIGHT… because it could confuse people.
“but don’t say that working with code behind is NOT RIGHT… because it could confuse people.”
That not what I was trying to say in this article although I myself haven’t found code-behind to be that useful.
What I am saying is that using inheritance to achieve code-behind is not the best approach in Flex, as there are better approaches.
The reason it isn’t the best approach IMO is
1. You have to start thinking about naming conventions for you view and logic.
2. It fails it seperating logic from the view.
3. You now have limited use of private methods in your logic, as you cannot call a private method on the logic from your view (even if you may want teh method private as nothing else should be able to see it).
4. You can create an instance of your logic, and add it to a display list, which you obviously wouldn’t want to do as it aint a view item.
Using the source property of a Script tag solves all of the above, and actually achieves what you set out to do (seperate view from logic).
I’ve spoken to Aral about the method of the implementation of code-behind in the tutorial, and he understood my point. I was meant to follow it up with him, but I really can’t be bother to try an convince people anymore. If you want to use inheritance for code-behind and gain the pitfails of implementing it in this way in, then thats fine, I’m just suggesting what is a better a cleaner implementation.
If it’s on Adobe, it don’t automatically mean its the best way!
Tink, as I said before, you have reason in a couple of things… I know that you don’t said that…. It was the response for Stephan Richter:
He said:
PS: the fact that Adobe says you should code in a certain way (which actually they don’t but merely suggest one way of doing things) does not mean it’s right.
Correction:
I know that you didn’t say that
[...] rted reading… I learnt really few things in the post, but one comment had a link to aTink BlogPost where he advocated that Flex’ way of doing code behind is ba [...]
Hey Tink,
I have one massive problem with the script block and the source attribute… the IDE(flexbuilder/eclipse) doesn’t introspect into the file…
so lets say i have a mxml file with some mxml components in it
–psuedo code
i can’t control + click on the function (“doClick()”) and have the IDE jump to the function… it just jumps to the top of the file, like it’s trying to find it… I’m all for clean code… but since the IDE doesn’t pick up the function, I just use the script block for convenience in the IDE… i would like more clean code… but just haven’t found a good way to seperate… so i started looking up the code-behind method, and i like the way of using inheritance, and that would solve my IDE problem, because then it could introspect into the class because it’s a class, and the IDE already does that… do you actually use the script block in tandem with the source? and seperating your files… back in the flash IDE I did this and it was just the way to do it… and it seperated the code fine… but now i’ve been spoiled by eclipse… and i’m sad that it can’t introspect into the source file of the script block…
also… if you do use the source attribute, do you just keep your files in the same directory as your mxml files? and what sort of naming standard have you came up with for the code files…?
I’m just sharing my opinion, but if you’ve got any advice it would be appreciated very much…
thanks
Axel
Hey Axel
Unfortunetly your code was removed when you posted (pesky wordpress, i’d be interested if anyone know how I can allow MXML with wordpress alongside proper code hinting in comments).
I’m not sure I understand your problem without seeing the code.
Lets say I have an .as file and it has a private method call test() in it. If i create an MXML file and create a script tage and add the .as file as the source, i can now create components and invoke the method test(). The FB IDE gives me code hinting/completion for the method, and if i use ‘goto definition’ (CTRL + click/F3), it will open the file and take me directly to the test() method as you would expect with any iinline code or inheritance.
I don’t implement code-behind in all projects, but when I have used it I have kept the files in the same directly and named them exactly the same but the name isn’t capilatlize on the .as file as it isn’t a class. This way the 2 files sit next to each other in the navigator.
Thanks for the reply, i can’t say how much i appreciate that, i post comments out there, and on flexcoders an no one ever seems to reply… so thanks for that…
so the code minus the “opening and closing carrots” is
vbox
button click=”doClick()”
endvbox
thats all it was…
you say that your goto definition works? do you provide the full path to the file or something? lets say i’m knee deep in my structure
com/acj/view/login/Login_code.as
com/acj/view/login/Login.mxml
the mxml includes the _code file via the source=”Login_code.as” the goto definition doesn’t work… it just jumps to the top of whatever file i’m in… do i have to provide the full path or something? I don’t want to hardcode the full path in the source… I’m not sure why the goto definition doesn’t work for me when i use the source=”someAsFile.as” in the script block….
so in short, the problem is… you say the goto definition works when using the source=”someAsFile.as” (which is code-behind) but i’m saying it doesnt work and never has… (not for me at least)
any example would be awesome… later man, thanks.
Hey Alex, what version of FB are you using.
We’re using FB 3.0 beta 2.0 and have tested on both OSX and Windows and goto definition works fine on both. That said, I don’t ever remember this not woking for me in previous versions such as FB 2.0.
We don’t provide the full path, just the name of the file as its in the same directory. So i have a main MXML file called ‘CodeBehindTest.mxml’ and an AS file named ‘codeBehindTest.as’ and then in the script tag I use:
source=”codeBehindTest.as”
Everything works the same as if the code was written inline inside the script tag and MXML file.
Alright, thanks for your help, i’ll check it out.
[...] 216;code-behind‘ techniques that Ted and Adobe promote. I’ve tried the ‘script src‘ technique that Tink is passionate about. And I’ve even [...]
[...] started reading… I learnt really few things in the post, but one comment had a link to aTink BlogPost where he advocated that Flex [...]
[...] ns of the interface elements. As I struggled through it, I read up on the code-behind and partial-classes principles that seem to be generally accepted by the Flex commun [...]