On 1/19/13 8:15 AM, "Frank Wienberg" <fr...@jangaroo.net> wrote:
> After some time off, I just became aware of this discussion, and it has
> already become quite longish, so please forgive me if I missed or
> misunderstood some arguments.
>
> That said, my understanding of MXML is that it is just another (for some
> use cases more convenient) syntax to write an ActionScript class. From
> MXML, you can use any other AS class that has a no-arg constructor and
> properties, and from AS, MXML components can be referenced like normal
> classes, too. When using a component library, you do not even know whether
> the components were written in AS or MXML.
All true.
> An MXML component can inherit
> from an AS class and vice versa.
Mostly true, there are some restrictions and pain points.
> I find this mix-and-match approach very
> charming. And if that is the correct semantics, I don't see any reason to
> not generate JavaScript code from the (temporary) AS class generated from
> MXML.
I believe compilation speed is the main reason Falcon goes straight to ABC.
It should also let us hand optimize certain patterns.
>
> Now in this thread, I read that you should not generate an ActionScript
> class / JavaScript from MXML, but instead a data structure that gets
> instantiated into a component (later). That sounds like a similar approach
> to Ext JS, where they use object literals with "xtypes" as component
> descriptors, which can then be instantiated into "real" components as
> needed. Sounds good, too, and indeed has some advantages ("lazy"
> components), but how does that go together with the "old" approach of MXML?
It is still a class, but instead of mapping MXML tags to methods, I'm
generating an array of values. Object literals are too slow, at least in
AS. The old MXML generated code generated a lot of methods and if we needed
to change the code in those methods, we had to change the compiler. Falcon
has a chance of being more version independent if it just generated data
instead of code, and developers don't have to learn how to build the
compiler to change the behavior of the SDK.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
