incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Collins <ndcoll...@gmail.com>
Subject Re: Wish list for Apache Flex
Date Mon, 09 Jan 2012 16:37:09 GMT
Out of curiosity, what Maven support are you looking for that Flex-Mojos
doesn't provide, other than being natively integrated into the compiler,
perhaps?

Nick Collins

On Mon, Jan 9, 2012 at 10:15 AM, Carlos Rovira <
carlos.rovira@codeoscopic.com> wrote:

> Hi,
>
> I would want to share my thoughts about what changes would like to see in
> forthcoming Apache Flex releases (far beyond 4.6.1 that would bring nothing
> new AFAIK and will be only serve to put the project in the new Apache
> rails). I'm referring to Apache Flex 4.7, 4.8, 4.9...and so on.
>
> This is only my opinion and as I said I can't help right now in this issues
> until I get the time to support Apache Flex with my own work, so it's only
> my desired changes or new features that I would like to share here to give
> you some points that I think it would be great to have in Apache Flex:
>
> * Dinamic View States
>
> we have fully support of "dinamic skin parts" in Flex 4 and work great, but
> one thing we need too is "dinamic view states". Right now view states need
> to be declared in the AS3 class and in the skin. So this is all very
> "declarative". 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.
>
> * AOP
>
> With all new avances in this field in the last year (see James Ward /
> Michael Labriola -Planet of AOP's or Swiz 2 beta AOP feature), I think Flex
> should provide AOP in its core framework. We need to make it more
> transparent to the end user and stablish the preloading hooks to
> instrumentalize the classes when we load the bytecode in order to be able
> to change that code before it loads in the AVM. I think this is completly a
> Flex framework responsability.
>
> * Flex Core refactor (SystemManager, Managers -PopUpManager,...-)
>
> The Flex core framework has many out date code that brings many problems
> nowadays due to monolitic code or poorly designed code. This is normal in a
> framework that has now 6-7 years (I talking since Flex 2 since Flex 1.x was
> AS2), and has code from that period. Today we know more techniques and
> things evolved so we should refactor many internal things that today are
> obsolete and are limiting the way to growing and introduces several bugs.
> I'm referring to all the code that glues all the framework: SystemManager,
> PopUpManager, and so on...
>
> * Maven support
>
> I commented this already, but as I think this is really importante to
> succed in the enterprise market (and this is the main Flex use case) I
> state this again... Maven support, Gradle support...are really important if
> we want Flex to survive. We can't handle huge applications repositories if
> we don't have this kind of tool that ensure that our builds are well formed
> and constructed with the right external and internal library versions.
>
> * Metada Evolution and DI frameworks support
>
> Metadata should continue to evolve and support current DI frameworks like
> Swiz or Parsely.
>
>
> This is some of the things I list here and now, but I think I would come
> with more as I have time.
>
> And you? what are the things that you would want to see in Apache Flex
> (change, new features,...) , I think this kind of thread is needed now that
> the list are working for a week or so... I think we need to start to see
> some future horizont, although the first step would be to get the source
> code in Apache, and all initial commiters taking over the project to
> generate the 4.6.1 initial version).
>
> What do you think? Make sense this key points proposals for future Apache
> Flex evolution?
>
> Thanks!
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F:  +34 912 35 57 77
>
> CODEOSCOPIC S.A. <http://www.codeoscopic.com>
> Avd. del General Perón, 32
> Planta 10, Puertas P-Q
> 28020 Madrid
>

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