You can clone with
To use Feathers with MXML, you need to create a special build of feathers.swc. By default, Feathers is built using the AIR SDK with ASC 2.0. This version of the ActionScript compiler no longer supports MXML.
Using the Ant build.xml available with Feathers from Github (but not included in the final release zip file on feathersui.com), run the mxml target in the Feathers root directory. You may need to add a file named sdk.local.properties to override the value of flexsdk.root to point to the location of the Flex SDK on your local file system.
This will create feathers-mxml.swc that contains support for using Feathers with MXML. Study the MXML example to learn how to use Feathers with MXML.
It will be the best improvement!
I agree, it would be a perfect move for Feathers...
Mxml support would be awesome!
You would get bindings support, which must be used carefully of course but still very powerful!
If I were to add MXML support to Feathers, binding probably wouldn't be available, unfortunately. Starling has its own EventDispatcher implementation, so I don't think that it will be compatible. Daniel (Starling's author) and I have both made serious attempts to extend the native flash.events.EventDispatcher to work properly with Starling's display list (for things like bubbling), but there were issues that neither of us could figure out how to resolve.
ah ok, that's a shame. i didn't know that. I still have to build my first project with starling. So don't know too much about it yet. Definitely going to give feathers a try though! And even without the binding i think mxml support would be a great addition.
I agree. Binding is cool but decrease performances and could have unwanted side effects... so even without binding, MXML would be great for Feathers.
Mxml support would be awesome!
some very basic initial mxml support (references #186)
Hey Josh, just stumbled across this in my travels. I'm a committer on the Apache Flex project, I have been inside and out of the new MXML and ASC compiler for Falcon. I know it's tied to Flex (the compiler is not actually tied to the framework) but with this new compiler I could see very interesting things happening with feathers and MXML support.
Also, the new MXML compiler does not create the intermediary AS classes so there is a lot less garbage. I'm seriously going to look into this as an option for down the road, just since I see myself using feathers for mobile and would love to be able to create my UI's in mxml.
Things like data binding could definitely be optimized and I think they are being optimized in the new compiler. Things are being compiled straight to opt code.
I've done some minor tests with the Adobe Flex mxmlc. Starling events actually work in MXML, so it seems that the compiler doesn't type the generated event handler argument as a flash.events.Event, which is nice, but since Feathers uses signals, that's an issue. I may eventually switch over to Starling events instead of signals (for other reasons too, not just MXML support).
I was able to use metadata successfully in a number of places, and ScrollContainer acts similar to a Flex container. I got a little stuck on ScreenNavigator, but I can't remember off the top of my head exactly where that was. Maybe something where it would have needed binding to work properly.
It would be cool if binding in MXML could somehow be updated to work without requiring the native event dispatcher, but that seems tough since it might mean losing strong typing optimizations (I'm not sure what goes on at the op code level, though).
Well, as we know the MXML in Falcon is not completed but Gordon said he would be working on it to finish the implementation.
So, I guess with me, I am just looking towards the future since the Falcon compiler works good with AS and not MXML yet. That being said, I just put the comment in so you knew I would be very interested in helping with this implementation.
As far as Signals being extracted from feathers, I hope you do it sooner than later if you are since I and others are writing code against the signals.
If you could in your spare time, do you think you could setup a small test project with your MXML tests so I could look at it and start tinkering with the existing Adobe Flex compiler? Doesn't matter either way if you have more important things to do(which you do. :) ) I just don't know where you are coming from in how exactly you set things up.
This all sounds very exciting!
Just a quick note to Josh about the potential removal of the signals. Those are the only big thing i don't like about feathers. so yes please remove them :-) We already have 2 event systems (flash and starling), adding 1 more doesn't make things more clear. If people want a more advanced loosely coupled system they could always use StarlingMVC (which is also based on events AFAIK). The signals add just more complexity to an otherwise very intuitive component set IMHO. Anyway of course entirely up to you! But i thought i'd give you some feedback from my first experience. Working on a prototype on ios now and feathers amazing!
excellent issue! We need something simple as mxml to overcome our complex GUI
ScrollContainer: MXML content is added during initialize(). better de…
…tection of when the MXML content is changed. (references #186)
I think a short sample on the MXML usage on feathres would be helpful for potential learners.
The instruction from http://forum.starling-framework.org/topic/declarative-description-of-gui could be a nice starting point.
some more stuff for the MXML manifest (references #186)
A simple MXML example (references #186)
I noticed that mxml classes have difficulties resolving imported starling typess in the example provided by 04c88d7
I was also able to reproduce the behavior in my own mxml class.
Does it have something to do with starling shadowing flash types? (i.e. displayobject, event)
It could be a bug with starling, mxml, or feathers. Is this a known problem?
The main SWC for Feathers starting with version 1.1 will be built with ASC 2.0 instead of the classic version of MXMLC included with the Flex SDK. This means that, from now on, if you want to continue using the current support for MXML that Feathers offers, you need to build your own SWC. I've updated the description of this issue with instructions for how to use the Feathers Ant script to build Feathers with MXML support.
Instruction at the top is missing next step: