Wish list for Apache Flex

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Wish list for Apache Flex

Carlos Rovira
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
Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Nick Collins
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 <
[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

João Saleiro
- public repositories for the SDK and other components
- plugin to generate flash builder / flashdevelop / FDT / etc project files
- Marvin Froeder subscribed here on the Flex mailing list :o)

João Saleiro


Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Jeffry Houser
In reply to this post by Nick Collins

  Do you have a use case for dynamic view states?  I can honestly say
I've never been limited by the current implementation.

  In the Flex 3 era you could define states on the fly; but it could be
a pain.  I have never dug into the underpinnings of the Spark State
system, though.

On 1/9/2012 11:37 AM, Nick Collins wrote:

> * 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.
>
>


--
Jeffry Houser
Technical Entrepreneur
203-379-0773
--
http://www.flextras.com?c=104
UI Flex Components: Tested! Supported! Ready!
--
http://www.theflexshow.com
http://www.jeffryhouser.com
http://www.asktheflexpert.com
--
Part of the DotComIt Brain Trust


Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

João Saleiro
In reply to this post by Nick Collins
Sorry, in my last email I deleted accidentally the first part:

On 09-01-2012 16:37, Nick Collins wrote:
> 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?


- public repositories for the SDK and other artifacts
- plugin to generate flash builder / flashdevelop / FDT / etc project files
- Marvin Froeder subscribed here on the Flex mailing list :o)

João Saleiro


Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Jonathan Campos
In reply to this post by Jeffry Houser
On Mon, Jan 9, 2012 at 10:42 AM, Jeffry Houser <[hidden email]>wrote:

>  Do you have a use case for dynamic view states?  I can honestly say I've
> never been limited by the current implementation.


I agree that "dynamic view states" isn't exactly clear to me. I could see a
need to official support for "multi-dimensional" view states though. This
was originally discussed with Adobe as a possible Flex addition. I'd be
interested in knowing if any work had been done on it.

--
Jonathan Campos
Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Michael Schmalle
Quoting Jonathan Campos <[hidden email]>:

> On Mon, Jan 9, 2012 at 10:42 AM, Jeffry Houser <[hidden email]>wrote:
>
>>  Do you have a use case for dynamic view states?  I can honestly say I've
>> never been limited by the current implementation.
>
>
> I agree that "dynamic view states" isn't exactly clear to me. I could see a
> need to official support for "multi-dimensional" view states though. This
> was originally discussed with Adobe as a possible Flex addition. I'd be
> interested in knowing if any work had been done on it.
>
> --
> Jonathan Campos
>

I agree to, something that would deprecate the;

[SkinState("titleAndViewAndMessageAndStarsAndIconWithoutContent")]

Mike


Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Jonathan Campos
On Mon, Jan 9, 2012 at 10:50 AM, Michael Schmalle <[hidden email]>wrote:

> I agree to, something that would deprecate the;


It will probably be something I will focus on. So I can get ride of:

<State name="portrait" stateGroup="portraitGroup, phoneGroup"/>
<State name="landscape" stateGroup="landscapeGroup, phoneGroup"/>
<State name="portraitTablet" stateGroup="portraitGroup, tabletGroup"/>
<State name="landscapeTablet" stateGroup="landscapeGroup, tabletGroup"/>
. . .

And all the other code required to make that work.
--
Jonathan Campos
Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Matthew Poole
+1 to the AOP idea

On 9 January 2012 17:06, Jonathan Campos <[hidden email]> wrote:

> On Mon, Jan 9, 2012 at 10:50 AM, Michael Schmalle <[hidden email]
> >wrote:
>
> > I agree to, something that would deprecate the;
>
>
> It will probably be something I will focus on. So I can get ride of:
>
> <State name="portrait" stateGroup="portraitGroup, phoneGroup"/>
> <State name="landscape" stateGroup="landscapeGroup, phoneGroup"/>
> <State name="portraitTablet" stateGroup="portraitGroup, tabletGroup"/>
> <State name="landscapeTablet" stateGroup="landscapeGroup, tabletGroup"/>
> . . .
>
> And all the other code required to make that work.
> --
> Jonathan Campos
>
Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Alex Harui
In reply to this post by Carlos Rovira



On 1/9/12 8:15 AM, "Carlos Rovira" <[hidden email]> wrote:

> * Dinamic View States
>
> ...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.
>
Adobe has some work in this area that will likely get contributed.

> * AOP
>

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 folks
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 to
do in AOP.
 
> * Flex Core refactor (SystemManager, Managers -PopUpManager,...-)
>
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.
>
> * Maven support
It is the #1 vote on JIRA.  Just need someone to start working on it.

>
> * Metada Evolution and DI frameworks support
>
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 to
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 to
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 not
already in there and get votes for it.

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


Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Alex Harui
In reply to this post by Jonathan Campos



On 1/9/12 8:45 AM, "Jonathan Campos" <[hidden email]> wrote:


> I agree that "dynamic view states" isn't exactly clear to me.
This is probably just MXML/AS equivalence.  Can you do everything in AS that
you can do in MXML.  It is not quite possible or very hard for states and
transitions today.

> I could see a
> need to official support for "multi-dimensional" view states though. This
> was originally discussed with Adobe as a possible Flex addition. I'd be
> interested in knowing if any work had been done on it.
There were only discussions at Adobe.  There is no code to contribute.

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


Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Michael Schmalle
In reply to this post by Alex Harui
Quoting Alex Harui <[hidden email]>:

>
>
>
> On 1/9/12 8:15 AM, "Carlos Rovira" <[hidden email]> wrote:
>
>> * Dinamic View States
>>
>> ...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.
>>
> Adobe has some work in this area that will likely get contributed.
>

>> * Flex Core refactor (SystemManager, Managers -PopUpManager,...-)
>>
> 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.
>>

Alex, can you say what your framework classes are based on? Is this  
something where mobile and multi-touch can be used/composed but the  
framework not dependent on them?

I'm very much interested in this because I have messed around with  
lighter weight classes that use multi-touch in some music applications  
I have made.

Mike




Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Alex Harui



On 1/9/12 10:31 AM, "Michael Schmalle" <[hidden email]> wrote:

> Alex, can you say what your framework classes are based on? Is this
> something where mobile and multi-touch can be used/composed but the
> framework not dependent on them?

My current thoughts are to create a framework that is very granular and uses
lots of composition.  I have prototypes where HelloWorld is a 28K swf.

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


Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Doug McCune
>
> My current thoughts are to create a framework that is very granular and
> uses
> lots of composition.  I have prototypes where HelloWorld is a 28K swf.


Alex, does the Apache style of individual user contributions lend itself
better to flushing this out? This is clearly something you've been working
on at Adobe, but does the fact that Flex is now an Apache project and you
are acting as an individual contributor and not as an official Adobe person
matter in terms of reducing the friction of you sharing this kind of code?
i.e. Would you have held back longer from pushing this code out publicly
prior to the move to Apache?

If so it seems like the move to Apache is already bearing some fruit in
terms of more open code development.
Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Alex Harui



On 1/9/12 12:15 PM, "Doug McCune" <[hidden email]> wrote:

>
> Alex, does the Apache style of individual user contributions lend itself
> better to flushing this out? This is clearly something you've been working
> on at Adobe, but does the fact that Flex is now an Apache project and you
> are acting as an individual contributor and not as an official Adobe person
> matter in terms of reducing the friction of you sharing this kind of code?
> i.e. Would you have held back longer from pushing this code out publicly
> prior to the move to Apache?

I'm still trying to understand whether I am acting as an individual or as an
employee of Adobe.  I think it is actually the latter.  Adobe still owns the
work I do and it has to pass legal clearance.

I believe that the key difference working with Apache is that I don't have
to convince managers and product managers and business folks before checking
in code to Apache (but I still have to convince Legal).  We didn't have
resources to allow critical folks like me to spend too much time exploring
ideas.  There were always deadlines to meet to make our paying customers
happy.

In Apache, I have to make sure I contribute enough shorter-term stuff to
make the project successful so Apache Flex continues to have customers, but
we will hopefully have tons of folks contributing their own short-term stuff
as well so I will hopefully have time to continue to massage longer-term
ideas and get folks involved in that as well.

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


Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Matthew Poole
>>AOP is probably a language thing, which we do not have control of.
Fair point Alex, AOP probably would better be a language feature rather
than a framework feature. Though we might see something sooner if we
implement it as a framework feature.

Having said that if enough f the micro-architecture frameworks implement a
byte code manipulation approach perhaps that is sufficient. That poses an
interesting question in terms of what flex is and what it becomes. Is it a
UI framework, boiler plate, micro-architecture, all of the above?

Do we need to establish what the high level goals of the framework are?

Matt

On 9 January 2012 20:33, Alex Harui <[hidden email]> wrote:

>
>
>
> On 1/9/12 12:15 PM, "Doug McCune" <[hidden email]> wrote:
>
> >
> > Alex, does the Apache style of individual user contributions lend itself
> > better to flushing this out? This is clearly something you've been
> working
> > on at Adobe, but does the fact that Flex is now an Apache project and you
> > are acting as an individual contributor and not as an official Adobe
> person
> > matter in terms of reducing the friction of you sharing this kind of
> code?
> > i.e. Would you have held back longer from pushing this code out publicly
> > prior to the move to Apache?
>
> I'm still trying to understand whether I am acting as an individual or as
> an
> employee of Adobe.  I think it is actually the latter.  Adobe still owns
> the
> work I do and it has to pass legal clearance.
>
> I believe that the key difference working with Apache is that I don't have
> to convince managers and product managers and business folks before
> checking
> in code to Apache (but I still have to convince Legal).  We didn't have
> resources to allow critical folks like me to spend too much time exploring
> ideas.  There were always deadlines to meet to make our paying customers
> happy.
>
> In Apache, I have to make sure I contribute enough shorter-term stuff to
> make the project successful so Apache Flex continues to have customers, but
> we will hopefully have tons of folks contributing their own short-term
> stuff
> as well so I will hopefully have time to continue to massage longer-term
> ideas and get folks involved in that as well.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Wish list for Apache Flex

Roland Zwaga
I guess I'll have to chime in here then :)
Right now I think having AOP as a framework feature is the most realistic,
once Falcon fully drops
we might start to see compile-time weaving, but for run-time dynamic
proxies it might be an idea to
make it a framework feature.
I am the author of as3commons-bytecode (
http://www.as3commons.org/as3-commons-bytecode/index.html),
which is the low-level bytecode manipulation library that most of the
micro-frameworks are using as a basis for
their AOP features. Should there be interest in somehow integrating this
library I'll be happy to help out, or, if
there is a need for a different kind of API, I'd still be willing to lend a
hand since I've spent quite a while
spelunking through the caverns of ABC bytecode :)

Roland

On 9 January 2012 23:02, Matthew Poole <[hidden email]> wrote:

> >>AOP is probably a language thing, which we do not have control of.
> Fair point Alex, AOP probably would better be a language feature rather
> than a framework feature. Though we might see something sooner if we
> implement it as a framework feature.
>
> Having said that if enough f the micro-architecture frameworks implement a
> byte code manipulation approach perhaps that is sufficient. That poses an
> interesting question in terms of what flex is and what it becomes. Is it a
> UI framework, boiler plate, micro-architecture, all of the above?
>
> Do we need to establish what the high level goals of the framework are?
>
> Matt
>
> On 9 January 2012 20:33, Alex Harui <[hidden email]> wrote:
>
> >
> >
> >
> > On 1/9/12 12:15 PM, "Doug McCune" <[hidden email]> wrote:
> >
> > >
> > > Alex, does the Apache style of individual user contributions lend
> itself
> > > better to flushing this out? This is clearly something you've been
> > working
> > > on at Adobe, but does the fact that Flex is now an Apache project and
> you
> > > are acting as an individual contributor and not as an official Adobe
> > person
> > > matter in terms of reducing the friction of you sharing this kind of
> > code?
> > > i.e. Would you have held back longer from pushing this code out
> publicly
> > > prior to the move to Apache?
> >
> > I'm still trying to understand whether I am acting as an individual or as
> > an
> > employee of Adobe.  I think it is actually the latter.  Adobe still owns
> > the
> > work I do and it has to pass legal clearance.
> >
> > I believe that the key difference working with Apache is that I don't
> have
> > to convince managers and product managers and business folks before
> > checking
> > in code to Apache (but I still have to convince Legal).  We didn't have
> > resources to allow critical folks like me to spend too much time
> exploring
> > ideas.  There were always deadlines to meet to make our paying customers
> > happy.
> >
> > In Apache, I have to make sure I contribute enough shorter-term stuff to
> > make the project successful so Apache Flex continues to have customers,
> but
> > we will hopefully have tons of folks contributing their own short-term
> > stuff
> > as well so I will hopefully have time to continue to massage longer-term
> > ideas and get folks involved in that as well.
> >
> > --
> > Alex Harui
> > Flex SDK Team
> > Adobe Systems, Inc.
> > http://blogs.adobe.com/aharui
> >
> >
>



--
regards,
Roland

--
Roland Zwaga
Senior Consultant | Stack & Heap BVBA

+32 (0)486 16 12 62 | [hidden email] | http://www.stackandheap.com