Code-Behind and Flex 2.0 (Partial Classes)

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 Eeek, immediately we can see a fallback here that we can’t name the files the same.

Code-behind inheritance 1

Lets extend this Accordian to change the UI and also add some new functionality. We now have a CustomAccordian.mxml file that extends extends Accordian.mxml which extends Now although in theory we know CustomAccordian.mxml extends Accordian.mxml we can’t see this becuase we have been forced to extend to achieve our code-behind.

Code-behind inheritance 2

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

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.