Extending Builders: Layout Builders

[Tom Eugelink]

Uhuh. I see. Of course I know the regular builders for creating controls and layouts. I did not know that FXML uses builders with the same interface, which is probably why I skipped the wrong links on google.

Anyhow, I see possible issues which would need to be addressed (http://docs.oracle.com/javafx/2/api/javafx/fxml/FXMLLoader.html):
- First you can only provide one builder, so that would mean they'd have to chain, and that is very unpractical.
- Secondly it's the fact that you need to explicitly provide the builder to the load method. I would aim for automatic inclusion; adding a jar with a set of control to the classpath should automatically add any builders required to parse the FXML.
- And lastly: not all builders actually build something. In case of the HBox.C scenario it creates a constraint class, but pushes that out to a layout already created. The build method returns null.

So I figure if these chances were made to the usage of builders in FXMLLoader, it could work for commen FXML scenario's. However, the SceneBuilder still would have no clue what constraint class to generate when adding a node to ABCLayout. And the thing I did with setting a HBox.C constraint on a layout where the node is not yet part of, would also be a problem: because it requires an "after document" style of event.

It is my impression that the builder pattern is to narrow focused, and I'm not sure if bolting on the additional logic is the best course of action. It may be easier / cleaner to create a new API for that.

Tom





On 2012-11-27 07:51, Daniel Zwolenski wrote:
> They can be difficult to google thanks to "Scene Builder" hogging the google-sphere.
>
> Builders are basically convenience factories for building Nodes. Michael Heinrichs gives a good view on builders here: http://blog.netopyr.com/2012/01/24/advantages-of-javafx-builders/
>
> They aren't really specific to FXML but FXML makes use of them to simplify the XML syntax and add convenience methods to Node classes. There's a bit of mention of them in the FXML docco: http://docs.oracle.com/javafx/2/api/javafx/fxml/doc-files/introduction_to_fxml.html#class_instance_elements
>
> There's a bit more of a clue on how to use them in this: http://jayskills.com/blog/2012/04/12/add-custom-components-to-fxml-using-builderfactory/
>
> I haven't followed all of this conversation but I suspect builders could do the sort of syntactic sugar you wanted.
>
> From the sounds of it, builders possibly could be used to simplify the MigPane code too (but I haven't looked and from a user's perspective, what you've done works fine).
>
>
>
>
> On Tue, Nov 27, 2012 at 5:16 PM, Tom Eugelink <tbee at tbee.org <mailto:tbee at tbee.org>> wrote:
>
>     On 2012-11-27 01:51, Richard Bair wrote:
>
>             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?
>
>
>     I don't know. This is the first time I've heard of FXML builders, otherwise I would have used them for MigPane. I did not find anything on the google, do you have a reference to some documentation or example?
>
>     Tom
>
>