flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Forking the Falcon compiler for Starling/Feathers MXML generation
Date Tue, 01 Mar 2016 22:24:07 GMT
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.


On 3/1/16, 2:16 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@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
>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
>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.
>On Tue, Mar 1, 2016 at 1:35 PM, Alex Harui <aharui@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
>> 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,
>> 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
>> 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
>> 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" <teotigraphixllc@gmail.com>
>> >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
>> >It
>> >also means I would have a monetary reason to be able to contribute to
>> >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
>> >in.
>> >
>> >Background; I have worked extensively with the Falcon compiler mainly
>> >creating/writing the FalconJX compiler FlexJS uses to cross compile
>> >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
>> >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
>> >MXML generation or even how to start.
>> >
>> >I do understand "what" the original compiler does as far as setting up
>> >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
>> >be
>> >done since then we could add a whole bunch of specific things that
>> >enhance the dynamic nature of constructing a Starling/Feathers
>> >mobile/desktop app."

View raw message