That's a valid approach as well, but probably has the overhead of wrapping a lot of their classes to conform to IUIBase. You would probably get a lot of other things like Binding and States for free though.
-Alex On 3/1/16, 2:16 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala" <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote: >If I may, there might be a better approach by just doing it within the >FlexJS framework. You should be able to create a >org.apache.flex.starling.Application.as class where a starling display >list >is used instead of the regular display list. You can follow the pattern >that the org.apache.flex.jquery.Application.as or >org.apache.flex.createjs.Application.as follows. > >Once you have the basic application setup, you should be able to construct >individual components and use the Starling display list as you go. You >might have to create a new version of UIBase (and possible other classes) >to use the starling display list instead. > >And theoretically, for each of these starling based classes, you could >have >the COMPILE::JS versions that do the same/similar thing on Canvas/WebGL. >Something along the lines of https://github.com/matrix3d/spriteflexjs > >Just a thought. I might be missing something big here. > >Thanks, >Om > >On Tue, Mar 1, 2016 at 1:35 PM, Alex Harui <aha...@adobe.com> wrote: > >> I don't know what Josh did to MXMLC to get it to work for >> Starling/Feathers. I have encouraged him in the past to try to work >> directly with the Falcon output. IMO, MXMLC should be abandoned. >> >> Falcon supposedly has no real ties to any particular ActionScript >> framework. MXMLC generated code that expected the Flex SDK to be >>around. >> >> Maybe the best place to start is with a simple Starling/Feathers app >> written with some MXML and AS. Run it through Falcon with >> -mxml-children-as-data and see what you get. It won't run right away, >>but >> will give us tangible issues to discuss. In theory, you won't need to >> touch any of the JBurg stuff at all. The MXML reduction does not use >> JBurg except for any AS code in event handlers and script blocks. >> >> What Falcon currently does is add one method and a few new properties to >> the subclass. So for some MXML like >> >> ---- MyApp.mxml ---- >> <StarlingApp width="900" height="600"> >> <FeathersComponent id="foo" label="bar" /> >> </StarlingApp> >> ---- MyApp.mxml ---- >> >> The effective output (because there is no generated AS output from >>Falcon) >> is something like: >> >> public class MyApp extends StarlingApp >> { >> public function MyApp() >> { >> super(); >> generateMXMLAttributes([2, "width", false, 900, "height", false, >> 600]); >> } >> >> override public function get MXMLDescriptor():Array >> { >> return [1, FeathersComponent, 2, "id", false, "foo", "label", >> false, "bar"]; >> } >> } >> >> IOW, any base-class for an MXML file must support: >> >> public function generateMXMLAttributes(data:Array):void >> >> public function get MXMLDescriptor():Array; >> >> >> Another property called mxmlsd is added for state-dependent nodes. Not >> sure if you will need that. >> >> There might even be a better way to do this, and better names. The >>reason >> it is this way is because I think it is better to have some requirements >> on the base classes of the framework rather than have the output assume >> other kinds of lifecycle calls: addElement vs addChild, when to >> instantiate child nodes, etc. By passing in MXML as data, the framework >> gets to decide when to actually apply properties, map them to different >> things, etc. >> >> HTH, >> -Alex >> >> On 3/1/16, 9:40 AM, "Michael Schmalle" <teotigraphix...@gmail.com> >>wrote: >> >> >Would I even need to fork it? >> > >> >I mentioned to Josh that I use MXML and Feathers extensively for these >> >audio apps I am about to release on Android which means I have a high >> >stake >> >in the tech at the moment. >> > >> >That tinkerer side of me feels I could do something about this but I >>am at >> >a loss of what I need to do to get the ball rolling. >> > >> >If I could get this project to work, this would be huge for the project >> >since the Falcon compiler could actually start to be used in >>production. >> >It >> >also means I would have a monetary reason to be able to contribute to >>the >> >development and learning deeper of the compiler. >> > >> >Alex, I need some advice man. :) Where would I even begin? >> > >> >Below is what I posted on Josh's Feathers SDK issue, just me talking to >> >myself. >> > >> >Mike >> > >> >" >> > >> >I'm putting this here just so if anybody else reads it and wants to >>chime >> >in. >> > >> >Background; I have worked extensively with the Falcon compiler mainly >>in >> >creating/writing the FalconJX compiler FlexJS uses to cross compile >> >AS/MXML >> >to JS. >> > >> >The problem I see is that I wrote a traversing framework that was a >> >visitor >> >and walker implementation which was an abstraction outside of the >>actual >> >AST Falcon produces when it parses AS3. >> > >> >The actual MXML compiler uses JBurg and is completely outside of my >> >knowledge base. I don't off the top of my head know of any hooks to >>extend >> >MXML generation or even how to start. >> > >> >I do understand "what" the original compiler does as far as setting up >>AS >> >to be compiled again so the theory is there for me but I am totally >> >lacking >> >in the vision from start to end of what I need to do to get Falcon to >> >produce different byte code since there is no code generation pass. >> > >> >Anyway, I think this could be HUGE for Starling and Feathers if it >>could >> >be >> >done since then we could add a whole bunch of specific things that >>could >> >enhance the dynamic nature of constructing a Starling/Feathers >> >mobile/desktop app." >> >>
