Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of olegsivokon@gmail.com
 designates 209.85.210.175 as permitted sender)
Received-SPF: pass (google.com: domain of olegsivokon@gmail.com designates
 10.50.161.196 as permitted sender) client-ip=10.50.161.196;
MIME-Version: 1.0
In-Reply-To: 
 <EB6F7A48D477254EAB8F675582F80CD7131506@DPSBS1.digitalprimates.local>
References: 
 <EB6F7A48D477254EAB8F675582F80CD7130DD3@DPSBS1.digitalprimates.local>
	<CB6F2715.3CA20%aharui@adobe.com>
	<CAJQBtgkiNyxSN6khyJN8BbQDNsCJMBLMVDzNaDWFrFfpMeTLtg@mail.gmail.com>
	<EB6F7A48D477254EAB8F675582F80CD7131506@DPSBS1.digitalprimates.local>
Date: Sun, 26 Feb 2012 20:43:24 +0200
Message-ID: 
 <CAJQBtg=oYb78U=65bcWsqsQUjTb3UkcnhZDdR3UqE_PmKUTEew@mail.gmail.com>
Subject: Re: Compiler Array Implementation ( was Adobe / Apache / Spoon Flex
 Tour )
From: Left Right <olegsivokon@gmail.com>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=14dae934051b697b0c04b9e25ea6

--14dae934051b697b0c04b9e25ea6
Content-Type: text/plain; charset=ISO-8859-1

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.

Best.

wvxvw

--14dae934051b697b0c04b9e25ea6--