incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Sheely <robshe...@gmail.com>
Subject Re: Why Spark? (was Re: s:Spacer (was Re: Missing Spark components))
Date Sat, 03 Mar 2012 23:20:59 GMT
Maybe we can build on the concept of the Spark BorderContainer (quoting the docs):

The BorderContainer container provides a set of CSS styles and class properties to control
the border and background of the container.

A set of subclassed Spark components with CSS styling implemented. Or more specifically, a
set of skins for the components that expose many properties for CSS styling. 


On Mar 3, 2012, at 12:18 PM, Cortlandt Winters <cort@cortwinters.net> wrote:

> I totally agree with this and will try to help with it.
> 
> On Sat, Mar 3, 2012 at 6:12 AM, s├ębastien Paturel <sebpatu.flex@gmail.com>wrote:
> 
>> Hi all,
>> Im new to the mailing list so sorry if i do mistakes :)
>> 
>> I'm personnally very concerned about the ease of learning curve of Flex
>> for new users.
>> Don't forget that the ease of use and power of this SDK suits to not only
>> enterprise scale projects. It will be more true when the cross compilation
>> to HTML5 will be a reality.
>> I intend to create a new thread about this subject in the mailing list.
>> 
>> But about Spark vs MX subject, i must say that MX components were very
>> important to easely learn flex, and new spark components were harder to use
>> at first to do only simple skinning, even if the flexibility made it more
>> powerfull.
>> That said, Spark vs MX war has no sens since they refer to very different
>> use cases with pro and cons:
>> MX: Ease of use and quick simple skinning
>> Spark: Flexibility and power to create complexes skins and layout
>> We need both!
>> 
>> We could say that when the Spark components complete list will be
>> finished, you will still have the possibility to choose between MX and
>> Spark for your specific projects needs.
>> BUT: The main drawback for MX components is that you cant use them for
>> Mobile!
>> Thats too bad to not have a simple quick way of skinning when working on
>> Mobile projects.
>> 
>> The fact that we oppose Spark and MX is only because of flex's history.
>> But you should consider a components list dedicated to use cases for which
>> we would have chosen MX components.
>> This NEW components library would be (not like MX) based on Spark
>> components and expose basic skinning attributes easely in MXML (as MX).
>> That way a new lib equivalent to old MX could be used for Mobile.
>> And when a developper is stuck by the limitations of skinning
>> possibilities (like he would have been with MX) he still can use the Spark
>> base to freely do what he wants.
>> It should not be that much work to achieve that.
>> It must be carefully defined to manage Desktop and Mobile for easy
>> skinning components.
>> 
>> 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).
>> A new components list based on Spark should replace MX for easy and simple
>> skinning use cases.
>> 
>> What you think of it?
>> 
>> Thanks for reading
>> Seb
>> 

Mime
View raw message