Layouts with constraint classes

[Tom Eugelink]

Because of animation the label may move from one HBox to the other. This is the reason why the current approach stores constraints inside the node, so that when it moves from layout A to B, the constraints also move. My approach allows to specify different constraints for the same node in each layout.

You are right that there should be a parent layout, I left it out to not confuse things, but apparently that is confusing :-)

<VBox>
     <HBox>
        <HBox.C for="arrow" vgrow="NEVER" valignment="RIGHT"/>
     </HBox>

     <HBox>
        <Label  fx:id="arrow"  alignment="center" text="">
            <HBox.C vgrow="ALWAYS"  valignment="LEFT" maxWidth="Infinity"/>
        <Label>
     </HBox>
</VBox>



On 2012-12-01 08:01, Daniel Zwolenski wrote:
> You've lost me. What are you expecting  the actual view to look like with this FXML?
>
> If I interpret it literally you've defined two HBox's one after the other. The first one has no children and an unused constraint, the second one has a Label in it with a constraint on it. I'm guessing you are trying to do something more but it's not real clear what that more is?
>
>
>
> On 01/12/2012, at 5:28 PM, Tom Eugelink <tbee at tbee.org> wrote:
>
>> Not variables, but references. There are constraints specified for nodes that are not yet part of a layout (or even exist at that time, because they are declared further down). Note the absense of a label in the first HBox.C.
>>
>> <HBox>
>>     <HBox.C for="arrow" vgrow="NEVER"  valignment="RIGHT"/>
>> </HBox>
>>
>> <HBox>
>>     <Label  fx:id="arrow"  alignment="center" text="">
>>         <HBox.C vgrow="ALWAYS"  valignment="LEFT" maxWidth="Infinity"/>
>>     <Label>
>> </HBox>
>>
>>
>> Tom
>>
>>
>> On 2012-11-30 14:11, Daniel Zwolenski wrote:
>>> Ah ok, from your example code it looks like you want to use variables in FXML to define your constraints - getting into that territory of CSS-like style definitions that Richard was talking about?
>>>
>>> Assuming this is what you want, this can be done in the current setup using the ridiculously under-documented <fx:define> thing.
>>>
>>> I knocked up a very rough sample for you quickly. The FXML looks like this:
>>>
>>>   <BorderPane xmlns:fx="http://javafx.com/fxml">
>>>
>>>     <fx:define>
>>>         <HBoxConstraints fx:id="noGrow" hgrow="NEVER"/>
>>>         <HBoxConstraints fx:id="growLots" hgrow="ALWAYS"/>
>>>     </fx:define>
>>>
>>>     <center>
>>>         <HBox>
>>>             <Label text="I don't grow" style="-fx-background-color:green" Constraints.constraints="$noGrow"/>
>>>             <Label text="I grow big" style="-fx-background-color:yellow" Constraints.constraints="$growLots"/>
>>>         </HBox>
>>>     </center>
>>>
>>>   </BorderPane>
>>>
>>> (see https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/resources/fxml/example.fxml)
>>>
>>> I made a base Constraints class with a static helper method on it (called via "Constraints.constraints" in the FXML above):
>>> https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/Constraints.java
>>>
>>> And then a specific instance of HBoxConstraints:
>>> https://code.google.com/p/zenjava-playtime/source/browse/trunk/layouts/src/main/java/com/playtime/layouts/HBoxConstraints.java
>>>
>>> Obviously you would add others, like VBoxConstraints, GridPaneConstraints, etc. All pretty trivial. These helper classes could easily be included in something like JFXtras.
>>>
>>> So I stick with the stance that FXML is more or less OK here (not to say I wouldn't improve it lots in other areas), and really your conversation is about the Java API which is nicely decoupled to what can/can't be done in FXML. Kudos to Richard and the JFX team for designing the builders right.
>>>
>>>
>>>
>>>
>>> On Fri, Nov 30, 2012 at 9:20 PM, Tom Eugelink <tbee at tbee.org <mailto:tbee at tbee.org>> wrote:
>>>
>>>     On 2012-11-30 10:59, Daniel Zwolenski wrote:
>>>
>>>         It just doesn't do it the exact way you suggest where you specify multiple possibilities directly in the child in case it ends up in a different parent - not an approach I agree with anyway (see my previous comments), but that's just my opinion.
>>>
>>>
>>>     Just to make sure my suggestion is not misunderstood, it does not specify multiple possibilities in the child, but in the layout.
>>>
>>>     <HBox>
>>>         <HBox.C for="arrow" vgrow="NEVER"  valignment="RIGHT"/>
>>>     </HBox>
>>>
>>>     <HBox>
>>>         <Label  fx:id="arrow"  alignment="center" text="">
>>>             <HBox.C vgrow="ALWAYS"  valignment="LEFT" maxWidth="Infinity"/>
>>>         <Label>
>>>     </HBox>
>>>
>>>