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
