incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Left Right <>
Subject Re: Compiler Array Implementation ( was Adobe / Apache / Spoon Flex Tour )
Date Sun, 26 Feb 2012 18:43:24 GMT
I've explained how that could be avoided in a more generic way in the end
of the paragraph - why cannot that be a solution? It's ultimately the same
mechanism, as you would add event handlers, actually. If you think about
old MXMLC code, you could even use the part that generated event handlers
to do that. The benefit would be that:
1. You can later override this behavior by providing your own
implementation of a function that generates child components.
2. Much easier to use, when creating same components w/o MXML.
This is not entirely a foreign concept - all sorts of labelFunction's and
itemRendererFunction's work in a similar way.

Imagine something like this:

// compare to this._dispatcher.addEventListener("eventType",
this.eventHandler); ?
. . .
this._navigator.addTab("tabTitle", this.makeTab);
. . .
protected function makeTab(title:String):Tab
    var tab:Tab = new Tab(title);
    tab.setStyle("whatever", doesnt, matter);
    return tab;

Not ideal, but no additional objects are created + more experienced
developers would be able to provide makeTab() implementation which can be
smarter (same function for multiple tabs / generate content based on data).
The makeTab() function may be identified through [DefaultProperty]
metadata, for example.

The generated "descriptor" on the other hand, is not reusable, it's just
some amorphous chunk of data. Of course, it never was a good idea to extend
MXML components, but this is not a requirement, given normal code
generation, this limitation can be lifted.



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