FocusModel too restricted?

[Jonathan Giles]

Werner,

It sounds to me like you're trying to use FocusModel where it may not
ideally suit your needs, and rather than roll your own API that is more
applicable to your needs, you're hoping to coerce FocusModel to fit to
be consistent. Whilst I applaud your eagerness to have an API consistent
with the 'official' UI controls, my gut feeling is that this will most
probably not be the best approach. The FocusModel API was really
designed for row-based UI controls like ListView, TableView, etc, and it
may be hard to work into your property sheet component. For this reason
I would suggest rolling your own API (and possibly questioning whether a
switchable FocusModel is actually necessary for your control in the
first place, or whether you can just bake the API directly into the
property sheet).

Note that in this case the term 'focus' is overloaded, as this refers to
the internal 'fake' focus inside these controls - it has nothing to do
with 'real' JavaFX focus traversal. In other words, a ListView always
has the real focus, even if the ListView FocusModel says that row 1 is
focused - this is just for keyboard navigation purposes. For this reason
I'm curious if the FocusModel is what you actually want - I would assume
that what you are really wanting to do is move the real focus between
components in your control? Because of this you'll likely be rewriting
all of the FocusModel implementation anyway.

To somewhat answer your questions:
1) In general TreeView and TreeTableView have to jump through hoops, as
to reuse as much internal implementation code they essentially are
treated as if they are lists internally. In actual fact the focusNext /
focusPrevious methods almost weren't even added to the original API -
they were only added because I thought they were quite useful. For a
very long time we were going to be index-only.

2) When designing the FocusModel we were conscious of not providing the
same API with different names, so we settled on having a focus(int)
method and making the focusedIndex property read-only. This meant that
it was not possible for developers to accidentally bind the focus and
break the control. As always API design is a game of trade-offs, many of
which come back to bite you when you encounter new use cases in the
future :-)

At this stage it would be essentially impossible to redo the FocusModel
to remove the index-based addressing, as it would be a breaking change.
It is more possible that more methods could be made public / non-final /
not read-only, but they will need to be handled on a case-by-case basis
and the first step is to file Jira tweak requests.

I hope that helps a little...

-- Jonathan

On 2/09/2013 12:25 a.m., Werner Lehmann wrote:
> Hi,
>
> I am trying to use FocusModel in a custom property sheet component -
> it is probably a good idea to reuse as much API as possible and make
> components work similar to each other. However, the focus model makes
> this more difficult than it should be:
>
> 1. Why is it index-based? With methods like focusNext and
> focusPrevious it should not really require an ordered, index-based
> list. The TreeView focus model shows how this requires non-trivial
> extra effort if the data model is not similar to a plain list.
>
> 2. Why is setFocusedItem package private and final? With this I cannot
> even provide a new method "focus(item)" because I cannot call
> setFocusedItem internally. My users would have to translate their item
> into an index to be able to focus it. The TableViewFocusModel seems to
> have the same problem - but it is in the same package and can simply
> cheat on package private methods!
>
> To make this still work I'd have to provide index-based access to a
> tree-like data model. And to allow operations like focus(item) I'd
> have to translate the item to an index to call focus(index) instead -
> although I don't even need that index, and providing it is extra effort.
>
> Does it make sense to lift some of these restrictions?
> - no index-based requirement
> - less final/package-private methods
>
> Similar things can be said about the selection model...
>
> Werner