Thoughts on Spark and Skinning
Recently while talking to other D-Flex developers about the new Spark Architecture and Spark Skinning I’ve been hearing lots of complaints. Without talking about other projects like Reflex and their pros and cons there are many people that seen to have some sort of fundamental issue with Spark Skinning and the Spark Component model.
I start by saying that I honestly like the Spark model and decoupling the view from the component’s logic.
I want to go into a few argument points that seem to keep coming up and my thoughts on them. I will let you know now that as I am starting to write this I’m not 100% sure where this post will end up – but there is some fun in that right?
Spark Skinning breaks inheritance and causes for lots of code rewrite.
The first argument I keep hearing is how you can’t follow inheritance with Spark Skinning. People keep complaining that to make a simple change requires an entire new skin and that it is a waste of coding.
Why are you reusing skins? Usual design skins are going to be unique to the project and piece you are making, if you are really needing to reuse the skin just apply the skin to another component. But if I want to make one small change I have to make a new skin? Really? Have you not heard of CSS? Many developers that I’ve seen getting into Spark Skinning seemed to have forgotten that they can use CSS on their Spark Skins. You have some amazing skin that you want to change from Red to Blue? Go for it! Add a simple style and use CSS. Now your skin can be used and changed while keeping the same underlying code.
But you still say you want to reuse your skins and CSS isn’t enough? Go for it, break down and make the skin in total Actionscript, it’s really not that hard, and you can use your inheritance. Now is all that coding really worth it to be able to make the Skins that support inheritance? If so congrats, you’ve done a good job. If not, maybe you should have just copied and pasted a skin together and made the one change you needed to make that CSS couldn’t handle.
I’m honestly tired of all the developers on their high horse preaching about perfect architecture when they can’t even get their job done because they spent so long debating which design pattern would be best to handle some crazy problem.
I am a fan of good architecture and like to make sure that a plan is followed and standards are achieved, but when there isn’t any real benefit and you’re arguing over semantics then I think you are arguing for arguing sake and I’m not listening.
I don’t like MXML, I want to Skin in Actionscript
Okay, go for it. No one is stopping you. And you can do anything that is done in MXML in Actionscript.
Doesn’t using a specific HostComponent tightly couple a Skin to a Component?!
Yes, but when are you going to be using a List skin on a Button? The Skin needs to know what it is being attached to. This is a one way coupling and makes sense to me. How would you repurpose a skin without changing what component it is going to?
Skinning takes to long
Yes, skinning takes a while. If you want something to look custom, then you’ll have to put in the time to make it. If you don’t like skinning then just use CSS and the styles that the Flex team has provided. That’s basically all the options you had in Flex 3 anyways.
Skinning creates twice as many visual components as Flex 3 components
Actually, while there are plenty of visual components that are created, I think that one thing many people forget is that the main component actually isn’t a visual component. All that code is actually lifted off the visual display list.
Skinning allows for coding to go on in the skinning class
Yes you CAN do a lot of coding in the skinning class. These classes follow the full Flex component lifecycle and you can make an entire application with code in your skin class… not that you SHOULD.
Some people see this as a major flaw to the entire skinning architecture, I see it as choice.
While I don’t appreciate junior dev putting services in a skin file, I do appreciate the option to have it there for that one weird case that coding like this makes sense. However the architecture and framework shouldn’t limit you, that would just make our jobs harder as we do lots of code around.
We all should learn best practices, code in ways that reduce confusion, keep code DRY, respect encapsulation, and maintain reusability but we should be free to bend these rules.
[...] This post was mentioned on Twitter by Jonathan Campos, CT. CT said: Flex News: Thoughts on Spark and Skinning: Recently while talking to other D-Flex developers about the new Spark A… http://bit.ly/aVot7r [...]
“Why are you reusing skins?”
Yeah, I see no reason to reuse an IconButton in two different project. =X
Spark made “uber complex” things easier to be done, so now it is just “little complex”. But it also made extremely easy things into just “little complex”. And that is what bother people, the easy to use halo components are now turned into the little complex spark….
In halo I couldn’t make my button to dance, yeah, you are right I couldn’t. But on spark I can’t just use button, I have to make it…. that really really pissed me.
I avoid spark as much as I can, use it only if I have no choice….
@marvin
I knew that one of the first comments I would get would be about the infamous “IconButton”. For your IconButton, have you thought about making it just once and using CSS and styles for the rest of your applications? I ask because it’s really not a big deal. I did it the first time in about 5 minutes and was well set from then on.
When I asked “why are you reusing skins” was for the simple fact that designs are usually unique to the application. More than likely the skin that is used in one app won’t match the design for a second. And if your designs are that similar, use CSS and you’re done.
Now what do you mean by “But on spark I can’t just use a button, I have to make it.” You could just use it unless you want to do something custom. I’m confused here.
@Marvin
Also check out Flex 3 compatibility mode and using the Halo Theme. Your default skins will closely match the same Halo functionality.
I think the worst thing I can say about the skinning in Flex 4 is that the complex components are really only skinnable by looking through the source code. Did you know that hidden amongst all the supported CSS properties for the scrollbar is something that allows you to create a thumb button with a fixed height, and that by default you should make your thumb buttons scale to the given height and width using top and bottom? Not without looking through the source code for how it’s coded and the skin parts are fit together in the default spark skin.
The other thing I’m having a lot of trouble with is hover tweens, which aren’t too bad with text-only skins, but get a little hairy when using Rect’s and Path’s. Currently I have some code in updateDisplayList that updates a bindable fill using the baseColor CSS property, but there should really be a better way to do that.
@stephen
I completely give you that! I’ve learned a lot of information from looking at the source code. At times I forget what I’ve learned and how hard it may be for someone that hasn’t read through tons of source code.
Also, have you tried doing Scale9 in Spark Skinning? That takes some extra effort too!
>>> Now what do you mean by “But on spark I can’t just use a button, I have to make it.” You
>>> could just use it unless you want to do something custom. I’m confused here.
If I need a IconButton, I need to make it, if I need a LinkButton I need to make it, if I need a IconLinkButton, guess what, I have to make it…. spark doesn’t offer none of this.
Converting a really simple project, with just 10 classes forces me to have 3 times more classes just to handle stupid simple things. That is what sux on spark it make simple stuff hard as complex stuff…..
Spark is hard? No. Is easier then Halo? Depends, if you wanna do something extremely simple on halo then Spark is 10 times more complex. If you wanna something extremely hard to do on Halo then Spark is 3 times simpler.
>Also, have you tried doing Scale9 in Spark Skinning? That takes some extra effort too!
Is it possible to have an FXG element scale9-ed at this time? Could you pls share the links to the resources that discuss that… It is the #1 requested feature in the FC Jira, wondered if there is a hack for that.
@Djam I have a way to do it in a spark skin, never tried it in FXG. I’ll make a blog post with how.
@Campos Thanks
@Marvin The best thing about Spark framework is that there is simply less pre-baked components. Instead, Adobe focused on giving you more control in terms of customization, while providing lighter (file size) finished products.
You really should contribute to the growing number of customized components like http://www.tink.ws/blog/spark-datanavigators/ has done. Encourage Adobe to continue focusing on the framework and making it simple to customize. Spark favors composition over inheritance – better practice.
“Adobe’s job is not to pre-bake everything for you, but make it easier for you to bake”
” Give a man a cake and you feed for a day. Streamline his baking and you feed him for a life time” – Forrest Kyle
If you’d like to see more Spark component delivered more quickly / distributed in an Adobe-supported way, you can vote for this idea: http://j.mp/94DaFD.