Content Graph

[Michael Strauß]

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 think this may be a good idea, but I would like to know more about the
> use cases.

Most of the time application developers will think of their UI not in
terms of the scene graph (with inflated skins and cells), but in terms
of the content graph. That's why many people are surprised to find out
that some nodes aren't contained in the scene graph, while unexpected
nodes will be there.

There are a lot of very specialized use cases, most of which involve
some sort of reasoning about the structure of the UI. For example, in
one example I needed to inspect the Node.properties map of all logical
ancestors of a node (excluding skin nodes). I think there are many
application-specific use cases like that. UI testing was also
mentioned in another email. You say that since you built the UI, you
should be aware of how it is structured. That's true, but you still
need to have some kind of representation, and the content graph is
exactly that.


> 2) How far does a content graph go? It contains MenuItem. Should or will
> it contain ListView items?

Well, that depends on the content models of the participating
controls. Often, there is a "natural" content model, which is often
visible in the constructors of the controls.
For example, Labeled has a constructor that takes in a "text" and a
"graphic", which we'll define as its content model.
MenuItem also has a "text" and a "graphic", and Menu adds "items",
which is a list of MenuItems.
ListView only consists of its "items". That's as far as the content
graph will go in this case.


> 3) Will this require a new observable list for every parent node, or is
> it going to be the same list for most of the nodes?

Yes, but these are specialized lists in most cases, often just thin
wrappers around an existing list. For example, Pane wraps its
"children" list, while ListView wraps its "items" list.


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


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


> If the primary content graph is always determined by the "base" control,
> and subclasses can only contribute additional nodes without being able
> to modify anything, would that make it impossible to create a new
> container type node (or perhaps we're already constrained here by having
> to subclass Parent) ?

Let's say you want to create a new container which is not a Pane. The
route to do that would be similar to how Pane defines its content
model, which is to add its children list to it by calling
`addContentModel(myChildren)`.
However, if your new container is a subclass of Pane, you can't change
the fact that it defined its children as content.