I've filed https://javafx-jira.kenai.com/browse/RT-30881 and hoping to get this
resolved for 8.
Richard
On Dec 4, 2012, at 8:23 AM, Richard Bair <richard.b...@oracle.com> wrote:
> 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?
>
> Thanks
> Richard
>
> On Nov 26, 2012, at 7:44 PM, Mark Claassen <markclaass...@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
>
