TextField Document model
Mark Claassen
markclaassenx at gmail.com
Fri Oct 19 06:16:01 PDT 2012
I am still a bit unclear on how I would do this. I would like to create
and position the field using the SceneBuilder, but the document model and
formatting are determined by other parameters, such as fields read out of a
database. Take postal codes for instance, for the US it is #####-####, but
for Canada it is A#A-#A# (where A means any letter). It would not be until
they chose a country that the formatting could be selected and applied.
I don't see how I can do this using the constructor approach and still use
SceneBuilder without creating an extra layer of indirection designed
specifically sidestep this issue. I could create a subclass of TextField
that would simply pass the calls to a delegate Content, which would be
pluggable. This approach, however, just sort of pushes the can down the
road a bit by forcing a layer of indirection.
I did not have time to look at the Skin and Behavior paradigms yet, so I
can't speak to the impact on them. I will try to brush up on those this
weekend. However, if this subclassing to delegate becomes relatively
common, then it seems that whatever Skin and Behavior issues might arise
would still need to be addressed. However now they would need to be
addressed by application designers instead of by the platform.
Mark
On Thu, Oct 18, 2012 at 7:23 PM, Richard Bair <richard.bair at oracle.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.
>
> Actually, as long as there is a Builder for the class, you should be able
> to build it from FXML even if there is no default constructor.
>
>
More information about the openjfx-dev
mailing list