On Tue, Mar 1, 2016 at 2:24 PM, Alex Harui <aha...@adobe.com> wrote: > That's a valid approach as well, but probably has the overhead of wrapping > a lot of their classes to conform to IUIBase.
Do you mean work overhead? That would be a one time thing, right? Or runtime overhead? I doubt if porting over stuff to conform IUIBase would cause runtime overhead... > You would probably get a lot > of other things like Binding and States for free though. > Yes, biggest advantage is you get MXML support for free since everything is already set up. Thanks, Om > > -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." > >> > >> > >
