Flex newbie question: can MXML be generated on the fly, like HTML is generated by a server?
If yes, is it ok to do so or am I missing an important Flex architectural principle.
Sort of... but it still needs to be compiled. MXML is not rendered directly, it is first compiled into ActionScript 3.0, and then into a typical SWF... so, you cannot serve your users with MXML. However, like almost all programmming languages, you can use automatic code generation to ease development tasks.
There is IIS/Apache component given by adobe that can generate your mxml -> html+swf using on the fly compilation, and it also caches the last compiled file.
However its not recommended for bigger projects as it has certain problems that you cant make libraries of your code and organize code accordingly. Namespace usage is very limited.
MXML is just a way of describing user interface layout and scripts. This information is then "compiled" into ActionScript, then converted to SWF format for use in the Flash player.
So, yes, you can generate MXML on the fly, in that you can create a text file that contains valid MXML syntax, then use mxmlc to compile it, but there's no way (that I'm aware of) to create MXML and "add" it to your current movie such that the information appears as it would were it compiled.
It is not officially supported but there is a few similar projects doing stuff similar to this.
as3Query let you create things with xml.
Using createComponentFromDescriptor() maybe can get what you want.
Should be more as I remember, but can't find it out at this moment... Searching for "MXML runtime dynamic compilation" or something like that should be helpful...
Related
I'm looking to create a flashBuilder document which uses seperate MXML files as "views" which are controlled by states - I believe it's a design pattern of sorts but I'm relatively new to FlashBuilder. I was wondering if anyone knew what design pattern it was and if I can be pointed in the direction of some good references!
FYI I'm looking into using FlashBuilder to design Android apps so any better suggestions would be much appreciated.
Cheers
You can do that the way you want. Just consider such file (MXML) as object. It can be easily added to some outer component, ie. UIComponent. You should read something about it but I bet it's quite simple. Just remember - MXML is just a language that describes an object - you could do that using AS 3.0 instead but it's obviously more convenient to use MXML. Considering this fact all the MXML files are compiled before they run so you can easily manipulate them.
Just try to add such object to some outer component like UIComponent - you can read a few words about it here: HTML in Flex. Just take a look at the function createWindow
Good luck!
they both seem to accomplish the same things with different syntax, whats the point of using two different technologies. Please highlight every possible benefit of using mxml. Also are there scenarios when one is more beneficial than the other and why.
Please clarify this runtime behavior of mxml vs AS3 as discussed in Oreilly Flex 4 Cookbook page 1:
" Many newcomers to Flex wonder how MXML and ActionScript relate to one another.
The MXML compiler (mxmlc), after parsing through the different idioms, translates
them into the same objects, so that this:
<s:Button id="btn" label="My Button" height="100"/>
and this:
var btn:Button = new Button();
btn.label = "My Button";
btn.height = 100;
produce the same object. The major difference is that while creating that object in
ActionScript (the second example) creates the button and nothing else, creating the
object in MXML adds the button to whatever component contains the MXML code.
The Flex Framework handles calling the constructor of the object described in MXML
and either adding it to the parent or setting it as a property of the parent. "
Usually,
MXML is used to build the user interface
ActionScript is used to code the logic of your application
Of course, you can also build the user interface with ActionScript but :
it will take you more time
MXML views are easier to read than AS views
In terms of user interface, ActionScript should be used only to manage view elements (add, remove, ...) at runtime.
Edit
Within a Flex application, one is expected to favor using mxml over AS, provided both uses are available. In case mxml doesn't provide a solution , the user can fallback to AS3. Flex is a framework, therefore you would expect that the emphasis is put towards mxml, rather than AS3. Like most frameworks , the idea is to hide the details in order to facilitate design and supposedly make programming more accessible.
Everything comes at a cost though, you can't really expect mxml to be faster than AS3 since it's built on top of it. A logical conclusion would be to decide on a case basis. What are your app requirements, is there really a performance gain in using this component or not etc... Apart from the fact that Flex as a whole is bound to be slower than AS3, I don't think you can set general rules. One could add that if one is worried about performance, why choose Flex in the first place...
End of Edit
The Flex framework is geared towards building RIAs, therefore it comes with a bunch of components to that effect and mxml which mainly deals with the layout of these components, Actionscript being the language the Flex framework is built upon, will typically be used for the logic of your application.
The question is not really why choose one over the other. It's the same approach you would have if you decide to develop using a language directly or using a framework based on this language. It's like comparing JQuery & Javascript or CodeIgniter & PHP .I don't mean to imply that the reasons to use JQuery are the same regarding using Flex. Whilst JQuery will attempt to hide browser specificities and make JS more accessible , Flex's purpose is entirely different.
If you're developing RIAs, Flex makes sense, if you're developing games, not really. All you can do with Flex can be done with AS3 , only you wouldn't want to spend time developing DataGrids or HBoxes whilst you could spend more time on your app structure & design.
On the other hand, if you're developing a website or a game , you wouldn't want to add the weight of the Flex framework to your swf, simply because you've added a few Image components and a couple of Labels.
Flex is not adapted to every situation, unlike my previous Javascript or Php examples , Flex's purpose is not to make the language it's based upon more accessible or easier to deal with. Flex has a very specific target.
A similar question might be "what is the advantage of using HTML over Javascript for the UI?"
I suppose you are really asking "what is the advantage of using a declarative UI over an imperative one?"
Declarative UIs are more like configuration -- no logic (or in the case of MXML, very little logic). Declarative UIs separate the specification of the view from the behavior and data.
Tooling almost always prefers declarative UIs as well, because declarative specs tend to be extremely well suited to serialization... much easier for a tool to update MXML than ActionScript with properties and such.
As you get more familiar with the concept, declarative UIs start to feel more natural, and most people tend to prefer them.
Productivity, you create view elements with MXML faster than with AS3.
Under the surface MXML get's converted to the same AS3 bytecode as if you'd write in plain AS3 so the question if MXML makes the app slower comes down to how well the Flex compiler does the conversion.
As for the original question I would say that MXML is for visual development but as said before you hit the limits when trying to create custom components.
Personally I write Flex apps in 99.9% plain AS3 because I can't stand MXML. The only MXML file is the required Entry class so the compiler knows it should be a Flex app that it compiles.
Either way your app is going to get converted to an ActionScript object.
The advantage of using MXML is user friendly and more control on the look and feel of application. sometimes its easy to fix issues aligining your components on the right pane or panel with MXML.
The advantage i see using actionScript is command over your application, you have more control. Sometimes your MXML does not get you the itch of what you are looking and actionScript gives you more power.
I would suggest you to play with both to build an application which can give you less headache and better results.
None, Flex is for learning, as you learn more you use more .as and then one day... you use 0 Flex.
For one it's slow.
(edit - answer to comments)
'Why is flex slow' - it creates computer generated .as code. Equivalent functionality in .as is faster and smaller.
'MXML separates UI from code' - I'd say no it does not. First of ... it's XML.
If you are new, check out other frameworks, like Away3d, FDT and MinimalComponents. As you get more advanced, you use less MXML and one day no MXML, you are writing pure .as.
Anything in Flex can be done in HTML5/.js better. Also .as is much better than HTML5/.j
It's like a learning tricycle, and good for corporate developers that do drag and drop, they think of themselves as programmers. Software engineers... don't stay with Flex for long before evolving.
Here: http://www.youtube.com/watch?v=TL2t8eOs1XE
I feel sorry for you if you stay in Flex and don't advance.
I always thought that separating the UI from the logic is the way to go like the use of class files in Flash CS3/CS4 or MVC in web frameworks but recently there are plenty of examples and posts using ActionScript embedded in MXML.
Is there a benefit to doing this? Am I missing something.
Don't get too caught up on the "rules" of MVC and the like. Ultimately you want your code to be setup in such a way that it will minimize the impact/churn of future changes. It's less important "where" the code is and more important what and how it's interacting with other code. I see far to many people take a simple component like a login screen and make models, view, controllers, view helpers, service facades, etc. It ends up being like 75+ lines of code for something that should have been about 20. It also spreads the code amoungst a bunch of files rather than one. So in the end, you've made maintenace hard, not easy. I'm not arguing for ignoring design patterns, but rather being practical about it. Hope this helps.
In my experience, there's not much of a difference whether you write a component in ActionScript + MXML, or solely in Actionscript. Personally, if I'm writing something that's layout heavy with a little logic, I'll do it in MXML. Conversely, if it's code heavy and has little layout, I'll write it in Actionscript.
I suppose you could always separate the view and model, but then you have more files to maintain. Sometimes it makes sense, but I have yet to see a compelling reason to do it all the time.
I go by a few simple rules:
If a bit of code is just a single short line and it isn't something you can reuse elsewhere -- mere glue code -- put it directly in the MXML tag.
If it's too long to fit comfortably in the MXML tag or it is something multiple components in that MXML file can use, put it in a function in a Script tag within the same file, and call the function from the MXML tag(s).
Everything else -- full classes, large functions, things used by multiple MXML files -- goes in a separate .as file. This includes single-LOC methods that are part of a larger class, as opposed to the standalone functions the other rules cover.
I agree with Erich Douglass, to a point. Generally, if I can do the layout with MXML it's just easier to maintain. I mean, who wants to write all that crap in a createChildren override if you don't have to? Besides, the MXML is easier to read.
Whatever you do, though, remember that if you are merely calling a separate script file for an MXML component (Foo.mxml calls Foo.as for its ActionScript) you are losing the code highlighting feature that helps you work between the MXML and the ActionScript. I like to keep them both in the same place, so when I click on an ID in an MXML element I can see at a glance where it's being referenced in the AS.
I have been in the process of creating a "lite" version of an existing Flex application, and thereby porting many of the classes that are used by both into a library project. As such, I want to easily find all of the "orphan" classes in the original project - those classes that are no longer referenced/used by the project. Is there an Eclipse plug-in, or some other easy way to find these in Flex Builder 3?
Thanks.
MXML Compiler (mxmlc) compiler has "link-report" which will generate all the classes you are using in your original application. From there, with a bit of grep / awk / xsl magic, you should be able to diff with the classes you have in your library project.
Here's what I do sometimes, lets say we've been refactoring, and a class becomes obsolete, I simply move the suspecting file from Flex Builder to the desktop, rebuild the project and see if it the compiler spits out any Errors.
If it doesn't complain, I know I can safely delete it.
If your class is depended on, the compiler will throw some errors in the Problems panel in Flex Builder and give you a fairly clear hint of what's missing.
This won't be fun however if you have thousands of classes, as you have to traverse them one by one.
I would suggest, always keep copies of the old ones in Subversion, just in case you had something re-usable in there, and later you want the deleted file restored.
I have a Flex application that seems larger than it should be. There is a lot of code in it, but not a lot of assets and it just seems large, but I'm not sure how to go about figuring out where the space is going.
I know about the –link-report option, but it only gives the sizes of externally linked library classes. I'm very interested in seeing a report of the sizes of all the classes and resources in my application and it would be a huge bonus if I could also view their dependencies. Not knowing how the code is compiled I'm not sure if this is even possible, but it seems like it should since the compiler can give me the sizes of individual classes linked from other libraries.
I did some searching around, but couldn't find anything helpful. Everything points to the optimization techniques of modularizing and externally linking libraries, which I understand and will implement, but I would really love some more detailed reports of what my compiled application looks like.
To be clear, I'm not really interested in tips on how to reduce the file size, just a report on what is used for and which classes are referencing what.
Anybody have any ideas?
CORRECTION - The link report does show all classes. My particular project in Flex Builder had several CSS files set to compile to swfs. My link report for the main app was being overwritten by these css compiles!
The link report actually contains all compiled classes and not just the ones in external libraries (at least with the Flex 4 SDK). There is an xsl available that will generate an html file of the link report so it is easier to read.
Check this post: http://blog.iconara.net/2007/02/25/visualizing-mxmlcs-link-report/
There is a command-line utility called flash.swf.tools.SwfxPrinter in swfkit.jar, which comes with Flex Builder (or the plug-in or the SDK) and which you can use to analyze information about class sizes. Joe Berkovitz wrote some good instructions on how to make use of it in his blog, and he was working on an AIR-based GUI tool that leverages it, but I'm not sure if he ever published the tool. Still, you can use his instructions to leverage the utility directly from the JAR.
I found a handy little AIR app that really helps organize the link report info.
http://www.kahunaburger.com/2008/03/08/air-link-report-visualizer/
It's old but still works very well.