Sounds like this may be a case of "where view details become essential to the operation of the control, then define the Control to always include those specific view details.”
> On Mar 23, 2015, at 11:45 AM, Robert Krüger <krue...@lesspain.de> wrote: > > > > On Mon, Mar 23, 2015 at 7:07 PM, Richard Bair <richard.b...@oracle.com > <mailto:richard.b...@oracle.com>> wrote: > tl;dr; I lean toward keeping the Control API as view-agnostic as possible, > but where view details become essential to the operation of the control, then > define the Control to always include those specific view details. > > ============================================================================ > > Very interesting discussion, I’m enjoying reading through it. The following > is a bit of background as to where my head was when we were designing this. > > In Swing we had a similar concept to the Skins, they were the various UI > delegates. In theory they allowed you to change the look of a Swing component > (and they did) — but there were all kinds of “view specific” details that > leaked into it, and also in the Swing components. With JavaFX, I wanted to go > down more of a purist route, where the Skin would literally do all the UI > (view) and the control would be the controller. OK, the Control was a Node > because it made more sense conceptually to put a Button into a scene graph > than to create a Button, associate it with a view, put the View into the > scene graph, and somewhere stash the controller so you could get it back > later. And for something like a Button, it works well. > > Almost as soon as we’d gone down this road we got into the various problems > you guys have been discussion around scroll bars and view positions. If > you’re using the standard UI, then you kind of want to have access to these > properties so you can get the UX right. However if we add these properties to > ListView, then it would go down the road of saying “ListView displays a list > of items and has a scroll bar or at least a scroll position and you have > convenience API for making certain items visible, etc”. > > Another very common complaint was about how to go about knowing the size of a > cell for a specific list view item. You’d really want an API on ListView that > said “getCell(item)” and then you got the cell, at least assuming it was > visible, otherwise since it is virtualized it doesn’t make a whole lot of > sense. But anyway, if you don’t know whether the skin even does > virtualization, then how can you define these semantics in a way that is > broadly consistent and usable? > > Basically it comes down to having the API on the controller (Control) and > restricting what kinds of skins can be created per control or having users > cast the skin to a concrete type and work with the Skin directly for such > things. If we were a dynamic language we could be dirty and munge the two > together into a single thing (dynamic properties), but with its own set of > trade-offs (you have to know what kind of skin you’re dealing with, and if > you get it wrong, your app breaks). > > As time went on we ended up adding more view-specific functionality to the > controls (even adding view state via the CSS background API etc!!). I don’t > know what the right answer is for this design question, but where we were > heading was a place where you would have different UI controls for different > “classes” of controls. So a ListView with scrollbars is our ListView, and a > PagingListView or something would probably be different. They could have a > common base class if we designed it such, otherwise they would just have > those similarities that are consistent between the two classes of control. > > That is why I find this actually quite appropriate: > > > So Skins prevent us from getting visual details of the Control (such > > as scroll position, position of item on screen, ...), because it is > > Skin-specific, but at the same time they fail to customize the look & > > feel, because visual presentation leaks into the Control anyway. > > > This is the design balance! If you get it wrong, you get exactly what you’re > saying here. > > In the end, I lean toward keeping the Control API as view-agnostic as > possible, but where view details become essential to the operation of the > control, then define the Control to always include those specific view > details. > > > Not understanding the discussion in-depth, I just hope that solving issues > like https://javafx-jira.kenai.com/browse/RT-39917 > <https://javafx-jira.kenai.com/browse/RT-39917> is possible within the > current design. If such limitations are something one has to live with, it is > not possible to create a UX that can compete with other toolkits including > Swing. At the moment this is a brick wall we seem to be hitting porting our > product from Swing to JFX.
