Extending Builders: Layout Builders
daniel.fuchs at oracle.com
Tue Nov 27 01:29:39 PST 2012
On 11/27/12 4:45 AM, openjfx-dev-request at openjdk.java.net wrote:
> Message: 1
> Date: Mon, 26 Nov 2012 16:51:16 -0800
> From: Richard Bair<richard.bair at oracle.com>
> Subject: Re: Extending Builders: Layout Builders
> To: Tom Eugelink<tbee at tbee.org>
> Cc:openjfx-dev at openjdk.java.net
> Message-ID:<FEBAB867-47B2-46EF-A0BA-42584C5F4161 at oracle.com>
> Content-Type: text/plain; charset=iso-8859-1
>> > But I'd rather use a different approach: provide (de)serializers that help map the FXML onto the objects. I see FXML as a layer on top of the API and good software development teachings say that lower layers should not have any knowledge of higher layers, so I feel really really bad about polluting the Java API to support FXML. Providing glue might be a better approach. Java has standard plugin-style solutions in place, like META-INF/services, so it should be easily possible to provide plugins together with the components that help in those places where simple serialization does not cut it.
> Isn't this the role that the builders already play in the FXML deserialization routine? My understanding was that people would be able to create custom builders for their classes (and we could provide custom builders for ours) such that you would be able to map such things from the FXML?
It is important for tools like SceneBuilder to be able to introspect
builders, one way or another.
At this time for every custom builder we need to add special code in
SceneBuilder. The JavaFX generated builders can - until now - be
introspected and so SceneBuilder can support them generically through
Keep in mind that not all bean properties will be present in FXML - but
all will need to be present in the SceneBuilder's Inspector. When a
property is dynamically set by the user in the inspector, then
SceneBuilder needs to emulate what the FXMLLoader would have done if it
had encountered this property in FXML (this is that - or modify then
reload the whole FXML).
If the FXMLLoader uses custom builders whose behavior is opaque then
there is no way to know what changing a property will do on the target
object. Sometimes reloading the whole FXML is the only thing that SB
will be able to do, for instance - if SB supports modifying some
constructor property from the Inspector. But for this to happen it means
that SB would first need to know that it is a constructor property - and
not a simple read-write property.
More information about the openjfx-dev