TextField Document model

[Mark Claassen]

> Add some callbacks to all TextInputControl's that let you filter / modify
changes

I agree with lots of what you said.  However, the callback stuff scares me
a bit.  With the current implementation of only filters, things like the
date field will not be done be most developers (if the alternative is to
write their own control).  To ensure the necessary flexibility, one needs
to almost re-invent the Content interface, but have it called something
else.

It seems that your main concern with my previous suggestion was giving a
developer too much of an opportunity to shoot themselves in the foot.  And
I agree that if someone doesn't extend from a well created implementation,
this is bound to happen.

Would you consider having a setContent(TextFieldDocument doc) method in
TextField?  The length() method and the get(int, int) method could be
final, making it necessary to call super.insert() or super.delete() to get
anything done.  This would provide the flexibility (likely all the
flexibility) and yet would prevent a developer from making a fairly large
set of mistakes.

Mark

On Fri, Oct 19, 2012 at 1:05 PM, Richard Bair <richard.bair at oracle.com>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