MXML Support

[joshtynjala]

Updated: I have forked the Apache Flex SDK, and I am modifying the compiler to support Starling and Feathers. See the blog post Adding support for MXML to Feathers for details about this project.

Special thanks to YETi CGI for sponsoring this project.

[gkonnov]

It will be the best improvement!

[skeddio]

I agree, it would be a perfect move for Feathers...

[arnoudb]

Mxml support would be awesome!
You would get bindings support, which must be used carefully of course but still very powerful!

[joshtynjala]

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.

[arnoudb]

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.

[skeddio]

I agree. Binding is cool but decrease performances and could have unwanted side effects... so even without binding, MXML would be great for Feathers.

[yishh]

Mxml support would be awesome!

[teotigraphix]

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.

Mike

[joshtynjala]

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).

[teotigraphix]

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.

[arnoudb]

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!

[hyzhak]

excellent issue! 👍 We need something simple as mxml to overcome our complex GUI

[shepelt]

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.

[buzzware]

Very pleased to see this progressing. I have built a Flex mobile app, and am not happy with the result, for general performance reasons, and cosmetic problems with the iOS-native parts of standard Flex controls when the screen is scrolled. Spark Mobile is broken in my opinion, and without mobile, Spark as a whole is broken. The mobile development future for me is either Feathers+MXML (hopefully with binding) OR Phonegap with Javascript, HTML, CSS. In 2013 I want declarative UI with binding. Just letting you know this feature is that critical for at least me, and I'm probably not alone. Thanks for your efforts.

[shepelt]

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?

[joshtynjala]

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.

[ludddd]

Instruction at the top is missing next step:

• create build.local.properties and redefine starling.root in it. That starling.root should point to starling src folder instead of starling root folder through.

[yangboz]

Without ID for binding, there is a work around to get the component:

//<feathers:ImageLoader name="name_imageLoader" source="
private function get id_imageLoader():ImageLoader{
return (this.id_scrollContainer.getChildByName("name_imageLoader") as ImageLoader);
}

Notice: You should layer by layer (container used) to get it.

And, how to customize feathersUI's MXML component ?

Finally, thanks for this great work!