Hi Steven,
I'd also like to pick up the idea of "no code in MXML" as a "best theory" rather than a "best practice".
Since we have been able to successfully apply this to Flex applications, I would have to disagree with this assessment.
when we were building RIA with
Flash, that it was essential not to scatter ActionScript code around the
actual Flash movie itself. So ... we
would advocate that code was not scattered around the timeline, that there
was a single layer in the timeline,
with a single frame, where a single file "includes.as" was included in the
application,
This is definitely one, valid way of doing things -- however the #include method of loading code into Flash projects is the old-school way we were forced to use in the days of AS1. With AS2 and the ability to link classes to movie clips, this method is no longer necessary. It makes sense to keep all code in external classes and link them to your movie clips (forms) when necessary. The code Application form, then, becomes a natural entry point into your application. Natural in the Flash-way of doing things.
Does this method of working translate to Flex? Of course -- Flex *is* Flash :) The most striking difference between Flash and Flex (apart form Flex actually having *useful* components that work) is the way you layout your forms: Using MXML instead of an FLA. The fact that Flex is a server product is irrelevant (and completely unnecessary -- it *should* ideally be a client-side tool that outputs SWFs.) In Flex, instead of linking your form classes to an ArpForm or an mx.screens.Form, you link them to mx.containers.Form or mx.core.Application. Migrating an application from Flash to Flex thus becomes simply modifying your forms to handle any component API differences between Flash and Flex and reconstructing your form layouts using MXML (the reverse is also true for migrating a Flex application to Flash.)
Any code you have in your FLAs or MXMLs just makes you less flexible and for what? A potential few seconds saved when you are initially writing the code. It has been my experience that actually writing code takes the least amount of time in a project -- debugging, maintaining and scaling an application all take far more time and that's what we must try to reduce. It all comes down to one thing: I like simplicity. The less rules there are the less I have to think. If I know that there's no code in my MXML or FLAs, I don't waste one second of my time searching through them. I know where everything is the moment I look at a new ARP project, even if I've never seen that particular project before. For me, this is more important than saving a few seconds during initial development by adding code to my FLA or MXMLs.
Inevitably, some code might find it's way into a component in the Flash Symbol library; but if this ever were the case, then it would be code that BELONGED on that component, and was typically responsible in some way for the view logic associated with that component - so some degree of encapsulation was achieved. But code in the FLA rather than in external ActionScript 2.0 was a bad code smell.
This was inevitable with the V1 components but not so with the V2 architecture.
Let's now move to Flex.
Let me first state the obvious; I would not advocate placing business logic
(or lots of it) within <mx:Script>
blocks in Flex, if it can be extracted into an external ActionScript 2.0
class. I would *never* use the
Include functionality in Flex to pull in blocks of script, and where
possible, I would always encourage that
external classes, imports, and object creation is used.
Agreed.
Maintainability and Scalability
If we have AS2.0 code in our MXML, does it make our code harder to maintain
? Not necessarily -- if
the code is directly related to that MXML file, it may be the case that
encapsulation would encourage
the code to belong as a method on the MXML file.
This is the main point that we disagree on: Since the form implements your class (this uneasy relationship brought to you courtesy of the underlying MovieClip which stands on the periphery of standard OOP) it *is* encapsulated regardless of whether you place the code in the MXML or in the class. Placing code in the MXML from the runtime perspective bothers me because you are dynamically altering the class.
public function billPaymentButtonClick() : Void
{
ViewLocator.getInstance().getView( "statusView" ).setStatusMessage(
"Paying Bill..." );
EventBroadcaster.getInstance().broadcastEvent(
EventList.BILL_PAYMENT_REQUEST );
}
This example worries me because it appears as if a form has knowledge of the status bar. In ARP, we would write the same example as thus:
public function billPaymentButtonClick():Void
{
dispatchEvent ( { type: "billPaymentRequest" } ); // or use your own custom Event class
}
The Application form, which contains the status bar, would be listening for this event and would set the status message accordingly. The Controller would also be listening for this message and would execute the appropriate Command for execution of business logic. In ARP, we don't use View Helpers/Locators -- the Commands are instead passed a reference to the form that the event originated on (ie., called with execute ( viewRef )). I don't believe that there is adequate reward in violating the encapsulation of your View by introducing a View Helper in a state-maintaining client such as Flash.
file, JUST to
be able to say it's an external file. This is a convoluted example, that I
don't want to pick
apart (there are nicer ways of doing it) but it serves a point I think.
It's not just to be able to say it's in an external file -- it's so that you don't have to explain to the new developer you hired last week why everything else *but* that method (and a couple of others in some other files, perhaps) is in its own class file. It's about consistency.
We're not risking the scalability, maintainability, performance, clarity or
elegance of our
code by mixing MXML and ActionScript 2.0 here.
I would disagree. You are risking scalability and maintainability if you place AS2 in MXML.
On a similar note, data binding is an immensely powerful feature of Flex;
And one that is great for quick-and-dirty hacks and prototyping but it does not belong in a large-scale application where maintainability and scalability concerns outweigh the hazards of introducing such logic into your MXML.
I truly believe that this is a matter of individual style ...
Definitely. Especially without specific metrics to quantify actual vs. perceived benefits of the various methods discussed.
base, I do not believe that a purist approach of not having a line of ActionScript 2.0 in your MXML reaps any particular rewards -- rather a pragmatic, common-sense approach to keeping ActionScript 2.0 to a sensible minimum in your MXML,
Unfortunately, it has been my experience that "common sense" does not exist and that which we refer to by that moniker is a shy beast, especially in team development where each member may have a different understanding of common terms such as: "sensible minimum". My sensible minimum might be one or two methods, Joe's five and Andy's ten. In time, we have the ingredients for a royal mess :)
extracting AS2.0 code
into classes (and unit-testing them) where possible, is the most pragmatic
approach.
Now this part, I wholehearted agree with :)
Do not mix content and code.
Do not convolute the clarity of your application.
Think about encapsulation.
Think about maintainability of the code-base not just by yourself, but by
other engineers on the project.
Don't do things that stop you keeping your source code under version
control.
Those are the "forces" that make us think about keeping our content and code
I often mention these as "focus points" (though I like your term "forces" too) in development and concur with them. I would add that the separation of presentation and business logic is a fundamental goal and that encapsulation is perhaps the most important factor to watch for -- whenever I've been bitten by my code during development I find that I can trace it back to some needless violation of encapsulation at some point.)
they are not forces to which the solution is "don't have AS2.0 in MXML".
Of course not. This is just one recommendation.
rather I think it's a developer decision that most developers who turn to Flex are more than capable of making for themselves.
Definitely.
But having *some* AS2.0 in your MXML is not necessarily a bad practice, and
shouldn't be
demonised as such.
"Some" and "consistency" are not the best of friends. I would not advocate placing any code in your MXML files in order to maximize the maintainability and scalability of your applications.
I'm not interested in maintaining a 2-way compatibility
between Flash
and Flex, as I have no experience of use-cases where a project would bounce
between the
2 technologies for its implementation.
A project wouldn't. However, migration of applications from Flash to Flex is a very real use case today.
All the best, Aral
-- Aral Balkan Managing Director, Ariaware http://ariaware.com
