I agree with the people that thinks that "spark was the best thing happen in Flex4". Until Flex 4 skinning was limited and a pain. Right now skinning is soooo much easy. Why people thinks the opposite let me think that they does not understand how to use skinning in the right way.
For example I see many people using views and components directly in MXML and using external Presentation Models...The recommended way is to use views and components in AS3 that holds the logic you will use in your Presentation Model and separate the representation in a MXML (again for views and components). In this way you can effectively put all your skins and css in an externa SWC and change all the apperance of your application. mx was monolitich with kilometric methods with logic and representation mixed making separation of concerns impossible. With spark a huge step in separation was done, and in many components the logic is better distributed. A evolution in spark (the right way) should continue the separation of concerns since some core components continue to have thousands lines of code. To all the people that state that prefer mx over spark I would ask they try to learn more about spark and try to figure why many things was done in that way. Again not all is positive and as many people stated here before, many things was done to accomodate Flash Catalyst and maybe this is some of the overhead and negative things. But the approach is great, and people should try to avoid prestablished thoughts and learn more. I'm sure they will find a great component set with a great architecture that we should evolve and maintain. Still there's many bugs 2012/3/24 Tink <f...@tink.ws> > You can't design and preview skins in Illustrator, Fireworks and Photoshop > and export as FXG? > > Tink > > > > > Left Right <olegsivo...@gmail.com> wrote: > > >I think that the most important motivation behind new skinning system was > >that assets imported from Flash CS aren't editable / aren't fully editable > >in other editors commonly used for Flex framework. Since new skins are all > >in plain text, they eliminate this restriction. However, several important > >advantages of previous system were lost. The preview at the time of > >developing the skin is very important, but no tool exists to fairly > preview > >Spark skins until they are actually used. For reasons beyond my > >comprehension, the skins had to inherit from UIComponent. Combined > together > >these two disadvantages are a show-stopper for many projects / workflows. > > > >Now, the problem with promising that this is going to be fixed any time is > >that: > >- If we want to consider some graphic tool for designing the GUI, what > tool > >should it be? > >- New skinning system is the most significant change in Halo to Spark > >transition, if it is dropped, then there's basically no reason to use > Spark > >at all. So, patching Spark components in attempt to alter the way they use > >skins would be a major rewrite anyway. > >- There isn't any solid plan, neither less solid goals or even intentions > >expressed as about what would be the priorities of Apache version of the > >framework, so I don't think there may be a reasonable answer. Maybe this > >will be addressed, maybe it won't be, maybe the problem will perish > because > >of the development taking a completely different turn... > > > >Best. > > > >Oleg > -- Carlos Rovira Director de Tecnología M: +34 607 22 60 05 F: +34 912 35 57 77 <http://www.codeoscopic.com> CODEOSCOPIC S.A. <http://www.codeoscopic.com> Avd. del General Perón, 32 Planta 10, Puertas P-Q 28020 Madrid
