TextField Document model

[Richard Bair]

Hi Mark,

I'm wondering if you had a chance to try this out?

Cheers
Richard

On Oct 26, 2012, at 10:28 PM, Mark Claassen <markclaassenx at gmail.com> wrote:

> Thanks.  I plan to work on it this weekend.  We will see what happens!
> On Oct 26, 2012 10:51 PM, "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.
>> 
>> 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 need to look at the implementation, but I think the places where we
>> modify the text (and would insert checks to the filter) are also the places
>> we move the caret / selection, so they could take into account the filtered
>> text.
>> 
>> What is the purpose of "notifyListeners"?
>> 
>> Richard