TextField Document model

Richard Bair richard.bair at oracle.com
Tue Dec 4 08:23:45 PST 2012

Hi Mark,

Sorry for being slow -- you will at least be glad to know you are in such auspicious company as Jonathan Giles, who has to regularly bribe (or threaten) me to get timely responses :-)

On first read, this seems very nice. The Filter interface is a single-abstract-method interface, so it will play perfectly well with Lambda's. It can be reused among multiple controls and types of text input controls which seems ideal. It seems to plug into the pipeline quite naturally.

One question is, should the filter start off as null and have an additional filter (newlines and such) always applied, or should it start out as non-null where the built in filter handles newlines (and such) and new filters also will have to either wrap the existing filter or add support for newlines (and such!) or not as necessary? The safest thing for an implementor would be to delegate in case we change the built-in behavior.

The next step would be to create a diff and attach it to the JIRA issue (and make sure you have signed the Oracle Contributor Agreement (OCA)). I think we can then integrate the patch and start the discussion around formatted text field. Jonathan, what do you think? Have you had a chance to review?


On Nov 26, 2012, at 7:44 PM, Mark Claassen <markclaassenx at gmail.com> wrote:

> I sent a potential API change to Richard Bair a few weeks ago.  He has not
> responded to me, which makes me think it was too complicated at this point
> and wasn't going to fly.  I think for a good InputMaskField, the Content
> and the eventual caret position and selection needs to be controlled by the
> "model".  This makes the solution a bit complex.
> However, for filtering, this is not the case.  Doing both of these in one
> shot is, perhaps, a mistake.  Here is another idea which takes care of the
> easy cases...easily.  A more complex InputMask control I will save for
> later.
> So, here is the simplified idea:  Add the ability to "filter".  And by
> filter, I mean the ability to modify the input and only the input:
> Add the following sub-interface to the Content interface.  No methods are
> added to the Content interface.
>    interface Filter {
>         String filter(int index, String text, String currentContent);
>    }
> Add the following to TextFieldContent and TextAreaContent:
>    private Content.Filter filter;
>    public void setContentFilter(Content.Filter filter) {
>         this.filter = filter;
>    }
> Change the "insert" method of TextFieldContent and TextAreaContent to start
> with:
>    @Override public void insert(int index, String text, boolean
> notifyListeners) {
>         text = TextInputControl.filterInput(text, [boolean], [boolean]);
>         if (filter != null)
>              text = filter.filter(index, text, get());
> Add a method in TextField:
>    public void setContentFilter(Content.Filter filter) {
>         ((TextFieldContent)getContent()).setContentFilter(filter);
>    }
> Add a method in TextArea:
>    public void setContentFilter(Content.Filter filter) {
>         ((TextAreaContent)getContent()).setContentFilter(filter);
>    }
> This would do a few things:
> 1) Use the current "TextInputControl.filterInput" mechanisms of TextField
> and TextArea (like to strip out special chars and newlines).
> 2) By specifying the Filter interface outside of TextField and TextArea, it
> allows the same filter to be used for TextField and TextArea
> 3) Makes it simple to do things like translate all input to upper case or
> limit the overall length
> 4) By not adding a method to Content directly, something like the
> InputMaskContent would not be forced to deal with the Filter interface at
> all.
> This implementation would allow someone creating a filter to "filter" the
> text to have illegal characters.  I thought it was more validate this
> first, so that the implementer would only have to deal with proper input.
> However, TextInputControl.filterInput could be done both before and after
> the Filter.filter() call.
>         text = TextInputControl.filterInput(text, [boolean], [boolean]);
>         if (filter != null) {
>              text = filter.filter(index, text, get());
>              text = TextInputControl.filterInput(text, [boolean],
> [boolean]);
>         }
> Another possible addition to this may be to allow the filter to return
> null, signifying an error input and causing the system to "beep".
> Thanks for your consideration,
> Mark

More information about the openjfx-dev mailing list