TextField Document model

[steve.x.northover at oracle.com]

Another idea is to have a TextField that validates using a RegEx.  I 
expect that this would augment (not replace) the need for specific 
Date/Time validation classes etc.

Steve

On 20/10/2012 11:30 PM, Jonathan Giles wrote:
> 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
>