TextField Document model

Scott Palmer swpalmer at gmail.com
Fri Oct 19 08:01:47 PDT 2012

Put the dynamic aspect inside your Content implementation.  So it can delegate to something that handles whatever the current format should be. You still pass one fixed interface to the constructor.


On 2012-10-19, at 9:16 AM, Mark Claassen <markclaassenx at gmail.com> wrote:

> 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