RE: [flexcoders] Theory and Practice: Mixing AS2.0 in MXML
Thanks a lot for the time you spent doing that Erik! Much appreciated! Robert L. Brueckmann Web Developer Merlin Securities,LLC
RE: [flexcoders] Theory and Practice: Mixing AS2.0 in MXML
After all, a MXML gets compiled into a AS 2.0 class. Most MXML files are
instances of the View (classic View in MVC that is) - so to me it's logic
andvalid to have functionality inside that file that handles and delegates user
interactions.
Dirk.
-Original Message-
From: Steven Webster [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 03, 2005 9:25 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Theory and Practice: Mixing AS2.0 in MXML
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 of script, 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, it may 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 Idon'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, are held within the MXML file -
especially when
they are concerned with view logic, or with dispatching events so that theycan
be used
as discrete components without coupling them to anything else in the
architecture.
We're not risking the scalability,
RE: [flexcoders] Theory and Practice: Mixing AS2.0 in MXML
Personaly I don't like putting code into mxml's too, for me they are just the visual part of the application. I also don't like the idea of having a class somewhere far away from my form wich is called on a (for example) submit button event and then accesses the formfields to check their values. What I do is naming the mxml (class) file like this: classNameVisual.mxml and subclass that file with an .as file called className.as. This way I can instantiate the form as className and have a local reference to the formfields inside my .as file. There I do actions that apply to the form only and use events to communicate with the rest of the application. This approach results in two files vor each view (form, mxml, whaever). The only consern of the .as file is the mxml file. And they are easy to find. Greetz Erik -Original Message- From: Aral Balkan [mailto:[EMAIL PROTECTED] Sent: donderdag 3 maart 2005 11:10 To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Theory and Practice: Mixing AS2.0 in MXML 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
RE: [flexcoders] Theory and Practice: Mixing AS2.0 in MXML
Can I ask how you manage an MXML without any ActionScript at all? How in a file that has components with clickor change listeners would you not have any supporting ActionScript codeI mean just about every single one of my MXML files has initialize or creationComplete listeners in the parent container tag with dozens of other components that are dependent on dataproviders changing and user interactions like clicking or dragging and dropping and I cant begin to imagine how I could extract every bit of ActionScript from my MXML files into individual ActionScript classesmaybe Im not grasping the Cairgorm design architecture fullyI thought I had a pretty good grasp on it but to hear that youre writing MXML files with no ActionScript in them whatsoever kind of baffles mecan you give me an example? Thanks for bearing with me! ;) Robert L. Brueckmann Web Developer Merlin Securities,LLC
RE: [flexcoders] Theory and Practice: Mixing AS2.0 in MXML
What i do is extending the mxmlclass with an AS class. Then instead of using the mxml i use the AS subclass. If the class is empty, things just work like they did before. But inside the AS class u have the usual callBacks (createChildren, init, etc) and a constructor. Via code u can add listeners to the UI components and manage everything from within the AS class. Greetz Erik From: Robert Brueckmann [mailto:[EMAIL PROTECTED] Sent: donderdag 3 maart 2005 15:14To: flexcoders@yahoogroups.comSubject: RE: [flexcoders] Theory and Practice: Mixing AS2.0 in MXML Can I ask how you manage an MXML without any ActionScript at all? How in a file that has components with click or change listeners would you not have any supporting ActionScript codeI mean just about every single one of my MXML fileshas initialize or creationComplete listeners in the parent container tag with dozens of other components that are dependent on dataproviders changing and user interactions like clicking or dragging and dropping and I cant beginto imagine how I could extract every bit of ActionScript from my MXML files into individual ActionScript classesmaybe Im not grasping the Cairgorm designarchitecture fullyI thought I had a pretty good grasp on it but to hear that youre writing MXML files with no ActionScript in them whatsoever kind of baffles mecan you give me an example? Thanks for bearing with me! ;)
RE: [flexcoders] Theory and Practice: Mixing AS2.0 in MXML
That was my initial approach too, but eventualy it was
easier to track bugs and 'mis-references' since i extended the component i was
accessing. Now i get an error when i try to reference a textfield that isnt
there. Another thing that is a pro for this kind of approach, is that the mxml
file doesnt have to know wich method to call in the helper
class.
Greetz Erik
From: Dimitrios Gianninas
[mailto:[EMAIL PROTECTED] Sent: donderdag3
maart 2005 16:22To: flexcoders@yahoogroups.comSubject: RE:
[flexcoders] Theory and Practice: Mixing AS2.0 in MXML
I tend to put such code in the
corresponding ViewHelper class, so every view (MXML file) has a corresponding
ViewHelper class. See sample below:
Inboxes.mxml
mx:Box
...
vw:InboxesViewHelper id="inboxesHelper"
view="{this}"/
...
mx:List id="inboxList" width="165" height="100%"
labelField="name"
vScrollPolicy="auto"
change="inboxesHelper.doLoadInbox(inboxList.selectedItem.id)"
/
...
/mx:Box
Jimmy
Gianninas
Software Developer -
Optimal Payments
Inc.
RE: [flexcoders] Theory and Practice: Mixing AS2.0 in MXML
Im reading these posts but haveno
time to respond (nor to any other posts right now), though the discussion is a
good one and I dont have strong opinions either way (taking into account
of course that Im strongly loyal to binding). The only thing Ill
contribute is that Im gonna refer to Eriks technique as view-behind
in deference to the ASP.NET approach called code-behind (eh, I dont know
how the punctuate it). I now expect a nickel every time I see view-behind in a
flexcoders post J
Carry on,
Matt
From: Erik Westra
[mailto:[EMAIL PROTECTED]
Sent: Thursday, March 03, 2005
10:30 AM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Theory
and Practice: Mixing AS2.0 in MXML
That was my initial approach too, but
eventualy it was easier to track bugs and 'mis-references' since i extendedthe
component i was accessing. Now i get an error when i try to reference a
textfield that isnt there. Another thing that is a pro for this kind of
approach, is that the mxml file doesnt have to know wich method to call in the
helper class.
Greetz Erik
From:Dimitrios
Gianninas [mailto:[EMAIL PROTECTED]
Sent: donderdag 3 maart 200516:22
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Theory
and Practice: Mixing AS2.0 in MXML
I tend
to put such code in the corresponding ViewHelper class, so every view (MXML
file) has a corresponding ViewHelper class. See sample below:
Inboxes.mxml
mx:Box
...
vw:InboxesViewHelper id=inboxesHelper
view={this}/
...
mx:List id=inboxList width=165
height=100% labelField=name
vScrollPolicy=auto change=inboxesHelper.doLoadInbox(inboxList.selectedItem.id)
/
...
/mx:Box
Jimmy
Gianninas
Software
Developer - Optimal Payments Inc.
RE: [flexcoders] Theory and Practice: Mixing AS2.0 in MXML
I was about to say that. It's besicaly like asp.NET where
you have the tag bas view on the html and the code in C# or VB in a code-behind
file. I use jimmy's method using the viewHelper because otherwise you wouldhave
the mxml file a actionscrip class (code-behind) and the viewHelper also if you
would use the framework.
Omar
Ramos
Technology
Manager
Itacon
Corporation
From: Matt Chotin
[mailto:[EMAIL PROTECTED] Sent: Thursday, March 03, 2005 12:31
PMTo: flexcoders@yahoogroups.comSubject: RE: [flexcoders]
Theory and Practice: Mixing AS2.0 in MXML
Im reading these posts
but have no time to respond (nor to any other posts right now), though the
discussion is a good one and I dont have strong opinions either way (taking
into account of course that Im strongly loyal to binding). Theonly thing
Ill contribute is that Im gonna refer to Eriks technique as view-behind in
deference to the ASP.NET approach called code-behind (eh, I dont know how the
punctuate it). I now expect a nickel every time I see view-behind in a
flexcoders post J
Carry
on,
Matt
From: Erik
Westra [mailto:[EMAIL PROTECTED] Sent: Thursday, March 03, 2005 10:30
AMTo: flexcoders@yahoogroups.comSubject: RE: [flexcoders] Theory and
Practice: Mixing AS2.0 in MXML
That was my initial
approach too, but eventualy it was easier to track bugs and 'mis-references'
since i extended the component i was accessing. Now i get an error when i try to
reference a textfield that isnt there. Another thing that is a pro for thiskind
of approach, is that the mxml file doesnt have to know wich method to call in
the helper class.
Greetz
Erik
From: Dimitrios
Gianninas [mailto:[EMAIL PROTECTED] Sent: donderdag 3 maart 2005
16:22To: flexcoders@yahoogroups.comSubject: RE: [flexcoders] Theory and
Practice: Mixing AS2.0 in MXML
I tend
to put such code in the corresponding ViewHelper class, so every view (MXML
file) has a corresponding ViewHelper class. See sample
below:
Inboxes.mxml
mx:Box
...
vw:InboxesViewHelper
id="inboxesHelper" view="{this}"/
...
mx:List
id="inboxList" width="165" height="100%"
labelField="name"
vScrollPolicy="auto"
change="inboxesHelper.doLoadInbox(inboxList.selectedItem.id)"
/
...
/mx:Box
Jimmy
Gianninas
Software
Developer -
Optimal
Payments Inc.
