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

Reply via email to