I’ve recently had the opportunity to dig into Flex 4 skinning a bit deeper with the latest beta. While there is a lot to be desired from the separation of concerns in moving display code into the skin and leaving logic code in the component, there is one LARGE gaping deficiency in Adobe’s model.
I’ve noticed a number of people here (Andy McIntosh), and here (Andy Hulstkamp) working with button icon skins. The main reason for this is that Adobe saw fit to remove the icon property from the Spark button. Being a visual element, it does make some sense for Adobe to let users specify a button icon inside a skin as opposed to putting it in the main Button component.
Now to address the LARGE gaping deficiency in Adobe’s model. Adobe developed the skinning architecture WITHOUT taking something into account that we developers use on a regular basis. This is the Object Oriented principal of Inheritance. Note the following excerpt from Adobe’s livedocs:
Try to encapsulate skinning code. Place code that is used by multiple skins in the component class. Place code that is specific to a particular skin implementation in the skin class.
Most skins use absolute layouts within the skin class.
When creating skins, do not subclass existing skin classes. Instead, copy the source of an existing skin class and create another class. Use this method especially if you are going to reuse the skin for multiple instances of a component or multiple components. If you want to change the appearance of a single instance of a component, you can use FXG inline.
When creating a Spark skin, you can use MXML, FXG, embedded images, or any combination of the above. You do not use run-time loaded assets such as images.
The inability to inherit skins is going to kill my productivity as a developer. For example, let’s say I really liked the code Andy McIntosh had done with the IconButton (which I do) and wanted to re-use it. Let’s say I’ve also done some work on button skinning for my application and I want nice looking gel buttons like this:
Can I set up my GelButtonSkin to inherit from Andy’s IconButtonSkin to take advantage of his image functionality, but override his background drawing with my own? The simple answer from Adobe is NO. In order to accomplish what I want, I’ve have to create a completely new skin class and use copy/paste from both my GelButtonSkin and Andy’s IconButtonSkin to get my desired functionality.
You might say, “Well, Adobe says in the quote above that code that is used by multiple skins should be placed in the component class”. This begs the question though… Why did Adobe remove icon as a button property in the first place? It’s obviously one of those things where you might want different flavors of it. Perhaps a rectangle button /w icon vs. a rounded button /w icon. Instead, we’ll see a fragmentation of Flex while everybody and their brother develops their own flavor of IconButton along with their own custom skins to do exactly what they want. Productivity for developers moving between projects is going to take a hit due to this lack of code re-use.
Note: This post is intentionally antagonistic. I’d love to be proven wrong on my assertions. If someone has come up with an elegant work-around to the problem of skin re-use and inheritance that doesn’t resort to copy/paste, I’d love to be educated and saved from my ignorance.
August 3rd, 2009 at 4:42 pm
So far, I saw all designer very happy with spark. Adobe really made spark with design in mind!
But, as you said, developers aren’t forgotten… may be not entirely, but this code reuse lack is very problematic….
Copy & paste will produce unmaintanable code…. imagine, Andy fixes a bug on icon button…. I will need to search all my code for that skin and replicate the fix…
But I will follow this, hopefully someone was smarter then I and find a fix for that.
VELO
August 3rd, 2009 at 11:46 pm
Hey Andrew,
This is not the only answer but let me take a crack. Our docs may be a little extreme in their wording, but I think it’s to make a point. We really think about the skins when a designer is involved, and gear our docs in this manner. Putting together a hierarchy of classes for skins is not very toolable. How does a designer look at a particular skin and then tweak it? We looked carefully at how designers work, do they think in terms of re-usable pieces, componentize, etc? They don’t! They copy/paste everything! And given that they operate this way, could we find a way to provide skins in a way that made sense to them, and deal with the complications if let’s say they copy a skin and then modify it just a little? If your skin was made up of some superclasses, what if the thing that the designer wanted to modify was not in the leaf? What if they essentially re-parented a base class component? That can’t be done easily in an MXML subclass. So to make skins easily modified by a designer, we recommend putting everything together.
Now, if you’re a developer and you’re only going to work in code with other developers once you get your hands on the skin (designers don’t get to modify in the tool) then maybe you can go ahead and do some hierarchy. Look at the Spark skins, we set up a base class with functionality, but those skins are not created by tools. We write those suckers by hand to make sure all the styling and whatnot is there. In the future, maybe we’ll be able to tool that, but not for now. If this model will work for you, we’re all for it. But we think if you’re going to really be working in a collaborative environment, the designers are not going to be able to handle the skins if you try to think of them as OO classes.
We’re open to feedback on this though, especially for how we can improve the dev side of this in the future.
Matt
August 4th, 2009 at 7:31 am
Velo and Matt. Thanks for your responses. Both make some sense. I think we need to take a look at doing our skins mostly in actionscript for those parts of skins that will be re-usable such as the button image above.
I just can’t see using copy/paste when maintaining a large app. Especially if we decided we needed to change something like how a transition worked in all 1000 text fields.
I guess for my own workflow, I don’t want a designer touching my code and copy/pasting junk everywhere. I’d rather take what they gave me and create something inheritable and re-usable.
Matt,
Have you thought about the possibility of allowing a SkinnableComponent take an array of skin classes? Then I could have a skin that did nothing more than the image and a second one that did my background and just layer them up or reuse them independently. I know there might be an issue with how SkinPart works and searching for those required parameters though.
August 4th, 2009 at 12:58 pm
I think you’re basically talking about making components take a composition of skins. That’s kind of what Halo does, it’s considered a fail according to our goals of making it easy for folks to swap things around in a major way.
Keep in mind that you can of course do things to make skins re-usable for multiple instances. Add styles, make things resizable, etc. Then just assign the same skinClass to your components. You can make a skin complex and it will then be usable however you want. Write it in AS or in MXML, it’s up to you. But as far as what we’re going to encourage, when the stated goal of the architectural change is enabling high-design, it’s going to be the methodology we’ve discussed. As people experiment in more enterprise-focused apps I think we’ll see where the appropriate mixture of approaches plays out.
August 4th, 2009 at 2:45 pm
I’m not sure what workflow you’re going for, but here, designers don’t touch code. They send us images for what they want along with annotations for behaviors. I don’t want them touching code due to the unmaintainable mess this would produce. I guess we’ll have to agree to disagree on this one and see how it plays out.
August 4th, 2009 at 11:57 pm
@Andrew, if you consider that all these changes to Flex skinning seem to be driven by Catalyst, the decisions do look at a lot more reasonable. It seems Adobe wants to get away from the workflow of designers giving PSDs to developers and instead they will give you completed skins or even a semi-functioning prototype. There is a cost to the developer but the benefit to the designer/developer workflow could be much greater, assuming your team gets on the Catalyst bandwagon like Adobe would like you to. Most likely future version of the rest of CS will be able to be more tightly integrated with Flex too.
August 5th, 2009 at 7:09 am
@Darren
The problem is how to reuse this catalyst code….
Imagine you develop a component… let’s say I made a Datagrid to sell (I know it exists and it is free, but let’s assume it doesn’t)…
I can’t sell just the SWC, I need to send the skin source as well, otherwise people won’t be able to skin it.
Or let’s think on this IconButton example…. how many IconButtons will exist around the world? If I need any change I need to create a new one, I can’t extends the original and do my changes.
This lack of code reuses really scares me. It reminds me an old software that I saw, where everybody copy n paste code for everything. No code reuse at all…. maintain that was extreme painful.
VELO
August 5th, 2009 at 7:55 am
@Darren,
I’m still not sold on catylist yet although it does look promising for our designers to work with for prototyping. It really all depends on how clean the generated code is and how maintainable. In all the demos I’ve seen, it’s either a black box of code, or they just don’t like to show us the generated code. If either of those cases is true, no catylist code will be making it into my final products. Call me old fashioned, but I don’t really trust code generators unless I can fully understand and modify the generated code.
August 5th, 2009 at 10:01 am
It scares me big time to hear that we should be copy/pasting code around. VELO made an EXCELLENT point that skins cannot be packed in a SWC file because you wont be able to extend them without handing out the source and having it “copied”. Then if a skin/component is updated, it becomes even more painful merging the differences. What if I don’t want to give out the source?
August 17th, 2009 at 5:35 pm
I’ve had a lot of success with degrafa and advanced css button skin available here: http://www.flexstuff.co.uk/2009/04/30/degrafa-extend-cssskin-to-skin-flex-buttons/ This generally allows me to build a single button, skin it’s states and pass in src variables for its relative up, down, over, disabled icons.
September 20th, 2009 at 10:41 am
Why not update the one skin (and IconButton) to include layout for an icon part? If the icon part has no size, simply don’t position things around it. Spark’s Button will ignore it and never set its source, and your skin will work in both?
December 1st, 2009 at 9:02 am
I have exact issue! I work on flex 4 project where I need designer to take care about design but also have flexibility to change certain elements at same time. I also wrote article about this issue with few work-arounds http://blog.paveljacko.com/?p=29 but I couldn’t find any really clean way how to achieve this goal. please let me know if you find better one:)
December 14th, 2009 at 7:41 pm
This whole post reaks of a lack of understanding of the flexibility and purpose of skins.
While it’s true that skins can not be subclasses, they can be made to be extremely flexible, using custom properties, or states to define their behaviour. There’s no reason you should be using a different skin for each TextField, rather design one robust flexible skin, which takes some parameters, and use that for everything.
In addition, Skins do NOT define functionality . They are simple components, which are only meant to define visual layout corresponding to a given state of a component. So there should be no real concern about updates, or bug fixes.
In the vast majority of cases, because of the nature of what skins do, any bugs should be quite minor and extremely easy to fix. Skins should not really contain super complex logic, or anything that would require some sort of major update.
And I guess as a final thought, having to extend skins would sortof destroy the beauty of them imo. The nice things about them is the FLEXibility, if you need to make a change just do it, and don’t worry about it. Don’t want to be saddled with a bunch of stuff you don’t need, just delete it…. it’s nice.
Everything doesn’t have to be OOP all the time. In some cases, such as this, an OO structure would be a drawback and make things harder rather than easier 90% of the time.
December 14th, 2009 at 9:07 pm
@Shawn
So you are saying that 0 code reuse is a nice think just because is more flexible?
Writing an APP w/o code reuse is fine…. if you don’t need to care about maintain it.
VELO
December 14th, 2009 at 9:19 pm
Shawn, while I agree with you that OOP is not always best approach (with skins that sounds even more to be the case), I don’t think so you get the issue from right angle. Problem with skins is that they are completely flat. Think about them as Paintbrush…yes it’s simple and straightforward. And now compare it to Photoshop. In Photoshop you have layers which allow you to manipulate background without destroying some content in front. And this “little” fact makes huge difference. Obviously it’s not as “simple” as paint but it doesn’t mean you have to layer everything. Just use it when you need. So why designer can’t create background skin and then add some another skin with controls on top and as layer he could just drag background and use it on another component. That doesn’t include any logic in skins at all. But makes huge improvement in maintainability and scalability of project. Obviously it’s not suitable for every scenario, but even for those 10% it would mean big time saving (=>resource saving=>money money=>happy client). And this scenario is generally in large scale project where maintainability is well considered. I wrote about my similar issue on my blog. Would be happy if you can advise me, how to do that without skin inheritance or layering
December 14th, 2009 at 11:03 pm
I’m not disagreeing that being able to extend skins would be “nice”, I’m arguing about the idea that this is somehow a major issue, worthy of such a sensationalist blog title/post.
It would be nice, but is it required to make good maintainable code? I would argue no.
You mention PSD as an analogy, but I would argue that skins are inherently simple objects. So I’m having trouble imagining this hypothetical use case where this is such a huge issue??
Skins are flexible enough that a single project should never have more than a couple different skins for any given component. So where’s this problem with scalability that you mention? For example a single robust skin could handle all image based buttons for an entire app. A skin can make use of custom properties, and custom styles, based on your own components, which *should* give you enough flexibility to make your skins scalable and re-usable throughout any given project.
Of course, you may reach a point where your Skin gets overly complex, and you could save some time by being able to extend it. But even then, is there really a feasible/effective way it could be done? If I need to change one specific part of a skin, I can’t imagine any remotely straightforward way to do that with inheritence. Sure, you could easily hook up new functionality,but again, your skins shouldn’t really be defining alot of functionality…so I just don’t really see the need.
December 15th, 2009 at 6:40 am
@Shawn
I don’t see the Button/LinkButton scenario as overly complex…. although you can’t reuse anything from Button to build the linkButton… same happen on IconButton….
On IconButton is even worse, or I have a skin for each different icon ( which is completely unmanageable but the original suggestion comming from some users ) or I need to create a new class that inherits button just to make some room to configure the icon…. so I will configure a skin property inside the Button just because skin doesn’t allow doing something smarter….
Skins as it is may be great for designer who don’t care about writing 10 hundred skins and won’t need to ensure similar skins behave on a similar way….
And I see this as a major issue also…. a project like flexLib won’t exists for spark…. and people who create new components will have major issues to make their components shareable… specially in non-opensource scenarios….
VELO
December 15th, 2009 at 10:40 am
I’m not sure I follow you. First of all, you do not “need” to make an additional class to configure your button, you can set styles through CSS and read them in your skin, without ever having to declare MetaTags for those styles.
That’s not really best practice, but it’s not like it’s a big deal to set up your own class.
I don’t see the big deal with creating an EnhancedButton and EnhancedButtonSkin, which can handle button’s, link buttons or icon buttons, or any other buttons your specific project needs.
If it’s getting too comple,x split it out into 2 or 3 specific skin types, still very manageable and scalable.
December 15th, 2009 at 10:44 am
As for Skins being great for designers who like to write hundreds of skins….dude there’s tons of shit in there for developers. I can hook up init functions, state change listeners, I can add sprites through AS3 and draw using the graphics API, use state-based properties, access the parent’s properties & styles… i mean it’s pretty sweet.
December 22nd, 2009 at 5:40 am
@shawn: there are quite a few scenarios: for example skins which look the same and share some similar skin parts, but then every skin gets its own skin parts as well. Not to mention custom layout issues, which can’t be just applied via styles.
You would want to use inheritence in such cases to save time, money and avoid problems. And i do think that there should be tool and language support for such cases .
December 22nd, 2009 at 3:55 pm
Well, I agree that there are some fringe cases where extending a skin would be a nice thing to do, I just don’t think it’s something that really needs to be done on any regular basis.
And even then, I still struggle to come up with any “good” way that this can be done, without imposing a whole bunch of structure into the skins that we really don’t need.
Inheritence in OOP works well, because classes have defined functions, and areas of resonsiblity, which can be overriden/modified on an individual bases. In addition, we can decide where and when to call the super() functions should we require them.
Skins have none of that, in order to effective extend, and modify skins, we would need some sort of structure in the skins themselves that identified some discrete areas which could be overriden.
In the end, you would be imposing a whole bunch of crap for developers to deal with, for a use case which may occvur <1% of the time. Doesn't seem worth it.
I supposed they could simply allow you to extend a skin, and we could use getElementAt to modify gfx, but that would be extremely fragile and prone to breakage, so I don't see any benefits coming from there. Being able to extend a skin and override it's AS functions is about the only thing I can see that would work, and is doable, and they should probably implement something that allows us to do this.
December 22nd, 2009 at 3:58 pm
Actually I guess we could use id’s to effectively target/modify a specific skin component, and this could come in handy from time to time. But I still think it’s a rare need.
December 22nd, 2009 at 4:48 pm
Maybe if skin looks like this:
It would be much more usable then it is right now….
Even better if it allow more then one skin to support the multi layer idea…
VELO
January 18th, 2010 at 12:29 am
When I start digging the Flex 4 source code, I do find ways to make skin classes reusable. A simple example I would like to point out is ButtonBarSkin.mxml. With and , most, if not all, skin re-usability problem should be solved if you plan nicely before you code. Just my 2-cents.
January 18th, 2010 at 9:32 am
@Brian, Where do you find ButtonBarSkin.mxml? Is this an Adobe exmple, or something you found on the web? I’m getting ready to kick off a Flex-4 project, so any links to appropriate skinning techniques would help me a great deal. Thanks.