Future of Skins
tomas.mikula at gmail.com
Wed Jan 8 15:16:38 PST 2014
On Wed, Jan 8, 2014 at 10:56 PM, John Hendrikx <hjohn at xs4all.nl> wrote:
> 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
> 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
> 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.
Sorry, I misunderstood what you meant by "use with bindings". Yes, I guess
factories are your only option, but again, it shouldn't be too much
boilerplate with lambdas.
>> 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 :)
More information about the openjfx-dev