Just a note to others reading this, you also get a lot of info/insight from the comments within the code, (the Pros/Cons sections are concise).

View Source is your friend.

I enjoyed your original post and I appreciate your reply to mine.

In response to paragraph 3 “It has been known …”:
- Yep. I should have made that clear. Thanks.

And paragraph 4 “The simple and code-in-front classes I have never used, but wouldn’t it mean …”:
1) Designers and developers need to agree on two things: what events the view dispatches, and what properties the view will make accessible. Then they can each do their job independently. This works well for me - thoughts?

2) I am only interested in preserving the base MXML component or layout for reuse because I actually do reuse these across applications at times. In my experience, the logic has been specific to an application and framework and will rarely if ever be reused in full.

But still, if you wanted to swap base views and use the same logic (when would you do this?) it may make more sense for the views to extend the logic instead of duplicating code … but then you’re back at the ‘code-behind’ problem. Do you have an elegant solution?

3) View helpers:
I’ll add that to the list. In the meantime here’s an article with a good example in an interesting series.

Update: view helper example added to the application.

“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.”

It has to be known that this method does not let you create a logic class (i.e. a class that only contains logic), it has to be a View class (i.e. extend a UIComponent), so that the MXML class can successfully extend the AS and be added to the displayList. Yes it has logic in it, which results in a base class that is a mix of logic and view.

The simple and code-in-front classes I have never used, but wouldn’t it mean a designer would need to know about all your classes and what they do, to be able to use them further down the line in other MXML classes. It’s also less portable IMO and could end up creating lots of duplicate code. I.E the logic now extends a particular view class (i.e. TinkScrollBar, surely the logic now can’t be used with the ScotScrollBar without changes being made, at a minimum the class the logic extends would need to be changed, which would leave you with a load of classes that have the same content but just extend a different base class?

Also not mentioned is the idea of ViewHelpers, i.e. using composition for the logic (the falldown here meaning that you can’t make the method protected or private).