calendar picker chaining
jonathan.giles at oracle.com
Sun Aug 12 00:46:41 PDT 2012
> 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!
More information about the openjfx-dev