TextField Document model
jonathan.giles at oracle.com
Sat Oct 20 20:30:20 PDT 2012
I'm coming into this discussion really late, but I've been sick, so
that's my excuse, and I'm sticking to it :-)
Firstly, regarding the options Richard sets out below, my strong
preference is for option a (introduce a callback). It seems that it
supports the use cases that have been raised, and it does so without
introducing concerns around having a mutable Content. I think I would
only sway from this position if there is a use case that just can't be
done with this approach (which I'm totally willing to do if someone has
Secondly, Richard mentions an important point here: one of the things
that has been on the controls team backlog for way too long is support
for a FormattedTextField control, and important subclasses thereof (e.g.
Date/Time, Money, Zip code, etc). An ideal situation would be (in my
humble opinion) for JavaFX to ship with FormattedTextField and the most
critical subclasses, and for 3rd party projects such as JFXtras / JIDE
to bring out all the rest.
This approach of shipping 'simple' controls is what we did with Button /
Hyperlink and RadioButton / ToggleButton - in many cases the difference
in code between these classes is minimal, but it allows for way better
discoverability of controls and functionality - rather than having an
uber control with miles of API to toggle state / features. This approach
works well, and it also looks great on our 'number of controls' fact
Zooming out even further, we need to expand this discussion in one very
important way: validation support. I don't have an answer for validation
yet (it is certainly not a JavaFX 8.0 feature), but we have to keep it
in the back of our minds lest we regret it later (ah, the joys of API
Finally, FormattedTextField is _not_ planned for JavaFX 8.0. However, I
would love to have someone submit a FormattedTextField control via
OpenJFX. I am more than happy to work with anyone interested in doing
so, and from my perspective this would seem to be an easy control to
develop - so it would be ideal for someone to get up to speed with
JavaFX controls development. If anyone is interested please join the
discussion and let me know.
On 20/10/2012 6:05 a.m., Richard Bair wrote:
>> I did not have time to look at the Skin and Behavior paradigms yet, so I
>> can't speak to the impact on them. I will try to brush up on those this
>> weekend. However, if this subclassing to delegate becomes relatively
>> common, then it seems that whatever Skin and Behavior issues might arise
>> would still need to be addressed. However now they would need to be
>> addressed by application designers instead of by the platform.
> In general, I'm not a fan of subclass to delegate (AWT required subclassing for all event handling. Whoops!). The question in this case however is, what are the use cases and what is the best way to expose support for those such that the API is consistent and doesn't have any odd corners or gotchas. Sometimes the only way to expose the required functionality is to create such gotchas. Other times we can do something simpler, although more constraining, that covers 95% of the usages, and then subclassing allows power users to squeeze out the extra 5%.
> So for example, I would expect people would prefer to have a SearchField, DateField, MoneyField, and TextField with a maxLength property, rather than having to use callbacks or having to configure a TextField with all the right properties. It is easier to pick a DateField from a palette and just use it than it is to setup custom Content or even using off-the-shelf Content but having to plug it into a TextField (since doing this requires a little more thought and understanding of the architecture). On the other hand, being able to plug in the content is more natural than having to subclass in order to plug in the content.
> My feeling on it has been, we ought to add (or JFXtras, or JIDE ought to add) SearchField, MoneyField, etc as Controls and we ought to give TextField a maxLength, and we ought to have a more general purpose FormattedTextField. Of course, that doesn't help address some of the other odd use cases like an all-caps field, so the question is, for such a use case, is it better to:
> a) Add some callbacks to all TextInputControl's that let you filter / modify changes to the text or
> b) Allow Content to be replaced or
> c) Restrict such features to sub classes
> Of these, my feeling was that (a) was the most useful in connection with built-in DateField, MoneyField, etc. I worry that by making Content mutable, we make it very easy for people to naively replace the Content with their own, rather than wrapping the existing Content, and thus adding bugs into their software such as what happens when you paste a \n into a TextField. That just isn't one of those things that people think about the first time around. That's why I liked (a) better, where Content was basically under the control of the Text control implementation, but developers had an easy way to insert code into the process and filter / reject / etc changes to the Content model.
More information about the openjfx-dev