calendar picker chaining

[Jonathan Giles]

> Naturally that is a possibility; after all for the calendar picker a 
> single month is a specialized case of multi month. Basically this 
> means that any parameters for a skin are passed via CSS. Now this 
> FLOATING example is a boolean, true or false, present or missing. In 
> case of the picker I'd like numbers (or at least strings); number of 
> months to show, dimensions of the layout. That cannot be done this way 
> in a some what acceptable fashion: STYLE_CLASS_NUMBER_OF_MONTHS_IS_1, 
> STYLE_CLASS_NUMBER_OF_MONTHS_IS_2, STYLE_CLASS_NUMBER_OF_MONTHS_IS_3, 
> ... is not considered acceptable. So this would require either abuse 
> of existing CSS variables or the private API that will break eventually.
Yes, in your use case style classes are not the best approach. In my 
opinion your kind of requirement is best handled as API in the control 
for now, until we have official API to expose CSS properties (and even 
then, having the API on the control is useful). In other words, I would 
probably go down the path of having methods on your control for setting 
the number of months to show, etc. This can then be observed by the skin 
and update the view appropriately.

>
> Secondly I'm reading that this moves layout information into the CSS, 
> and that seems incorrect. CSS is for style, but actual screen layout 
> is part of FXML or Java code. Correct?
Correct, although this does not move layout information into the CSS, it 
simply moves the specification of which layout (and of course which 
styling) to use into CSS. It is best, in terms of controls layout 
itself, to use Java code to specify the layout.

>
> Third I'm reading the usage of one single skin implementation. The 
> calendar picker control itself is totally skin agnostic; it does not 
> even know what month is displayed, it only knows the last selected 
> calendar and the total list of selected calendars. Now, if I'd go 
> crazy I could create a picker based on, say, rotating drums. One drum 
> for day, one for month, one for year. The control's API does not 
> change; last selected calendar and all selected calendars (the last 
> will be a challenge with a drums skin). So this drums skin is so 
> fundamentally different from the button one that I would not dare to 
> force that in a single implementation class and have it change its 
> behavior. So either I setSkin on control, or set the skin some way in 
> the CSS, or use a proxy skin that redirects to the appropriate 
> implementation. What would be considered the best bet?

 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!
-- Jonathan