Layouts with constraint classes

[Tom Eugelink]

On 2012-11-29 23:51, Richard Bair wrote:
> 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

I do not agree with the statement that because children is a full blown observable list, we are obliged to use it. You use what suites best. An API should be setup so it is optimized for the most common scenario's. I have a big car in my drive way, but when taking the kids to school, I use the small one; it suits better for the task. OTOH when I have to drive my basketballteam to a match...

How many JFX developers have, in their first JavaFX application, created a HBox layout, typed ".add", and hit ctrl-space... Then be confused because there is no sensible method to add the node and googled to discovered the getChildren method? And to go even further, how many developers have looked at that "hbox.getChildren().add(node)" line and wondered about the verbosity?

So, all this FXML is great, but my first priority is a good and natural Java API. To me, getChildren and static methods are not it.

Tom