Layouts with constraint classes

[Tom Schindl]

Am 30.11.12 09:02, schrieb 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...
> 

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

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

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.

Tom


-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834