[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    TextField Document model
From:       markclaassenx () gmail ! com (Mark Claassen)
Date:       2012-10-27 5:28:54
Message-ID: CA+8PQmEkueYtB1FrksYDFjbBpe5dG7fx2mgP2hje-L2Xzu0+Uw () mail ! gmail ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]