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<
labri...@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.
