calendar picker chaining

[Tom Eugelink]

On 2012-08-12 09:46, Jonathan Giles wrote:
>
>
> From my point of view, it is most probably best to ship multiple controls in this situation. Each control would have it's own default style class, and therefore would be able to have a different skin specified in CSS via the -fx-skin property (as well as alternate styling). It is probable that each of the controls, in the simplest case, may be nothing more than a subclass of your core calendar class with a new style class applied. However, it may be that some of these subclasses deserve new API, so this approach makes it trivial to add it. Similarly, the same approach could be taken on the skin side of the house - have a core calendar skin which is subclassed by the appropriate calendars where new functionality needs to be supported.
>
> In general, my preference is to have a lot more simpler UI controls than to have a swiss-army knife control.
>
> Again, I hope that helps!
>

It does. I have not though about that approach. Interesting. It strongly downgrades the role of the skin class... and the whole control / skin / behavior concept as I saw it. It certainly explains a lot of choices made. Going to let this sink in a bit. This does make me very curious how you guys will be doing the touch controls icm write once run anywhere, since (as my little calendar picker example describes) their UI may be very different from a mouse based one.

Thanks!

Tom