On Wed, Jan 8, 2014 at 10:56 PM, John Hendrikx <hj...@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 >> 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. > 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(); > 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 >
