Extending Builders: Layout Builders

[Daniel Fuchs]

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?
>
> Richard
Hi,

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 
introspection.
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.

cheers,

-- daniel