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 aharui@adobe.com designates
 64.18.1.29 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Tue, 14 Aug 2012 14:34:32 -0700
Subject: Re: New components code
Thread-Topic: New components code
Thread-Index: Ac16V02xJMR0vNmcQNCorkJHgumQKAADUnHI
Message-ID: <CC501278.44886%aharui@adobe.com>
In-Reply-To: <CC5024DD.19F6A%cframpto@adobe.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-Entourage/13.11.0.110726
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 8/14/12 12:59 PM, "Carol Frampton" <cframpto@adobe.com> wrote:

>=20
>=20
> On 8/14/12 3 :49PM, "Carlos Rovira" <carlos.rovira@codeoscopic.com> wrote=
:
>=20
>> Hi Carol,
>>=20
>> I check your whiteboard to see the new components added but I miss a spa=
rk
>> DateField. We can expect to see it in your whiteboard at some time?
>=20
> I've said numerous times there is no spark DateField.  It was assigned to
> me but it was not started.
>=20
>>=20
>> On the other hand, I'm interested in do some work on dinamic view states=
.
>> I
>> remember that Alex said that some work was done in Adobe regarding this
>> feature, so I would want to ask if there's something done, if it is is
>> checked? what level of completion has?
The states work was being prototyped as part of the Falcon/MXML work.  It
was separate from the Flex.Next components.

I will have to find it and see if I can just check it in w/o having to go
through the usual process.

That said, the reason this kind of thing was being prototyped was because
Falcon was supposed to be SDK version independent.  IOW, it was going to be
integrated into and shipped with Flash Builder.  SDKs could be shipped
independently.  The plan was to take all of the current generated code and
generate data structures instead and have SDK code interpret the data
structures (which turned out to be faster in almost every case).  By turnin=
g
the states generated code into data structures it would be possible to
create a library to generate and manipulate those data structures at
runtime.

Now with Falcon at Apache, we have no guarantee that Flash Builder will be
able to successfully incorporate an Apache-built Falcon compiler into Flash
Builder.  IMO, there isn't a very good abstraction layer between the
compiler and the rest of FB.

So, we may end up with Falcon being packaged and run more like MXMLC.  The
MXMLC scripts might just get changed to call into Falcon for example.  And
that eliminates one major reason for taking the time to finish this kind of
code.  A safer route which is much farther along already is to try to make
sure Falcon generates the same AS code as MXMLC.  Then you know you're less
likely to hit new issues at runtime.

--=20
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui