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