Extending Builders: Layout Builders (original) (raw)

Tom Schindl tom.schindl at bestsolution.at
Fri Nov 23 02:08:35 PST 2012

Hi,

Let me retry - I hope this doesn't get too long.

FXML is simply a serialization definition to serialize ANY given java-object graph.

Let's take your example:

which means in full blown FXML without default-attributes

So written in Java-Code it means

HBox box = new HBox(); Label l = new Label(); l.set... HBox.C c = new HBox.C(); c.set... l.setConstraint(c); box.getChildren().add(l);

Definately not what you want because your layout-containers code looks like this:

HBox box = new HBox(); Label l = new Label(); l.set... HBox.C c = new HBox.C(); c.set... box.add(l,c);

Which clearly violates the generic serialisation which says sub-elements are always added (if it is a list) / set (single attribute) on the attribute they are the child of.

So if we take your proposed FXML as shown above we have a problem because when we follow the general serialization/deserialization strategy we'd have to have a layoutConstraint-Property on the Node although things like layouts only make sense when you add the node inside a layout-container but not if it is e.g. a child of a Group, ...

To summerize: My point - I fully agree with you that when coding the UI in Java your layout-container additions make a whole lot of sense but they break the serialization infrastructure because the addition is not done on the attribute itself (children) but through the owner of the attribute (HBox).

Tom

Am 22.11.12 19:51, schrieb Tom Eugelink:

Not sure I understand what you are trying to say here. Each layout has different and much deviating constraints, so they cannot be unified into one model.

I think I summarized it well in my blogpost: "All information about the layout of a single node should be stored in one place." This means absolute layout can suffice with the X,Y,W,H information available in the nodes (and thus allow binding), but all more advanced layouts require a separate constraint class. Tom

On 2012-11-21 22:42, Tom Schindl wrote: the nice thing about the current expression with static calls is that the semantics for adding children are always the same whether your target is a Layout-Container or e.g. a Group. You always call add on the target your specified. Your way of layout containers expects two different things to happen: * for layout container you want to call add on the owner because you want to pass the constraint object * you can add on the list itself for stuff like Group but also Tables Not to forget how would you like set the constraint when you not add to a list e.g. when using a borderpane? Tom Am 21.11.12 19:02, schrieb Tom Eugelink: I suspect the constraints were already "out" before FXML, but this would be a fairly acceptable notation:

| <Label fx:id="arrow" alignment="center" text=""_ _maxWidth="Infinity"> | || <HBox.Cvgrow="ALWAYS" hgrow="ALWAYS"|/> |

Or: | <Label fx:id="arrow" alignment="center" text=""_ _maxWidth="Infinity"|||HBox.C.vgrow="ALWAYS" HBox.C.hgrow="ALWAYS"|/> |

On 2012-11-21 17:46, Tom Schindl wrote: Am 21.11.12 09:46, schrieb Richard Bair: I wanted constraint classes from the start. There was a problem there, which I don't accurately remember now, but I do want to see some discussion around deprecating (or at least no longer depending on) the static methods and having some constraint classes again. They've probably been harder to implement in FXML? Tom

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

More information about the openjfx-dev mailing list