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: [email protected] 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 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
