Layouts with constraint classes

[Daniel Zwolenski]

Disagree that there are not a lot of use cases for getChildren
(observable/binding would be a start) but the point is completely moot
since I would guess there is a big fat zero chance of that kind of change
happening - backwards compatibility won't even let us have interfaces "just
in case", getting rid of getChildren would be out of the park.

Agree that the process should (in all things) be 1) define the ideal Java
API first 2) use glue to adapt higher level tools/APIs to that ideal Java
one 3) only compromise the ideal API as a last resort if the glue can't do
it (should be extremely rare). In general, from what I have seen Richard
has done a pretty good job at this (except in the case of CSS where the
exact opposite was done), with Builders being a great example/pattern.

I'm pretty confident if you specified your ideal FXML it could be built
using builders - possibly with some modifications and at worse some tweaks
to the FXMLLoader. Changing the Java Node classes should not be needed for
this. Up to you guys, but I think your conversation is best focused on the
Java API and leave FXML out of it until the end.

On the Java API side of it, my 2c:

- The current API works fine and doesn't "need" to be changed but it is
also a bit weird and unintuitive so it could be improved.

- For backwards compatibility any proposed change would likely need to be
in-addition-to the current API (i.e. addition of extra convenience methods,
not removal or major refactoring).

- Builders provide a way to specify an alternate API (in Java as much as
FXML) for this exact goal of convenience and intuitiveness, e.g. you could
easily have a HboxBuilder.add(Node, HboxConstraints) if you want that
called the static methods on the Node (based on HboxConstraints), and then
added the Node to the HBox. A suite of enhanced builders sounds like a
great mini-project for JFXtras, with the good ones eventually making it
into JFX official.


For me personally this is all a pretty low priority (it's just that this
deployment code is so painful I am easily distracted) so I'll leave you
guys to it unless you want me to chime in on the FXML side of it (I've hand
written a hell of a lot of FXML, written custom components with builders in
it, and had a good few debates/arguments with Greg about some of the
internals).

I am still a little curious though, is Greg no longer working on this, and
if so who is now responsible for FXML?




On Fri, Nov 30, 2012 at 7:27 PM, Tom Eugelink <tbee at tbee.org> wrote:

> On 2012-11-30 09:13, Tom Schindl wrote:
>
>> We are not obliged to use it but if wanted we can and if we don't have
>> the setLayoutConstraint()-API on the node I can't. Having this
>> layout-constraint API on Node gives us both what we want: a) you can have
>> the convenience API on layout b) I can still use bulk operations c) There's
>> not change needed in FXML infrastructure
>>
>
> I believe 99% of the use cases will not involve operations that benefit
> from getChildren; most use case will be simple "add-node-to-layout-with-**specific-constaints".
> This is what the API should be optimized for. Maybe we can find some source
> that helps us define the most common use cases.
>
>
>
>  I understood Richards last comment in the way that having the
>> layout-constraint on each node has the benefit that no changes to FXML are
>> needed. I think what Richard and myself are after is to have an API that
>> allows to have a Java-API which does not make the FXML case harder.
>>
>
> But the things that are needed to make FXML not harder (or make the FXML
> format readable) should not pollute the Java API. Glue IMHO should be put
> in a separate class or file.
>
> Tom
>
>
>