TextField Document model (original) (raw)

steve.x.northover at oracle.com steve.x.northover at oracle.com
Mon Oct 22 06:21:07 PDT 2012

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

More information about the openjfx-dev mailing list