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

Daniel Zwolenski zonski at gmail.com
Thu Nov 29 17:02:11 PST 2012

When I say "defining" constraints in the parent (vs child) I am talking about how you declare it in the FXML and this does not have to match what happens in the Java world (because we have binders). The Java side of it can still "store" the constraints on the child (or not, whatever you want). The "glue" (e.g. binders) can map from FXML world to Java world, allowing both to be optimal for their needs.

The suggestion looked to me to be that the Java model needs changing in order to better support atomic FXML snippets being more easily moved from container to container (i.e. if I happen to be in a HBox use these, if I happen to be in a GridPane use these).

If the goal is to allow for the FXML to be reused then the container should know about the child but the child should not know about it's container. So we just need a way to "declare" the constraints in the parent (i.e. I am the PersonDetails view so I will add this atomic block of FXML left aligned, vs I am the PersonSummaryView so I will add this block right aligned) instead of in the child (i.e. I am an atomic block of FXML - if you put me in a HBox I should be left aligned, if you put me in a GridPane I should be right aligned).

Plenty of mechanisms already exist for declaring the constraints in the outer FXML (builders being one of them) and these co-exist with the existing way of specifying them at a child level, allowing developers to mix and match based on their scenario. For me, I don't see a need to change the Java API to make anything "better" here for FXML and component re-use.

This was just a side comment though and the thread meanders further. In lieu of someone else summarizing the goals, here's my take and you guys can maybe correct any misunderstanding I have:

Cheers, Dan

On Fri, Nov 30, 2012 at 9:51 AM, Richard Bair <richard.bair at oracle.com>wrote:

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

More information about the openjfx-dev mailing list