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.

Post to Twitter

Posted by Andrew, filed under Flex. Date: August 3, 2009, 3:56 pm | 56 Comments »

56 Responses

  1. VELO Says:

    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.


  2. Matt Says:

    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.


  3. Andrew Says:

    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.

    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.

  4. Matt Says:

    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.

  5. Andrew Says:

    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.

  6. Darren Says:

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

  7. VELO Says:

    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.


  8. Andrew Says:

    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.

  9. Brian Says:

    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?

  10. josef salyer Says:

    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.

  11. Josh McDonald Says:

    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?

  12. Pavel Says:

    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:)

  13. Shawn Says:

    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.

  14. Velo Says:


    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.


  15. Pavel Says:

    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 :)

  16. Shawn Says:

    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.

  17. Velo Says:


    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….


  18. Shawn Says:

    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.

  19. Shawn Says:

    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.

  20. Florian S. Says:

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

  21. Shawn Says:

    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.

  22. Shawn Says:

    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.

  23. Velo Says:

    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…


  24. Brian Lai Says:

    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.

  25. Andrew Westberg Says:

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

  26. Farata Systems » Using Flex 4 Skin Inheritance To Make PictureButton Component Says:

    [...] across several blogs that hint that custom Spark skins should not be created via OOP inheritance I felt challenged. [...]

  27. Merk Says:

    I think the most frustrating thing is adobe deciding not to include things like icon on the base button and just make it an optional skin part. It has been said that the goal is separation of look and functionality… For a button I would almost consider an icon to be identical to the label… Why was the label not considered part of the “look” to be moved into the skin? Most likely it would be ridiculous to expect us to reskin a button for just the label, so that was left in. For some buttons an icon is the label or at least just as important. I really hope Adobe considers putting things like this back on the class as optional skin parts. That should satisfy both sides of the camp. If a designer really wants his button looking exactly how he designed, just don’t include the icon skin part and bake the icon in… This doesn’t seem to unreasonable.

    This would help fix the skin inheritance problems to a small degree as well. Right now I have a ButtonSkin, IconButtonSkin, EmphasizedButtonSkin, and an EmphasizedIconButtonSkin… All of these I want to have the same base button look and feel, and when I update that look and feel not have to change 4 different skins to do it. An Icon property on the button and adding emphasized states to the button would really make the OO minded designer happy! This would help cut down on a ton of different skins.

    I really hope Adobe watches these situations and takes some time to help us developers out that want our apps looking good. We can’t all have dedicated designers… It’s just not realistic! Help us Obi-Wan Adobe!

  28. Shawn Says:

    Why not just have one skin, that accepts a couple different style properties?

    If hostComponent.getStyle(“iconSource”) is set, show the icon. If hostComponent.getStyle(“emphasis”) = true, show emphasis?

  29. Merk Says:


    have you tried to do what you’re suggesting? Try setting emphasized on a custom skinned spark button and watch what happens…

    There’s also a lot of times you need to dynamically change the emphasized value of a button. Why should we have to go through the extra hassle of the style api when there’s a property already on the button to handle whether or not it’s emphasized. The skin should decide what the button looks like when it’s emphasized.

    I think that’s the biggest complaint here, why add the extra complexity and code burden on the developers? There’s no clear disadvantage to adding this functionality to the base classes… Unless I’m just really missing something here ;)

  30. Shawn Says:

    Well I’m sure nothing happens, since you need to implement it yourself. But the nice thing is, once you implement it you have it exactly the way you want.

    With more power comes more responsibility.

    Flex 4 is for the first time, truly flexible. You’re skin can look exactly how you want it, and you never have to bother with being constrained by what Adobe “thinks” you should be able to do.

    No more pouring through component definitions, looking at what properties you’re “allowed” to change. You just create your own.

    So, ya there’s definately a small amount of extra effort required. But the tradeoff is complete flexibility, and no need to go in and remove a whole bunch of stuff you don’t need.

    The main disadvantage to adding to base class, would be that it breaks the seperation of roles. All visual elements should be defined in the skin, all functionality in the .as file. This is fundamental to the way Flex 4 works, and is a great improvement.

    They could’ve added the support to the Base Skin file, but there’s a drawback there as well: Performance. Spark components are designed to be as lightweight as possible, you only add what you need. This way you’re not wasting CPU cycles on functionality you’ll never use.

  31. Shawn Says:

    Also, you don’t need to use the style API, that would just be the quick and dirty way of doing it.

    In <1minute you could create a new class which extends button, and add a emphasized property.

    You could then use this button throughout your project, and all future projects, with any number of skins attached to it (some may look COMPLETELY different than other, but they all share the same functionality), any of these skins can choose how they look when emphasized, and can target the property by saying 'hostComponent.emphasized'

  32. Velo Says:

    “small amount of extra effort”

    Funny choice of word… duplicating every code that doesn’t match your needs doesn’t sound a small effort to me… specially if I had to maintain that code.

  33. Velo Says:


    “So, copy-and-paste is not necessarily bad in the short run, if you are copying good code. But it is always bad in the long run. “

  34. Shawn Says:

    “duplicating every code that doesn’t match your needs doesn’t sound a small effort to me…”

    What are you even talking about?

    I suggest you get your hands dirty, and start making some real apps with Flex 4, then come back actually have an idea what you’re talking about…

  35. Shawn Says:

    Not to mention, how many HOURS have you wasted battling flex components to move things by 1px, or shoehorn in functionality that doesn’t exist? How many hours have you spent pouring over documentation, for each specific component’s visual properties?

    Consider that, by and large, you’ll never have to do this again. Once you learn basic SVG techniques, they will apply to all skins and all components.

  36. Velo Says:

    The old IconButton problem…. You need to DUPLICATE the skin…. or did someone fixed that and made skin reusable?


  37. Shawn Says:

    Skins are not classes. They do not have discrete functions and properties, therefor inheritence would be much messier than it is with Classes.

    If you’re going to complain, offer a solution… how would YOU construct a skin so it’s actually extendable?

    I’ve given it some though, and the only ways I can see are pretty ugly…

  38. Merk Says:

    The spark button already has an emphasized property on it, that’s what I meant by give it a shot :) It reskins the button completely when that property is set to true. I have found a work around by overriding the s|Button.emphasized style and setting the skin to EmphasizedButtonSkin, but it just doesn’t feel like it fits in with the new skinning model. I honestly expected an emphasized state on the skin… I would love to have a nice smooth AnimateColor transition between emphasized and non-emphasized states, right now that’s not possible. On the flip side I would hate to see a ton of state bloat to support this, maybe Adobe will come up with something that would allow more flexibility in communication between skin and component.

    Like I stated before, what’s the different between a label and an icon? They’re both the same purpose, and both related to the “visual” side of the component. An icon is really nothing more than a graphical representation of the label in 90% of cases. It’s obvious things like this are frustrating developers. A quick Google search on spark icon button will give an idea of how much trouble people are having. Honestly it’s little things like this that can have enough impact on whether or not developers look at other platforms. I mean try telling your boss when he wants an icon on a button that will be a couple of hours of work because the platform doesn’t natively support that. It’s a little like ‘huh’… really? The little things kill…

    I guess it just feels like Flex has this great move towards skinning and complete control over look and feel, but it sucks to have to go the extra mile to get something that was so easily accomplishable in Flex 3, and quite honestly is a UX standard. I can’t argue too much with the goal of a lightweight, performant controls though, that’s something we’ve been asking for as well. Like the original post states though, if something like this is being asked for by 95% of the community and it ends up having 100 different implementations, that’s just bad for the platform overall. I’m just hoping Adobe is listening…

  39. Merk Says:

    “The old IconButton problem…. You need to DUPLICATE the skin…. or did someone fixed that and made skin reusable?



    The only easy way I’ve found to do this so far is a extending the spark button and build a new optional icon skin part. This will allow you to change icons without creating new skins. You just have to use the new component.

    import spark.components.Button;
    import spark.primitives.BitmapImage;

    public class IconButton extends Button {

    public function IconButton() {

    private var _icon:Class;

    public function get icon():Class {
    return _icon;

    public function set icon(val:Class) : void {
    _icon = val;

    if (iconElement != null)
    iconElement.source = _icon;

    public var iconElement:BitmapImage;

    override protected function partAdded(partName:String, instance:Object) : void {
    super.partAdded(partName, instance);

    if (icon != null && instance == iconElement)
    iconElement.source = icon;


  40. Merk Says:

    Not to mention, how many HOURS have you wasted battling flex components to move things by 1px, or shoehorn in functionality that doesn’t exist? How many hours have you spent pouring over documentation, for each specific component’s visual properties?

    Consider that, by and large, you’ll never have to do this again. Once you learn basic SVG techniques, they will apply to all skins and all components.”

    I’ll agree 100% here. What used to take me a good week to skin an app can now be done in much less than half the time, with much much better results. I just don’t want to see my time shifted from complex things becoming easier to easy things becoming complex… There needs to be a good balance between the two and I think that will evolve over time as people keep yelling “where the hell is my icon!” ;)

  41. Velo Says:

    this photoshop layer that someone said earlier here seems a good start.

    If I could create an skin class like this:
    <s:ButtonSkin ….

    That does recall me a bit on 2.x and 3.x states

    Would be also nice if the skins could be pass as object….

    instead of:

    do this:

  42. Velo Says:


    Yeah, that is the “best” way right now

    But then I need a button with 2 icons, with 3, w/o background….

    And buttons are as simple as labels… imagine more complex components like datagrids or trees…

  43. Merk Says:

    “But then I need a button with 2 icons, with 3, w/o background….”

    In all fairness, I do believe this situation is easier to do in Flex 4 than Flex 3… Trying to get a button to display 2 or 3 icons in Flex 3… ugh.

  44. Velo Says:

    That is something I agree….

    Is much easier to do… but you end with code duplication. Then you have to fix something on a button… the problem is you have 10 more clones around there, which you have no idea existed, and you obvious didn’t touch any of this extra class… then QA go check what you did and you fixed only one place, but kept it broken all over….

    Was a pain to put a close button on TabNavigator, but once it was there I knew I only have to check it. Not a bunch of classes…

    Obviously Flex 4 is much better on the designer perspective which obviously I’m not.


  45. Shawn Says:

    I have no idea how the old Flex was better for developers.

    So, no control at all, and 80% private function/properties which can’t be overridden… is somehow preferable to a system which gives you complete flexibility and control?

    To me it’s not even close, the benefits faroutweigh the negatives.

  46. Shawn Says:

    I don’t really understand the big issue with “code duplication”.

    Unless you’re referring to duplication between projects??

    Skins are flexible/powerful enough (with the ability to read properties and styles from the hostComponent), that you should never need to create more than a couple similar types in any given project…

  47. Merk Says:

    “To me it’s not even close, the benefits faroutweigh the negatives.”

    I completely agree, we’re all just voicing some of the concern we see from a development perspective. From a design perspective things are 100x better. I don’t think anyone here will deny this framework is much more robust for control and design. I also don’t think anyone here is saying that Flex 3 is better, just having a hard time understanding the new component model. There are things that will most likely shake out as more of the community starts embracing the new model and finding its strengths and weaknesses. If we don’t voice it though, there’s nothing Adobe can do to help us.

    Almost feels like the jump from 1.0 to 2.0. There was challenge, but much more benefit. Learning from frameworks like degrafa and competition from silverlight are moving the Flash platform in the right direction for sure…

    note on your code duplication… I’m not sure from your conversations whether your more design oriented or development oriented, but OOP design lives and breathes getting rid of code duplication with inheritance and composition… It’s one of the top goals of OOP design. Code duplication leads to buggy & inconsistent spaghetti code. The design world doesn’t really concern themselves too much with duplication of art. It’s just a different way of thinking. I imagine it’s as hard to ask a designer to componentize art as it is to ask an OOP programmer to copy and paste (technical challenges aside)… Both would say “huh, why the hell would I do that…?” For skins this really isn’t a huge problem, since there’s nothing that can really break in a skin, but for developer efficiency, especially shops where the design and developer are one, efficiency is key to meeting business goals and Adobe should be doing everything it can to make sure that doesn’t suffer.

  48. Shawn Says:

    I’m a develop, not a designer, and I’ve been using OOP for nearly 10 years. And I support inheritence as a general concept with skins.

    What I’m saying though, is this issue is really a red herring.

    Code duplication should not be an issue within a single project, as long as you architect your skins in a smart way.

    Across projects, there could be a ton of code duplication, but inheritence would not help you here anyways…unless you’re working off of one conslidated global classpath, which in my shop is a major nono, each project needs it’s codebase to be standalone and portable.

    So again, please give me a use case. I would love to hear an explanation of why you would ever need “10 buttonSkins” as Velo infers…

  49. Shawn Says:

    Also, I would argue the old flex was better for non-developers, as everything was premade, and you could just set some styles, some properties, and voila you have a custom component.

    In Flex4, it actually requires a developer to add the functionality in.

    I don’t think it’s better for ‘designers’ at all, it’s better for ‘designs’ though, because it’s about 100% more flexible…

  50. creacog » Blog Archive » my first Flex 4 spark : component + skin = ResizeableTitleWindow Says:

    [...] Flex 4 skinning ignores developer needs [...]

  51. Shoyo Says:

    Adobe Fail again…

    I was a huge Flex fan on Flex 3.
    Expected a lot on 4, but adobe only disappoints…

    Flex 3 was so simple to skin. Really HTML like, using fireworks, images, css, piece of cake.
    It was friendly….
    Now the spark “innovation” is unnecessarily complex.

    Skinning is another Flex 4 fail.
    Why haven’t they kept the MX way of skinning for Spark and add whatever the complex stuff they like??

  52. Tracy Says:

    Hi there

    For a designer-developer workflow for skinning spark (and custom) components I’m thinking of the following. Any comments thoughts on whether this is a good / bad approach very welcome!!

    - create custom skin-classes that dynamically references a skin resource via the getStyle() property

    To do this:
    1. Identify the core spark components to be skinned. There shouldn’t be that many – Button, Scrollbars, ComboBoxes …
    2. Get one of the theme samples in the Flash Builder application folder (eg. Arcade). Use these to base your spark skins on.
    3. Copy the skin file (Button for example) … and change the reference of hardcoded embedded assets to a style declaration, eg. getStyle(“upSkin”)

    I haven’t gone through this process yet, but I imagine I would have a .css file that maps the spark (and other custom) components to the skin-classes and a 2nd .css (for sanity a separate file) that contains the dynamic skins (supporting the skinning workflow from Flex 3)

    What does everyone think? Can anyone see any potential problems with this method?


  53. Tracy Says:

    Also, I’m trying to find out which skin assets are the most optimal – i.e are smaller and take less processing to be drawn on the screen.

    From much reading I have concluded there are the following skin-asset options:
    1. MXML graphics (hand-coded FXG in Flash Builder)
    - good if you only have a text editor to create graphics
    - vector graphics, so scale optimally
    - large & verbose, so not as optimal
    2. FXG graphic elements exported from a graphics editing program (eg. Photoshop)
    - vector graphics, scale optimally, better performance over (1.)
    3. Embedded .swf / .png … assets

    Here is my post on the Adobe discussion forum. Still no reply from them, but I would love to get a discussion going around this & the skinning workflow to find out more about the trade-offs, limitations and best practices.


  54. David Coleman Says:

    You can do it!

    You have to use CSS:

    windows|TEPWindow {
        skin-class: ClassReference("com.{redacted for privacy}.presentation.components.controls.windows.TEPWindowSkin");
  55. nose job looks Says:

    Surgeons ask the patient to stop smoking cigarettes several weeks before the face lift surgery.
    The rhinoplasty surgeons India enhance the nose by reshaping it by using components like cuboids, gristle (fibrous) and a couple
    of fashioned elements as well. It is normal to have slight bruising
    and swelling for about ten days.

    Feel free to visit my web-site nose job looks

  56. wet camping Says:

    Have you ever thought about creatin an e-book or guest authoring on ther blogs?
    I have a blog based on the saame topics you discuss aand would
    really like to have you share some stories/information. I
    know my visitors would vlue your work. If you are even remotely interested,
    feel free to shoot me an e mail.

Leave a Comment

Your comment

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.