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. An MXML component can inherit
from an AS class and vice versa. 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.

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?
Or is my understanding wrong? How would you use an MXML component from AS3
code if it is not a class? Can you still "mix and match"?

Hoping someone can shed light on all of this,
*-Frank-*

Reply via email to