TextField Document model

[Scott Palmer]

I think you are correct.  I don' t know enough about the builders used
during FXML loading.  Some classes have an initBlah(x) instead of a
setBlah(x) when the value can't be changed.  I doubt that can be made to
work for something like this without breaking TextField. For now,
subclassing instead of setContent is probably the path of least resistance.
 But I'm in agreement that something better is preferred.  It's just that
there are a lot of bigger problems with JavaFX... so I'm not sure where
re-working TextFieldSkin interactions sits.  I would like to be able to
augment or replace the context menu on a TextField for example, or be able
to get the on-screen position of the caret so I can popup assistance
windows at the right place (I've got that working reasonably by subclassing
TextFieldSkin so I can get at the font metrics).

There are rough edges but I'm really loving the direction that JavaFX is
taking and how responsive the JavaFX team is.  I've submitted bug reports
on a Saturday morning and observed activity on the issue in Jira within
fifteen minutes.

Scott

On Thu, Oct 18, 2012 at 6:57 PM, Mark Claassen <markclaassenx at gmail.com>wrote:

> > Adding a new constructor to set it once would likely work for most cases.
> > I suspect making it dynamic is a lot more work.
> Maybe it is a bit more for the API designer, but, the way I understand it,
> this would preclude the use of the SceneBuilder to create the components,
> without a lot of subclassing.  (See the rest of this thread.)
> If this is not the case, I would be very interested to know how to
> accomplish this.
>
> On Thu, Oct 18, 2012 at 5:09 PM, Scott Palmer <swpalmer at gmail.com> wrote:
>
> > On 2012-10-18, at 3:28 PM, Richard Bair <richard.bair at oracle.com> wrote:
> >
> > > I don't have any philosophical reason for not having content be
> mutable.
> > My only concern here is that having it mutable introduces some additional
> > complexity in the class / skin -- or at least it might.
> > >
> > > BTW, if you find that changing it dynamically works perfect, I'd be
> > happy to do the code review (including Jonathan).
> >
> > Adding a new constructor to set it once would likely work for most cases.
> > I suspect making it dynamic is a lot more work.
> >
> > Scott
>