TextField Document model (original) (raw)

Mark Claassen markclaassenx at gmail.com
Mon Oct 22 10:22:03 PDT 2012

I'll try to provide some examples, but, in general I think my main thing is not to box in the developer more than necessary. I don't appreciate tools that don't allow me to complete a task because they think they are smarter than me. (Which, maybe they are...but in the end I need to accomplish my goals with the tools help or not.)

Even though I was pushing for the mutable content, I am leaning toward the ContentFilter approach now. If the passing of the control as a parameter is acceptable, then I think it makes a nice encapsulation; where an implementer can, in one class, deal with the data model and cursor position without needing to subclass anything. Hopefully this does not conflict with the Control / Behavior / Skin concepts.

On Mon, Oct 22, 2012 at 11:50 AM, Richard Bair <richard.bair at oracle.com>wrote:

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

+1 to the above. I'm not opposed to having mutable content, but if the use cases are easier for people by a combination of callback / specific property additions / new controls, then I think that would be my preference. But having TextField have mutable content, rather than TextInputControl, is also an interesting twist on the idea and would perhaps be another option to weigh. Richard

More information about the openjfx-dev mailing list