Layouts with constraint classes (original) (raw)
Daniel Zwolenski zonski at gmail.com
Fri Nov 30 01:10:52 PST 2012
- Previous message: Layouts with constraint classes
- Next message: Layouts with constraint classes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: Layouts with constraint classes
- Next message: Layouts with constraint classes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]