incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Wienberg <fr...@jangaroo.net>
Subject Re: [FlaconJS] pseudo emitter algorithm
Date Mon, 03 Dec 2012 08:44:05 GMT
On Mon, Dec 3, 2012 at 6:45 AM, Alex Harui <aharui@adobe.com> wrote:

> On 12/2/12 2:21 AM, "Frank Wienberg" <frank@jangaroo.net> wrote:
> > When you look at Jangaroo-generated JavaScript code, it closely resembles
> > the original ActionScript source code. We optimized the compiler as well
> as
> > the runtime to give the impression that the JS code is actually the AS
> code
> > that you, the developer, wrote. Every source file results in a separate
> JS
> > file, which is also loaded separately in "debug mode".
> I'm ok with that as long as it loads reasonably quickly.
>

As we only use this strategy for debugging, which is usually done with a
local web app with almost no latency, and you can enable debugging on a
per-module basis, loading time is still reasonable. While more requests
have to be made, script downloads can happen in parallel. Jangaroo debug
mode only loads the classes actually needed (= static dependencies of the
main class), so this can even be an advantage over loading the complete
code of a module.

> Even the line
> > numbers are kept precisely. This allows for debugging directly in the
> > browser without the need for any additional / new debugger tools.
> > Of course, this approach would not be possible at all when generating JS
> > code from ABC, not from AS/AST.
> >
> > We would like to provide something similar for MXML, too. So the ideal
> > solution would be a mixture of the approaches described in this thread.
> > Combine Alex' datastructures and the AST->JS approach. This is also very
> > similar to how Ext JS UIs are specified using nested JS Object literals.
> If you look at the prototype, it does not use nested object literals.  I
> was
> unable to get them to perform as well as the data stream I am using or the
> methods it is replacing.
>

So maybe we could output different code for debugging and for production?


> > The idea would be to generate AS code from MXML that contains both the
> > datastructures and the code fragments (<fx:Script>), keeping the line
> > numbers (if possible).
> It is probably possible to maintain line numbers for script blocks, but
> what
> are the advantages of maintaining line numbers in MXML?
>

For the completely declarative stuff, break points are of course not an
argument. The only point that remains is that developers might better
recognize their own code during debugging the more it resembles the
original source.
When talking about script blocks, do you mean <fx:Script> only or also
inline event handler bodies? The latter should keep their line number, too.
Maybe even binding expressions could generate code that you might want to
debug (break when binding expression is re-assigned to property), but I'm
not sure whether this is possible at all.

-Frank-

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message