I prefer to write components that use actionscript classes - and then use mxml that use these components. It makes use and reuse quite simple. Also combining this component into larger components seems easier this way as well.
Often my development cycle is like this 1) Write actionscript to get things working the way I want them to 2) Refactor this actionscript to make it readable and optimized 3) Create a component and move this actionscript into their own reusable classes, or into that component. 4) Replace original code with instantiation of that component and consider what variables will need to be set at the mxml level. So my <application> xml really doesn't have much actionscript in it. Its more of a straight outline of components. It has some actionscript like a creationcomplete function, etc. but .. well here's an example: You have an accordion with some UI elements and one of the accordion members should allow file upload. You could add a button with label browse and in the script section of the application have a function you call on click that pops up the file selector. This is Step 1. After you test it and see its working, you recode it a bit, maybe you want a text field to show the name of the file selected, or a list to show the files selected in the multi-file upload case. So you get that working, you clean the code so its somewhat reusable. That is step 2. Now you create a component called the FileUploader, perhaps another one called MultiFileUploader, they both use an actionscript class you create that contains most of the logic you previously wrote. This is step 3. Then in your application mxml you now have an instantiation of a FileUploader instead of an hbox, a text field, and a button. And all the actionscript that controls how that thing behaves is contained in the component or in classes it uses, so at the application level all you see is mxml. You test out this mxml, and realize you want to change the component so at the mxml level you can specify the filetypes it accepts, so you create a member on a class that you decide both FileUploader and MultiFileUploader will inherit from - called GenericFileUploader. The members name is fileFilterString, lets say, so that you can do something like <FileUploader fileFilterType="images" />.. and the generic class will create the FileFilter class each of its children uses in its constructor, actually using "Images (*.jpg,*.jpeg, *.gif, *.png)" as the string to pass in. So the general tendency is to push actionscript further and further down away from where you will ever have to touch it again, if possible - I doubt you would ever instantiate a GenericFileUploader using mxml, but much of the actionscript that both the FileUploader and MultiFileUploader use would be in that class (which could be mxml component or just actionscript). Then these components become building blocks that are easily used across your application and even future applications. How does this approach jive with the other ppl on this list? Sound about right? Seth From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of lrdvadersith Sent: Monday, October 29, 2007 11:03 AM To: [email protected] Subject: [flexcoders] MXML vs. pure ActionScript I am new to the Flex world, and I am trying to figure out if I should use MXML to lay out visual components, or go with a pure ActionScript approach. Google searches reveal pros and cons of each, but no real consensus on which is a better general approach. Even within our organization (all of whom are also new to Flex), there is no real strong opinions on this issue. I would like to see what the thoughts are from some of the more experienced Flex coders in this group. Do you prefer using MXML or pure ActionScript, and why? Thanks in advance, Steve
