In T89687#1044215, @cscott wrote:

Another slight inconsistency regards how child content is added to widgets. For most widgets, the PHP appendContent / JS $element.append() / 'content' config option is treated as an 'internal' method -- that is, the widget itself manages its content, and the enduser is not expected to directly add or mutate the contents of the $element / use appendContent.

But in other places (FormLayout for instance), the widget is entirely useless if you don't use $element.append / appendContent. And in the PHP demo app, a raw instance of Widget is created, and content is added to it.

It would probably be best if directly manipulating content were deprecated, and new initializers/methods added where previously the end user was expected to manipulate content. For example, FormLayout should probably take an items parameter. For the usage in the PHP demo app, a special ContentWidget subclass of Widget might be appropriate -- really what's wanted in the demo app is a Widget, but the FieldLayout insists that fieldWidget is a Widget, not a Layout. So maybe a LayoutWidget is needed to bridge the gap?

In T89687#1044231, @matmarex wrote:

I think FormLayout is the only case where that happens, and indeed it should not happen anywhere. The only reason it doesn't take 'items' (containing FieldsetLayouts) is because I haven't done that yet.

In T89687#1044378, @cscott wrote:

@matmarex: grepping for serializeContent in my patch shows that FormLayout, PanelLayout, and DropdownInputWidget all require serializeContent. Plus the bare Widget in the demo.