TextField Document model

[Mark Claassen]

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