Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

MXML Support #186

Open
joshtynjala opened this Issue · 18 comments
@joshtynjala
Owner

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.

@GEGman

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
Owner

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
Owner

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! :+1: We need something simple as mxml to overcome our complex GUI

@joshtynjala joshtynjala referenced this issue from a commit
@joshtynjala joshtynjala ScrollContainer: MXML content is added during initialize(). better de…
…tection of when the MXML content is changed. (references #186)
458846f
@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
Owner

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.
@joshtynjala joshtynjala referenced this issue from a commit
@joshtynjala joshtynjala LayoutGroup: made mxmlContent the default property for MXML and added…
… the missing code to refresh the children if mxmlContent changes (references #186)
e58721b
@joshtynjala joshtynjala removed the wontfix label
@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.