Layouts with constraint classes (was: Extending Builders: Layout Builders)

[Richard Bair]

>> 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)?
>> 
> 
> Your are right. The original post suggested adding an number of methods to the layout builders. I suggested to not do that, but use formal constraint classes. Richard asked for a discussion on that topic. There was one, but at this point I would say that it comes down to preference, because the getChildren() API and the add(N,C) are in conflict. One camp wants the constraints in the node so you can still use getChildren. The other wants the constraints in the layout, because they are only of value in context of that particular layout. (About your remark on "another type of parent"; that is "another parent", or another instance of a layout classes... there is nothing static going on.)

Having the constraints on the child is certainly the most natural solution with respect to how the FX APIs work. I think we cannot discount the fact that children is a full blown observable list and has the methods for keeping some, removing all, etc. When constraints are defined on the child node itself, it also works more naturally with FXML, and also (for what its worth) means that you can probably define the layout information in CSS and have it apply to a particular node as well. Which is a long-sought-after-feature.

The big hang-up is, if the constraint is defined on the child, then we're left with either a map of constraints (current situation, except we could have direct API on the node for it rather than static methods on the parent), or we require an instance of check and a cast. At least, that is how I see the options when constraints are on the child. Or have an uber-constraint object with everything imaginable, but that obviously isn't scalable to 3rd party layouts and sounds like an awful idea in any case.

Any other ideas?

Richard