TextField Document model

[Jonathan Giles]

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 
one).

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 
sheet :-)

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 
development!).

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.

Thanks,
-- Jonathan

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.
>
> Richard