calendar picker chaining

[Tom Eugelink]

On 2012-08-11 23:42, Jonathan Giles wrote:
>
>>
>> How would this be done? I am not supposed use the setSkin method, so does specifying that a certain control on a certain screen uses the multimonth skin belong in the CSS? And the configuration of the skin; how many months, grid layout (2x2, 3x1), also in the CSS? How would I access this information in the skin itself?
>
> Unfortunately the images never arrived, so I'm not entirely clear on what you are showing. I'm also not totally clear on your question. However, here is an answer to a question, hopefully somewhat related to yours.

http://home.tbee.org/stuff/chain.png


>
> What we do in the JavaFX UI controls team is have one control with potentially multiple visuals represented as different style classes. You can see this with the TabPane, it has a public static final STYLE_CLASS_FLOATING string, which users may use to modify the styling, as such:
>
> TabPane tabPane = new TabPane();
> tabPane.getStyleClass().add(TabPane.STYLE_CLASS_FLOATING);

If I'm reading a lot between the lines here (and there are only two). First I read that you have one skin which behavior is adapting depending on the CSS. 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.

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?

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?


>
>  It would definitely pay to check out OpenJFX and look at the code for TabPane, ColorPicker and Pagination.

Will do, however it speeds things up if I knew what I was looking for. Hence this little discussion.

Tom