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

[Daniel Zwolenski]

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:

- there are no problems in FXML at the moment, binders can be used to add
syntactic sugar. Possibly some of the existing binders could be enhanced to
add some more sugar - we should define the sweet FXML and work out the
binding enhancements needed.

- there may be some problems with the tools (i.e. scene builder) detecting
certain things but it's not too clear what these problems are - we should
identify the problems.

- there is a perfectly functional but not-very-nice use of static methods
in the Java code to set constraints - these would be nice to avoid but were
done this way for a reason (which may now be forgotten) - we could discuss
ways to get rid of these but this is largely independent on what we want to
see in the FXML.


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