TextField Document model

Richard Bair richard.bair at oracle.com
Fri Oct 26 08:10:52 PDT 2012

> 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"?


More information about the openjfx-dev mailing list