tsclausing.com

I’ve been searching for a way to write view code in my Flex & AIR projects that is completely reusable, scalable and simple yet powerful. I’ve read about and used the questionably named ‘code-behind‘ techniques that Ted and Adobe promote. I’ve tried the ‘script src‘ technique that Tink is passionate about. I’ve used ‘view helpers‘ and I’ve even tried the rarely discussed ‘code-in-front‘ technique that Marc has written about. However, I’ve recently been creating my views with a technique I call the ’simple’ method which is in the same school of thought as Marc’s idea. Here’s a table that describes the five methods mentioned above for creating views in Flex:

Continue to try out each technique in a Flex application with source and find out why I especially like the all MXML ’simple’ method …

Reusable, scalable, simple

I will be asking these three questions of the techniques above:

1. Does the technique generate wholly reusable code? Does the view contain application or framework specific code, or could the same view code be used across multiple applications?
2. Is the technique scalable? How well does it adjust to severe layout/design changes?
3. Is the technique simple? Can any developer, even you the developer, just look at it and know what’s going on / fix a bug / add functionality?

Those are the top three questions I’ve been considering. I want reusable code; I want freedom from design; and I want easy maintenance.

Techniques in action:

(Right click to view source)

To each his own

Some developers tend to get passionate about this subject as if only one method is valid. Hear this: They’re all valid. They all work (you can try them right here!). My advice is to know what your goals are and to choose the solution that is consistent with those goals. You’ll probably end up using some combination of these techniques in the same application. That’s not a bad thing.

My favorites:

1. ’simple’
   - Used 20% of the time to quickly develop wholly reusable, easy to read, easy to maintain view components.
2. ’script-src’
   - Used the other 80% of the time to quickly develop readable, disposable view components.
3. I do not use the ‘code-behind’ or ‘code-in-front’ techniques because I believe they fail at creating reusable, readable and maintainable components (compared to the options above). That’s just my decision.

Here’s introducing them in order of general popularity …

Meet ‘all-in-one’ (MXML & AS)

This technique is most common - a component is described in MXML and the logic is placed between <mx:Script></mx:Script> tags. I will not discuss this technique in this post as we are all likely to be familiar with it.

Meet ‘code-behind’ (View extends Logic, MXML & AS)

This technique requires two classes: one abstract ActionScript class containing logic and one concrete MXML class containing view code which extends, or inherits from, the logic class. [An abstract class exists solely to be extended and is not meant to be instantiated on its own. Since abstract classes are not actually supported in AS3 we're using the term conceptually.]

Meet ’script-src’ (MXML includes AS file)

This technique requires two files: one MXML class to describe the view and one separate ActionScript file which is included in the MXML component with the following syntax: <mx:Script source="logic.as" />. To the compiler, this is the same as ‘all-in-one’, but it allows us to mock-up apps quickly and prepare a view for a technique like ’simple’ while still meeting deadlines.

Meet ‘view helper’ (View composes Logic, MXML & AS)

This technique requires two classes: one MXML class to describe the view and instantiate a ‘view helper’, and one ActionScript class containing logic for the view (this is, of course, the view helper). The view and logic are tightly coupled in this arrangement but this is still worth considering in certain situations.

Meet ‘code-in-front’ (Logic extends View, AS & MXML)

This technique requires two classes: one abstract MXML class to describe the view and one ActionScript class containing logic which inherits from the view. This is an excellent idea because it begins to allow the view code to stand alone and become reusable, however there is still room for improvement in reuse and maintainability (see ’simple’).

Meet ’simple’ (Logic extends View, MXML & MXML)

This technique requires two classes: one abstract MXML class to describe a base view or layout and one concrete MXML class which extends the view with logic and data binding. This leaves the view completely 100% independent from the logic and allows for reuse within the same application or in other projects, easy design changes and easy to read code.

… What do you think?

Thank you for reading. I am hopeful that this post will gain a decent response from the community. I am always eager to learn from other developers and I would love to hear your input on the subject. Please leave comments and suggestions as well as links to relevant resources.