Extending Builders: Layout Builders

[Daniel Zwolenski]

The following is based on my experience using FXML. Someone from Oracle might know better. Is Greg still working on this - I have a vague memory of an email saying he wasn't?

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

Loosely connected. If a builder is available FXML can use it, if not reflection straight onto the class. Optional for your own custom classes, most (all?) core jfx classes have builders.  

> 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?

Yes, unless you want to use them to simplify your own class construction or you're looking for convenience methods to use in FXML that aren't on the regular control class. 

> 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?   

Optional. But the docco is poor (and reads like a tech manual - I've always loved the docco on spring as a guide for doing it right. The docco on maven is a guide for doing it wrong). 

> 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?

Safest would be to just use your class and not use a builder, then the class is the meta data. 

I'm not too sure on how the builder is hooked into the FXML but I would have assumed reflection too. I would have thought the tools could just inspect the builder class to find methods on it but if not perhaps there is a need to allow builders to declare their meta data (eg annotations, javadoc tags or XML). 

FXML operates 'above' the control level so in general it doesn't have any special information that the builder tools wouldn't have. The only difference is FXML is grabbing the data whereas the builder tools want to list the options so there could be some gaps. 

> 
> 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?

Interesting idea. 

You could certainly post process the FXML to do this. Probably pretty hard to go back the other way though once the file is edited. 

Groovy (as in the language) is something I've wondered about as an alternative to FXML. The desire to use XML was strongly biased by the popularity of HTML, ie make it on par in terms of skillset so HTML devs could switch. Doesn't necessarily make it the 'best' technology though and since FXML is a layer above we have the option to change (and I'll stop before I get fired up on CSS). 

If I wasn't working on messy deployment code for the foreseeable future I would much prefer to be working on an alternative to FXML that allows for templating and scripting (more like jsp). Maybe next year, when oracle release it jfx on mobile meaning I can actually get some paid jfx work ;)

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