Future of Skins

[John Hendrikx]

On 7/01/2014 18:11, Tomas Mikula wrote:
> With a non-reusable skin, dispose is pretty much just removing the 
> listeners. With a reusable instance, I suspect there is more work to 
> reset the state of the instance (e.g. removing children, or, if you 
> were concerned about performance, returning them to a pool of 
> objects). So I would argue fresh instances are never more complicated 
> than reusable ones, while the opposite is true only in simple cases.
Well fair enough.  Making them fully reusable is more involved anyway 
(as in settable on multiple controls).
>
>     Anyway, for me, making Skins reusable makes them easier to use
>     with bindings,
>
>
>  My understanding of skins is that they are the view of the MVC 
> pattern and that the rest of the application should not depend on the 
> particular implementation.
I'm not sure what you mean by this.

Skins that radically change the appearance of a Control may have new CSS 
properties to control that appearance (and standard JavaFX Skins do 
introduce CSS properties that are not available on the control itself).  
Big changes, like a Tree that is displayed in standard filesystem style 
and change it into a graph with linked nodes (perhaps 3D) that can be 
navigated in a similar fashion -- without having to switch to a 
completely different control (after all, the code does not care, it's 
still a tree).  It's possible -- and that's what I'm doing.

I just found it akward to provide users with controls to change the Skin 
(of one control) on demand.  Something like a SkinFactory would be 
required as Skins themselves cannot be precreated and re-used as 
needed.  If it were only a matter of changing the skins, I could also 
just change the CSS skin property's class name, but some of these Skins 
can be configured extensively which would need to be handled in either a 
Factory or by creating yet another Skin with these configurations preset.

Consider the graph case for a tree strucuture... there are many possible 
visualizations, 2D, 3D, visible node levels, fade in/out rules for 
nodes, scaling, etcetera.  Just one Skin offers all of these as 
Properties, and I'd like to provide say 5 or 6 "defaults" from which the 
user can choose.  Factories would be my only option at the moment.

As the underlying control needs no changes, I think Skins are ideal here.

>     and it ofcourse saves creating a factory.  I see the "skin" of an
>     object as the same as say its background color.  There is no
>     reason (anymore I think) that one should be treated so differently
>     from the other.
>
>
> One outstanding difference is that a skin is stateful, while a 
> background color is stateless (immutable). Thus you can use the same 
> instance of background color for many controls, but you cannot do that 
> with skin instances. In this respect, a skin provider is a better 
> analogy to background color (you can use the same skin provider with 
> many controls).
This is true, a SkinProvider would atleast not carry State, and it would 
blend in a lot better with almost all other properties.
> Furthermore, neither the current state nor your proposal prevents you 
> from doing this:
>
> Skin<MyControl> skin = new MySkin();
> myControl1.setSkin(skin);
> myControl2.setSkin(skin);
>
> My proposal does not allow you to write such code.
Well, your proposal would make the above code work, if all of those are 
SkinProviders, and even do exactly what you'd expect :)

--John