Extending Builders: Layout Builders

[Tom Schindl]

FXML only depends on builders when the object it creates has no no-arg
constructor or one wants to set readonly attributes who can only be set
when the object is constructed.

Tom

Am 27.11.12 22:28, schrieb John Smith:
> It seems odd to me that Builders and FXML are connected - from a Builder API or FXML user point of view they seem like such different things.
> I don't really know how this stuff works, so I'm going to do some speculation in this email, please correct me if I'm wrong.
> 
> I knew that the FXML implementation was doing some introspection to determine property names and types, but I thought it was on the public control or layout API (e.g. HBox or Button) and not the Builder code (e.g. HBoxBuilder and ButtonBuilder).  I guess that's not true and I didn't understand that relationship properly - thus Richard's comments around not polluting the Java API to support FXML explain part of the reason the FXML implementation works as it does.
> 
> I'm guessing for JavaFX, with respect to visual tools like SceneBuilder, Builders are currently functioning like BeanInfo  http://publib.boulder.ibm.com/infocenter/iadthelp/v6r0/index.jsp?topic=/org.eclipse.ve.doc/topics/cve_beaninfo.html; i.e. providing the metadata the visual tools require to do their job.
> 
> I guess the connection between Builders and FXML is more an implementation detail than anything a typical JavaFX programmer using the Builder API or FXML would ever worry about?
> 
> However, people writing libraries which include new controls and layout managers need to understand this connection, because they need to create compatible Builders for their controls and layouts?   Currently, the safest way to do this would be use the JavaFX generated builders so that the new control would be compatible with an off the shelf SceneBuilder which did not include custom code?
> 
> As a side product of the current congruence between FXML and Builders, does it mean that a tool like SceneBuilder could (without an inordinate amount of work) be made to work with generated Java Builder code rather than FXML files?
> 
> -----Original Message-----
> From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Fuchs
> Sent: Tuesday, November 27, 2012 1:30 AM
> To: openjfx-dev at openjdk.java.net
> Subject: Re: Extending Builders: Layout Builders
> 
> 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
> 


-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834