incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sébastien Paturel <sebpatu.f...@gmail.com>
Subject Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Date Mon, 05 Mar 2012 11:32:10 GMT
I think we all agree with that.
And the SparkSimple lib would also need to be optionnaly linked to not 
penalize other projects.

The modularity of the framework has already been heavly discussed in ML 
and if i get it right its one of the main roadmap objectives (someone 
confirm that?)
The question is: can flex include any new lib before having fixed that? 
Will it take long to be achived? how can we organize those new lib 
within flex project without including it in the code framework?


Le 05/03/2012 05:21, Tony Constantinides a écrit :
> My issue with this whole issue is choice.
> Even if I select "Spark only" its loads the MX library core and  Spark
> components which are based on mx.core.UIComponent.
> I love the desire for backward compatibility but GIVE ME A CHOICE to cut
> the mx framework loose. Its still loads 6 RSL
> with its loading time which people use as the excuse to dump Flex. Unless
> this is FIXED, this framework does not have a
> snowball chance of Hell of every be successful.
> Suggestion: Based Spark classes on a SPARK base framework class and not
> mx.core.UIComponent with its 14 thousand
> lines of code.
> Over engineered much?
> I already building up my own Spark custom framework rather than the one
> from Flex 4.6.
> I basically getting components only as 1/3 as big and running nice and
> fast. Although I like the Flex framework
> I like to use less functionality and get smaller components than the option
> of loading two frameworks
>
>
> On Sun, Mar 4, 2012 at 7:19 PM, Michael A. Labriola<
> labriola@digitalprimates.net>  wrote:
>
>>> In Conclusion in my opinion:
>>> Spark should be the base for all components from now on.
>>> MX should die mainly because we cant use it for Mobile and it is not
>>> based on Spark (that makes the SDK more hard to maintain).
>> MX can't die. It is still used by many more projects than Spark. It will
>> need to be maintained for the foreseeable future
>>
>>> A new components list based on Spark should replace MX for easy and
>>> simple skinning use cases.
>> I think it's fine to have a rich set of skins that you can use if you want
>> all of those styling attributes. I would hate to penalize every project
>> though. It still seems to me that, like HGroup and VGroup, we can extend
>> all of these classes and put them in a library... perhaps SparkSimple. It's
>> nothing but composed versions of the other classes with a more full
>> featured skin and additional style declarations. To me that would be the
>> way to solve both issue.
>>
>>


Mime
View raw message