Extending Builders: Layout Builders

[Daniel Zwolenski]

This thread has meandered a bit and I've lost track of the problem you're trying to solve. Would it be possible to restate the end goal (in a short sentence or two)?

If it is to simplify the FXML then I still think builders would do it  (Greg would normally have chimed in by now so I assume he's off-list). If you provide a short snip of your ideal FXML I'll have a crack at achieving it with builders. 

If the goal is better tool support, I'm not sure what can't be achieved through inspection of node and builder classes so an example would be good. 

If the goal is something else, I lost track. 

One comment: the idea of setting constraints in case the node moves to another type of parent (ie right align me in a GridPane, left align my in a HBox) is something I don't like the look of. You need the contextual information (eg am I on the person details page or the person summary page), the container 'type' does not provide this. If you want true portability of your fxml control better to push the declaration of the constraints into each FXML that declares the container (migpane can do this to a certain extent). This can again be achieved with builders (and numerous other techniques). Happy to show examples of this if needs be. 


On 30/11/2012, at 7:50 AM, Tom Schindl <tom.schindl at bestsolution.at> wrote:

> Where do you see reflection happening?
> 
> The Layout container would call the get(int) method and you get what you
> want a constraint specific for your layout container to programm against.
> 
> Tom
> 
> Am 29.11.12 20:56, schrieb Tom Eugelink:
>> All these constraints-stored-in-the-node approaches ignore the fact that
>> not the same constraints need to be valid for all possible layouts. Two
>> layouts also can be extremely different; suppose a HBox and a Circular
>> layout. Layout constraints exist in the intersection between node and
>> layout, they should not be pushed into some generic store.
>> 
>> And there is concern about speed because of casting, but won't
>> reflection have a much bigger performance penalty?
>> TomE
>> 
> 
> 
> -- 
> 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