This is I think the best way to write your applications. Code Behind cleanly and fully separates the design/interface from the logic of your program. Beginners should adopt this method early on. I wasn’t aware of this method until halfway through my project, I should have read all the Flex Quick Start documents from Adobe right when I was just starting with Flex.
Here’s a short illustration of how to use Code Behind.
Let’s say we have a TabNavigator component in our application. We can use different components that take advantage of code behind for each tab pane. This will make your code cleaner and more organized especially if you are working on an interface with a handful of different elements.
We use a custom component, FirstTab, instead of the default Canvas component for one of the tab panes. This component was written using code behind.
<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”absolute” backgroundGradientColors=”[#ffffff, #c0c0c0]” xmlns:local=”*”>
<mx:TabNavigator x=”10″ y=”10″ width=”200″ height=”200″>
<local:FirstTab label=”Tab 1″ width=”100%” height=”100%”/>
<mx:Canvas label=”Tab 2″ width=”100%” height=”100%”/>
</mx:TabNavigator>
</mx:Application>
For the FirstTab component, we need to write two files. One is the the Actionscript class, we name it FirstTabClass. The other one is the mxml component script, we call it FirstTab. FirstTab is actually a subclass of FirstTabClass. Now we can happily use Flex Builder’s interface designer on the mxml component while we put all our logic in the separate Actionscript class.
This is the code of the FirstTab component. We have to use the FirstTabClass as the root tag for this component. As an example, we just put a simple button in the center of the component. The id property of this button should match the public variable in the FirstTabClass.
<?xml version=”1.0″ encoding=”utf-8″?>
<FirstTabClass xmlns=”ricoonflex.*” xmlns:mx=”http://www.adobe.com/2006/mxml” width=”250″ height=”150″>
<mx:Button label=”Button” horizontalCenter=”0″ verticalCenter=”0″ id=”button”/>
</FirstTabClass>
This is the code of the FirstTabClass class. We define a public variable named button which corresponds to the button object in the FirstTabClass component. In here we do all our event handling and other application logic.
package ricoonflex
{
import mx.containers.Canvas;
import mx.controls.Button;
import mx.events.FlexEvent;
import flash.events.MouseEvent;public class FirstTabClass extends Canvas
{
// the variable name should correspond to the id of the button object in the component
public var button:Button;public function FirstTabClass() {
addEventListener(FlexEvent.CREATION_COMPLETE, creationCompleteHandler);
}private function creationCompleteHandler(event:FlexEvent):void {
button.addEventListener(MouseEvent.CLICK, buttonClickHandler);
}private function buttonClickHandler(event:MouseEvent):void {
trace(”FirstTabClass”);
}
}
}
I’ve commented on this elsewhere, but as far as I can see this is inheritance, not really code-behind.
Using inheritance you actally fail to seperate view from logic, as you logic is the base for you view and therefore to change the way your view lays things out, you may have to change your logic. Also you logic is a view component. It extends a view component, you can create an instance of it, and you could add it to a displayList (which obviously you would never want to do with logic).
Flex provides the perfect way to implement code-behind as that is by creating an ActionScript file for you code behind and then pluging that into a script tag using the source property.
This keeps logic a view totally seperate, allows for clearer naming, is just as portable and elimiantes the possibillity of being able to create an instance of logic.
In my eyes Adobe are clearly wrong on this one and suggesting to others a bad implementation (without even discussing the other option).
i wrote more about it here http://www.tink.ws/blog/code-behind-and-flex-20-partial-classes/
Tink,
I’ve read your post including all the readers’ comments. I think you have quite a good point. I tested the script+source tag with the small sample application I wrote in my post and found it almost as clean as using “code behind”. And you are right, this avoids instantiation of the parent class, although I don’t consider this a big practical problem since you or your team can avoid accidental instantiation of the parent classes with smart class naming and packaging, but this sounds like a hack and inelegant in a way.
But maybe there is some higher purpose we don’t know of yet or we’re missing with this code behind aside from making the code look cleaner. It could be reusability of the classes or it could simply be to make things simpler. And code behind is still a new feature in Flex, we probably will see a better implementation in future versions that addresses our current concerns.
Rico
“although I don’t consider this a big practical problem since you or your team can avoid accidental instantiation of the parent classes with smart class naming and packaging, but this sounds like a hack and inelegant in a way.”
We could avoid all mistakes in dev with smart coding, unfortunately mistakes happen, and its the ability to stop those mistakes or catch them, that create a better dev framework (i.e. AS 3.0 is a better dev enviroment as it is stricter that AS 2.0, and therefore you are less likely to make errors, and if you do they are easier to find).
“It could be reusability of the classes or it could simply be to make things simpler.”
I would argue that inheritance is a lot more complicated (i.e. making a proper class, than writing a few logic methds), and reusability is the same in both cases (i.e. totally reuseable).
“we probably will see a better implementation in future versions that addresses our current concerns.”
I don’t really have any current concerns with code-behind as it seems they have the perfect way to implement it, but instead they suggest the mis-used of inheritance to achieve code-behind.
I think this all boils down to how we define “code behind”. Using the script tag to include program code looks more like “code within” to me, the code is part of the component itself and is not really behind it at all. In essence and in the eyes of the compiler, the included logic code and the component code are just one file. Just like including files in PHP or C++, the compiler copies the entire content of the included file and puts it on the line where the include directive is, and this results in one file, no code behind.
Maybe inheritance is really the only way we can achieve true code behind.