I've been writing in actionscript 3 using flex builder 3 for a couple of weeks now and never encountered the need to use anything like MXML. I code all layout and design in pure actionscript.
I am not sure why, but many people immediately expect me to have written a lot of MXML when I say that I'm using flex builder.
Is MXML really recommended? If so, why did I never encounter the need for it yet?
As MXML is compiled to ActionScript while building, there may be no need for MXML - everything can be coded in AS3.
However, I find that MXML is quicker to use in some scenarios - for example, composite components of the UI in an application.
If a composite component is a library-type component (a new type of generic widget - whether based on an existing control or completely custom), I use AS3 as I get finer control. The code for such controls will not change much over time, once a stable release is made.
If a composite component is a part of an application's UI which is more likely to change over time due to user-driven changes to the UI (e.g. application configuration panels) then MXML allows faster iterative development. This is the kind of change where you have to move controls around, change styling etc. in response to user or marketing feedback, or business-driven changes over time.
Related
I am making a project in AS3, but I have come to a point, where I need to branch out, because I want it to publish to 2 places, which each require a bit of different additional code to function properly. So is it possible to achieve that I do not need to make 2 projects and maintain 2 similar projects?
I hope I wrote it clear enough.
Thanks for your responses.
You can do several things, depending on whether you're working in the Flash IDE, Flash Builder, or one of the other tools like IntelliJ.
If you are working in the Flash IDE and/or have a Flash Professional project set up in Flash Builder, you can go into the ActionScript Properties panel and set up a source path that points anywhere (I usually try to keep it relative, but it's up to you).
If you're working without a fla/xfl, then you probably need to look at setting up a library project.
This is a big reaseon for OOP! Write Base Classes and extend them for your Projects as needed.
Also check out Conditional Compilation
My question is about migration from Flex3 to HTML5. I want do migrate myself not application actually. The question is, what direction is the best and most similar to flex knowledge. Maybe I will reimplement some custom components I already have in my flex library. I think that some of useful flex components I will have to implement myself in HTML5 - e.g. AdvancedDataGrid or Tree.
Now I can see 2 possibilities:
assume page (or big DIV) as application master class, and implement
other components based on extending DIV functionality - and placing
DIV in DIV in DIV - like AS3 uses UIComponent. It gives me supported
by browser environment event handling or DIV movement and redrawing
etc.
assume one CANVAS component as application master class. Build own
classes tree with owner drawing control etc. I think i will need to
implement event handling & dispatching for my internal visual
components. Also all UI actions (like moving, redrawing) I need to
implement myself.
I assume, that I will start to build my own class/component library for long-term future use. Question is what is better for knowledge and work investing?
It will be good to know wide opinion on this problem.
Can you give yours here?
From experience, we can say that writing a DataGrid component is a VERY large undertaking. We've been working on our DataGrid components for 3 years now, and we're STILL adding features. Instead of writing your own ADG like component, you should consider JS frameworks. Below are some:
DOJO (Excellent framework for RIA Enterprise App Development, and
Free!)
Sencha (Pretty good, but commercial)
JQuery (Very popular, but highly fragmented).
Each of these come with their own grid component. Senchas grid is pretty good, but so are some jquery grids. See this for example: Best dynamic JavaScript/JQuery Grid
Bottom line, dont reinvent the wheel. There are many excellent paid and free versions out there, pick one that works for you and run with it.
Disclaimer: I am author of Web Atoms JS
Web Atoms JS was built to bring all concepts of Flex, Silverlight and XUL. And each of these technologies used more of XML markup for very high level UI controls. Screens become complex and visualizing them becomes painful when it keeps on changing.
With Web Atoms you will write for less code then any of other frameworks. Web Atoms comes with all basic flex Components & more are coming.
This is a Sample of what all things are possible in Web Atoms JS.
Here is link to documentation.
http://webatomsjs.neurospeech.com/docs
I've created a number of skins for various components recently. Some of these were for Spark components and the default behavior of Flash Builder is to take the source code of the original skin and copy into your skin as a starting point.
Normally, I am 90% ok with the original skin, I just want to tweak or add one little thing. It seems to me that duplicating 3 pages of source code to do this is a bad idea. What do I do when I upgrade Flex SDKs? Do I have to go back through the source of all these original skins and (re)compare? This sounds like a disaster.
Is there a way I can create a new skin in MXML that inherits from the old skin? Can I do this via ActionScript?
If you upgrade your Flex SDK I don't think there should be any modification in the skinParts of components. Anyway if there were, you would have a compilation error if one of your implemented skinparts is not of the right type or if you miss a required skinPart. So I wouldn't worry if I were you :)
Another tip would be to use as much as possible CSS styling to avoid this kind of problems.
And no, I don't think you can inherit from a skin and modify its elements (but I'd be glad to be proved wrong).
I am developing an app which allows the user to customise every component such as button line colour, text colour etc. Clearly I need a lot of flexibility in these components to ensure detailed customisation.
I am deciding whether to use MXML or AS for my view part of the components, I am aware AS is lighter on memory but harder to write, but am unsure on whether MXML is flexible enough for my requirements?
Why no both? I am not expert in particular, but I've worked with Flex 2 quite a while ago. Why cant you use both? MXML is better for creating UI since it's just templating / tags - while for doing some logic in the background, AS would be better in programming sense.
It's like you create your website with HTML (ie. MXML), and then in the background you support it with JS to do "richer" stuff (ie. AS)
I love skins in Flex 4 - they offer a really nice separation between logic and styling.
I was wondering how people use binding in skins. The easiest way is to just bind in the skin:
label="{ hostComponent.model.buttonLabel }"
you can also use 2 way bindings:
selectedItem="#{ hostComponent.model.selectedItem }"
but you could argue that this is logic so it should really be handled in the component. You don't really want to re-create all the bindings each time you create a new skin. That seems fragile and prone to creating bugs.
So what are the alternatives? Creating a bucket load of event listeners I suppose. The adobe observe and observeValues tags could be useful as well I suppose.
How do others handle this?
I think it's a good and interesting question. There are a couple of alternatives. I suppose you could inject the model into the skin and bind directly, but that seems wrong because I think the skin should be intimately connected with the component - if the component changes its reference to the model, it automatically changes in the skins. And anyway it only exaggerates the problem you mentioned.
You can create ids in the skin and operate on them from the model. For example
SKIN: label id="infoLabel"
COMPONENT: [SkinPart] var infoLabel:Label
creationComplete {
BindingUtils.bindProperty(this, 'infoLabel', model, 'infoLabel');
}
This solves your problem. No repetitive maintenance between skins of the same component. However using BindingUtils comes at a cost. Firstly it's not as evident what is bound to what - using the {} way is just so much more obvious. Secondly (I suppose this is actually just part of the first point) you might confuse less-able developers that have to read your code and figure out what's going on.
EDIT: This assumes your component is in AS3. If your component is in MXML, I guess you can just bind as you normally would in MXML.