Teoti Graphix, LLC

Ok,

After doing some more research, it is apparent there is a split in this new approach to skinning in Flex 4 Spark.

• Companies have designers that use tools to create a full MXML (flat) tree that implements a Component’s skin part API.
• Companies have designers give assets such as images and behaviors to developers, developers touch the code, not designers.

With this split it is easy to see why some devs like the Spark skinning implementation and others are having a hard time with the copy and paste.

I am in no way saying the copy and paste is wrong, against OOP or whatever other reason. I’m saying that this new skin implementation depends on tools. I guess this is the changing of tides and more editing programs getting into the mix.

Alternatives

This one I have been racking my brain on for a while; Anything a component developer that sells encapsulated pieces of behavior(components) creates, the component needs to work in a design view tool. Else we are marketing our components to a seemingly diminishing breed of company, the developer controls the code company. Another example of this is someone tweaking the MXML in a code editor.

What this means is, the alternatives shrink in value due to the fact anything that I could come up with is dynamic, which means it is not “flat” like an MXML skin, thus a designer has no access to.

Matt Chotin put it frankly in a blog comment; Halo failed because designers could not tweak the skins (ProgrammaticSkin) in the design view of a tool.

What does this mean?

Essentially, a component developer cannot create a BorderSkin that is a subclass of a Group (implementing a subset of border and background styles) that can then be reused in an actual Skin subclass. If you define styles that could be plugged into the composite BorderSkin, a tool like catalyst cannot read and display the composite border correctly. Plus with Flash Builder’s design view, forget it.

To make matters worse, how would you allow the designer to “apply” the styles you defined for the composite BorderSkin in their implementation of the parent Skin class?

Conclusion of Take 1

For me, it’s easy to create tight component API’s that allow a greater abstraction of widgets application developers use in their code everyday. We have had hundreds of happy customers with our past Flex2/3 line of components.

The new challenge for my company is realizing the need of the current motivations.

It’s hard for a component developer that sees abstractions in a component such as the spark.components.Panel to take it, slice and dice it to more of a composite approach (titlebar, content, statusbar). Make available a TitleBar and StatusBar component, when the Panel exemplifies what Adobe wants designers to get their hands on, one big chunk of view code in a tree, in the same file.

It’s easy to take and build sub components, skin them and make them work. The problem I am finding is how to I get the TitleContainer that holds these sub components to play nice with design tools.

Mike

Comments are appreciated.