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.181 as permitted sender)
From: Alex Harui <aharui@adobe.com>
To: "flex-dev@incubator.apache.org" <flex-dev@incubator.apache.org>
Date: Mon, 9 Jan 2012 10:21:40 -0800
Subject: Re: Wish list for Apache Flex
Thread-Topic: Wish list for Apache Flex
Thread-Index: AczO6fkPJzKImFuTQOebzWdleMkhHAAEY7ls
Message-ID: <CB307034.39731%aharui@adobe.com>
In-Reply-To: 
 <CAMFKFRg6_0QbfLxhQQhVo-JqaihHzTDq-oeyCi9=qeKiUb42=w@mail.gmail.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 1/9/12 8:15 AM, "Carlos Rovira" <carlos.rovira@codeoscopic.com> wrote:

> * Dinamic View States
>=20
> ...We need the capability to create states on the fly and let
> other parts handle this dinamic view states (transitions,...). Without
> this, view states are a bit limited.
>=20
Adobe has some work in this area that will likely get contributed.

> * AOP
>=20

AOP is probably a language thing, which we do not have control of.  As soon
as you start bytecode manipulation, you are no longer programming in
ActionScript and prone to even more debugging and analysis issues than folk=
s
who used to mix C and Assembly.  I would first want to see why a better
composition model for features can't do pretty much everything you'd want t=
o
do in AOP.
=20
> * Flex Core refactor (SystemManager, Managers -PopUpManager,...-)
>=20
My whiteboard folder will eventually include a completely new framework
based that will be mostly backward compatible with Flex but will have
smaller base-classes, a minimal DI implementation, and not use AS features
that are hard to cross-compile to JS.
>=20
> * Maven support
It is the #1 vote on JIRA.  Just need someone to start working on it.

>=20
> * Metada Evolution and DI frameworks support
>=20
I'm very much against the use of metadata at runtime.  It is a whole other
language that is not first-class in the VM and probably will never be, and
currently does not have any ties to ActionScript.  The kinds of DI used at
the application framework level by Parsely and Swiz don't need to be tied t=
o
the same DI in the framework and probably shouldn't be for performance
reasons.  It is different to inject a large application model once vs
injecting a data model for every component.  Now if we find a good DI
implementation for the framework layer, application frameworks may decide t=
o
borrow or extend it, and I'm pretty sure the framework DI will not be
parsing metadata at runtime.

Once we get JIRA up and the old issues ported, enter issues for anything no=
t
already in there and get votes for it.

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