Ha,
I just spent 2 hours looking at the code in FalconJS to try and
understand the pattern.
From a highlevel I get what they are doing but when it actually comes
to programming, there is so much indirection and composition I highly
doubt I could even attempt to use this pattern to create anything in
the next 2 years.
I have experience with code emitting but it used actual AST, no JBurg
and no reducers etc.
I may be getting confused to what is actually needed in a simple cross
compiler but to me it seems;
- gather all sourcepaths
- gather libraries
- execute a build target that will create the compilation units
- create a walker/visitor/emitter framework that recursively visits
each compilation unit
- foreach compilation unit emit the correct code that will create the
"mirror" platform code.
I know I must sound completely naive here but for what is trying to be
accomplished it seems that FalconJS is overly complicated for what it
is outputing.
From my research, it seems the engineers just copied a lot of classes
over from the ABC byte code generation framework and replaced things
to fit a javascript impl.
I know they created a "backend" API but to me again and PLEASE some
one that is 100 times smarter than me tell me I'm wrong in assuming to
create JS or Java you could just loop through compilation units and
use a hand written visitor/emitter?!
So.. really I am out of my ballpark with even trying to understand the
JS classes they have because they are connected to 100's of different
objects being passed around.
Mike
Quoting Michael Schmalle <apa...@teotigraphix.com>:
Ok,
Challenge accepted.
I was just looking through the cmc-js.jbg file. I actually think
this might be doable. The JavaScript impl looks very complicated
but, that's because it's doing a lot of things right now as far as
building the .js code.
I'm going to start small and see what I get. The first order of
business is just trying to hack together the base framework
(emitter) using FalconJS as a template.
If I can get C working we are going somwhere. That will take awhile,
I'll let you know what I discover.
Mike
Quoting Alex Harui <aha...@adobe.com>:
On 11/28/12 11:27 AM, "Michael Schmalle" <apa...@teotigraphix.com> wrote:
Are we creating just views? Are we creating business logic? As you can
see I have confused myself here.
What would be really kewl is if someone reading this says, Mike I bet
you can go from A to B to C then D. If I saw the whole prototype flow
in front of me I probably could make it work some how.
OK, so if you take the code I've checked in, the workflow is this:
A) Developer had FlexJSTestMXML.mxml and MyInitialViewMXML.mxml and Model.as
and Controller.as
B) I hand-converted FlexJSTestMXML.mxml to FlexJSTest.as and
MyInitialViewMXML.mxml to MyInitialView.as
C) I feed FlexJSTest.as and FlexJSUI.swc to FalconJS
D) I get a bunch of JS files
E) I mimic the AS controls in FlexJSUI.swc in js/framework.js
F) I hand-create an index.html to load all of the .js files
G) I run it in the browser (FireFox).
The parallel as I see it is that you start with B and:
C') Feed FlexJSTest.as and FlexJSUI.swc to FalconJava
D') You get a .jar
E') You mimic the AS controls in FlexJSUI.swc in java/framework.jar. They
should be thin wrappers on native Android controls, just like framework.js
is a thin wrapper on native HTML controls
F') You package it up into an APK.
G') You run it on Android device.
JBurg is just grammar, it took me about 3 months to finally learn
ANTLR and it's rewriting syntax. So if I had a clear path of what I
was trying to prototype with Java I would put time into learning JBurg.
What would be interesting is paralleling what you are implementing in
JS (your proto components) with Java Android. I know some people would
say this is ridiculous but it would be a path to a prototype.
What I don't know is if it is 'ridiculous' or not. If it isn't, it could be
pretty cool.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
