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: [email protected] 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, maintainability, performance, clarity orelegance of our code by mixing MXML and ActionScript 2.0 here. On clarity; often in the Flex Book, we would place more 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 inyour 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 inMXML". 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, andshouldn't be demonised as such. I'm not interested in maintaining a 2-way compatibilitybetween Flash and Flex, as I have no experience of use-cases where a project would bouncebetween the 2 technologies for its implementation. Hope this offers some food for thought. Steven -- Steven Webster Technical Director iteration::two
