TextField Document model

[Scott Palmer]

On 2012-10-26, at 11:10 AM, Richard Bair <richard.bair at oracle.com> wrote:

> 
>> Suggestion 2: (possibility)
>> public interface ContentFilter
>>   public void onDelete(Content content, TextInputControl control, int
>> start, int end, boolean notifyListeners) {
>>     ....
>>   }
>>   public void onInsert(Content content, TextInputControl control, int
>> index, String s, boolean notifyListeners) {
>>     ....
>>   }
>> }
>> 
>> I added the TextInputControl to the list of parameters so that cursor
>> manipulation could be done.  The above specification would also require the
>> user to call content.delete() and content.insert() for anything to be
>> changed.  I thought about using boolean return values to signify whether or
>> not the input was already handled or not, but that would just force a user
>> to know how to used the booleans.  This seemed nicer to me.
>> 
>> This would allow I lot of power.
>> * It has the safety of calling the insert and delete models on the rigorous
>> implementation of Content
>> * Allows the content to be replaced (if appropriate) at each event.
>> * Allows for the Content variable to be final
> 
> This is starting to feel right to me. However, instead of using a 2-method interface (or abstract class), if we break it into two interfaces, then it becomes lambda friendly. Although there is a distinct disadvantage to breaking it up. Having the two methods together means you could have a library of pre built filters, for handling a range of things.

You could make an interface that implements both of the single method interfaces. I'm not sure if that helps any as it might not work well for the lambda stuff.

> And interface or abstract class? Typically we always reach for an abstract class in cases like this because we can extend the class in the future. Now that Java 8 is introducing default methods, we do have another way to extend the API in the future. I am reluctant to rely on it yet though because it is an unproven tool for API design (ie: I don't know the gotchas yet).
> 
> So suppose we make this thing an abstract class with two methods (for now?) for handling both the delete & add cases. I would modify the implementation though, so that the add case returns the string to insert at the given location (null meaning to reject), and delete returning true / false? By default. The onInsert would return the input string, and onDelete would return true (so you could implement only one of the methods of you wanted to).
> 
> My reasoning for this is that it makes the implementation and semantics simple. Any time the implementation would mutate the content it first checks the filter and then either stops modification or continues (in the case of insert, with the new string).

I think in the case of Delete it is important to allow for modification of what us to be deleted.  What if the selected range contains a part that is not allowed to be deleted in your customized control? Imagine a field for a (North American) phone number that you wanted to always show as (###) ###-####. When selecting parts and hitting delete you don't want the delimiters to be deleted, just the digits.  It may not be the best example, but allowing the range to be modified or even split into multiple ranges would be far more powerful.  Just return an empty set of ranges and nothing gets deleted... It is more similar to how you propose the Insert filter to work... Actually it brings up the same issue for insert.  If I paste a few characters I may actually want to force an overwrite of some of the text that is already there. Such that if I paste 1234567890 into my phone number example the field ends up with (123) 456-7890. Just having Index and String parameters is not enough if we want some of the current text to be replaced.



Accounting for caret position and skipping fixed characters in the text can already be done fairly easily with what we have, so I'm not worried about that.  I want to keep it simple, without making certain things impossible.

Scott