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 <c...@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.f...@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 >>
