incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: New components code
Date Tue, 14 Aug 2012 21:34:32 GMT



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

> 
> 
> On 8/14/12 3 :49PM, "Carlos Rovira" <carlos.rovira@codeoscopic.com> wrote:
> 
>> Hi Carol,
>> 
>> I check your whiteboard to see the new components added but I miss a spark
>> DateField. We can expect to see it in your whiteboard at some time?
> 
> I've said numerous times there is no spark DateField.  It was assigned to
> me but it was not started.
> 
>> 
>> 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 turning
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.

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


Mime
View raw message