code - as a pragmatic (slothfull? :-) Flex programmer I am rather fond of using a bit more actionscript in my mxml, but then I understand where Aral is coming from - and in Flash I would never put code in my fla. I would be happy to recommend either framework to a client.
Not having seen Aral's recommendations, I can't comment
specifically, but I'd also like to pick up the idea of
"no code in MXML" as a "best theory" rather than
a "best practice".
Separation of content and code is the key driving
principle, imho, as to why 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, and the bare minimum
of
initialisation code (perhaps creation of your
controller) was placed on that first frame.
Thereafter, we advocated using the Cairngorm framework,
extracting all business logic in classes, and keeping
these classes in external ActionScript files. Despite
the limitations of the Flash IDE as an RIA development
environment, this allowed us to achieve best-practices of
keeping our content (the FLA) as separate as possible
from the code, in turn promoting reuse, promoting
maintainability, encouraging that code could be versioned
and kept under source control, etc.
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.
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 ofscript,
and where possible, I would always encourage that
external classes, imports, and object creation is
used.
However, let's remind ourselves why we might want to not
have code in our MXML -- not in theory, but
in practice.
Not mix content and code
This is the key one; if we have business logic in our MXML,
we should be refactoring this into external
AS2.0 classes (and unit-testing it). If
you have screeds of business logic in a big <mx:Script>
block,
then you should be pulling this into external classes - you
are beginning to mix your content and
your code.
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, itmay be
the case that encapsulation would encourage
the code to belong as a method on the MXML file. An
example ? Perhaps we have a click handler,
that is going to respond to a button press in our MXML
component; perhaps on pressing a button,
we want to set a status bar message, and then broadcast an
event for the controller ... it makes
sense to have:
public function billPaymentButtonClick() :
Void
{
ViewLocator.getInstance().getView( "statusView"
).setStatusMessage( "Paying Bill..." );
EventBroadcaster.getInstance().broadcastEvent(
EventList.BILL_PAYMENT_REQUEST );
}
and then in our same MXML file:
<mx:Button id="payBillButton" label="Pay
Bill" click="billPaymentButtonClick()" />
In this instance, I do not see what is to be gained by
being purist, and extracting the
billPaymentButtonClick() method out of the MXML and into an
external AS2.0 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.
Because MXML are text files, we can still keep these files
under source control, and we
can merge them if more than one person works on them.
More importantly, for maintainability,
I would argue that it's easier for developers to maintain
this source, where the methods
that are unique and specific to the MXML file, areheld
within the MXML file - especially when
they are concerned with view logic, or with dispatching
events so that they can be used
as discrete components without coupling them to anything
else in the architecture.
We're not risking the scalability, maintainability,
performance, clarity or elegance of our
code by mixing MXML and ActionScript 2.0
here.
On clarity; often in the Flex Book, we would placemore
code than we would be comfortable
with in a production project, in the body of the MXML file
... but we did warn about this in
the introduction to the book. Why ? Because we found
that when trying to explain a
concept, the clarity of having the code in the MXML file
outweighed the "purist" benefit
of keeping the code in separate files. Pragmatism won
over theory.
On a similar note, data binding is an immensely powerful
feature of Flex; and this will often
result in us binding to a var in our MXML, and then as our
codebase matures, we may
replace the var with a public method on our MXML that we
bind to. Why should that method
live in an external ActionScript 2.0 file, what benefit
does that bring us ? I'd hate to
cripple the utility of data binding, by taking a purist
approach to removing all occurence
of AS2.0 from MXML. Data binding saves an incredible
amount of overall development
time, effort, risk, and leads to an elegance and clarity of
code (cheque's in the mail Matt).
I truly believe that this is a matter of individual style
... but when you're building Enterprise
Flex apps with hundreds and thousands of MXML and
ActionScript 2.0 files in your code
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, extracting AS2.0 code
into classes (and unit-testing them) where possible, is the
most pragmatic approach.
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
separate; they are not forces to which the solution is
"don't have AS2.0 in MXML".
I'd hate this to turn into a holy war of opinion ... rather
I think it's a developer decision
that most developers who turn to Flex are more than capable
of making for themselves.
But having *some* AS2.0 in your MXML is not necessarily a
bad practice, and shouldn't be
demonised as such. 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.
Hope this offers some food for thought.
Steven
--
Steven Webster
Technical Director
Technical Director
iteration::two
This e-mail and any associated attachments
transmitted with it may contain confidential information and must not be copied,
or disclosed, or used by anyone other than the intended recipient(s). If you are
not the intended recipient(s) please destroy this e-mail, and any copies ofit,
immediately.
Please also note that while software systems havebeen used to try to ensure that this e-mail has been swept for viruses, iteration::two do not accept responsibility for any damage or loss caused in respect of any viruses transmitted by the e-mail. Please ensure your own checks are carried out before any attachments are opened.
Please also note that while software systems havebeen used to try to ensure that this e-mail has been swept for viruses, iteration::two do not accept responsibility for any damage or loss caused in respect of any viruses transmitted by the e-mail. Please ensure your own checks are carried out before any attachments are opened.
