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();

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


Reply via email to