On 18/04/2023 19:14, Michael Strauß wrote:
Here's a draft PR: https://github.com/openjdk/jfx/pull/1096
There are some API changes compared to my last email, the most notable
being that the content graph can now contain arbitrary objects. This
allows the content graph to directly contain a ListView's item list,
or a Labeled's text.
I've looked it over a bit. Would it be needed to have wrappers around
some parts of the content graph now that it supports arbitrary objects?
ie. instead of:
MenuItem
String
Rectangle
with wrappers:
MenuItem
Label
String
Graphic
Rectangle
The reason I ask is I wonder if the type itself will always be
sufficient to distinguish the various parts a control adds to the
content graph. A ListView's items for example could be arbitrary
objects; if ListView contributed anything other than its items, it would
be hard to pick it out.
Or consider a control that for some reason has two texts; I have some
reusable controls that display an image, a text on top (title) and a
text at the bottom (subtitle). These are all labels:
FancyControl
String (Label with text only)
String (Label with text only)
Image (Label with graphic only)
Would the returned list here be read only?
The content graph API is read-only, as its state depends entirely on
the properties of the participating controls.
Okay, my confusion stems from that there are ReadOnly interfaces for
properties, but apparently not for ObservableList. Read only seems good
to me.
For a lot of controls I think the content nodes will be fixed
(SplitPane, Label, Button), but for others like MenuButton or containers
these need to be modified. Does it make sense to use a similar model
here that is used for properties? Some controls would still need to be
able to modify the list directly, in which case subclasses could go that
route as well, circumventing these protections.
I'm not entirely sure if I understand the problem. For example, the
content model of Pane corresponds exactly to its children list. If a
subclass of Pane needs to add something that is not a child, for
example a "text" or "graphic", it simply adds its own content model in
the subclass. The combined content model of the control will then
consist of the entire children list of Pane, as well as the custom
properties that the subclass added.
In this case, the subclass will not be able to change the fact that
Pane added its children to the content model. That is by design, as a
subclass of Pane is still a Pane, after all.
I see that you went a different route here, without using an overridable
`buildContentModel` (subclasses could not call `super` and in that way
influence what the parent has as content model).
I guess what is happening is that there are multiple ObservableLists
that are being concatenated; each individual list is under control of a
single class, and a subclass can't access the list of its superclass in
any way.
--John
