TextField Document model

[Richard Bair]

> 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