Viewmodels and Widget Subclassing

Development Programming & Scripting UI
, ,
1

Is there anything on the roadmap that will eventually support specialized bindings in widget subclasses. Some use cases:

  1. A base class binding that I want to specialize in the subclass with a subclass of the base viewmodel
  2. An additional binding I want to make in the subclass widget that uses the base class’ bound viewmodel.
  3. An additional viewmodel that I want to bind in the child widget.

Right now we are working around some of these issues by not using the binding system and having functions in the widget base class “GetViewmodel” that are then specialized in the widget subclass, and doing bindings through blueprints rather than the binding interface, but this introduces a lot more boilerplate and complexity for designers.

2

Steps to Reproduce

  • Create a widget blueprint class hierarchy.
  • Bind a viewmodel in the base class widget
  • Bind a viewmodel in the subclass widget
  • attempt to use bindings in the binding interface
3

Hi,

We don’t have any plans to share at the moment, as we currently only support one View per widget. These workflows would require some degree of View merging to collate bindings from the base and child classes into a single view. We don’t plan to ever support overriding bindings (which sounds like scenario 1), but we’d like to eventually support scenario 3.

Just to clarify your current approach, you have a base widget class with a base VM that sets up bindings, and a child class with a derived VM adding additional fields that it uses? Would that mean your widget tree is set up on the child class? I wonder if it would be possible to shift any functionality to the base class to alleviate some of the boilerplate that you’re having to set up.

Best,

Cody

4

What we’ve been doing to get around these limitations is:

  • Base class has a GetVM that returns null
  • Base class functionality is entirely manual in blueprints (no bindings in the binding interface)
  • Child class uses VM bindings, has whatever VMs it needs, including either the base widget’s expected VM or a specialization of it.
  • Child class overrides GetVM to return its implementation of the expected VM class
5

That makes sense, as that would mean the child class is creating the View and the base is adding bindings to it (without necessarily knowing anything about it). The other approach that comes to mind would be to lean more into composition instead of inheritance. Your “base class” becomes a UserWidget with a base viewmodel and some widgets (including one or more NamedSlot), then your “child class” becomes another UserWidget which has an instance of the base in it’s hierarchy and fills in the named slot(s) with additional content. The pro is that both the base and the child can maintain their own viewmodel with it’s own bindings, though the downside is that they’ll be constrained to binding things to the WidgetTree actually defined within that UserWidget (so still no concept of overriding). We do something similar to effectively merge widget trees, since a single UserWidget can only have a single WidgetTree which will be overridden the moment you add anything to the hierarchy in a child widget (though C++ base classes also give you opportunity to inject that tree into a larger hierarchy).