Fundamentally, you want a CompositeEditor
to handle cases where objects are dynamically added or removed from the Editor hierarchy. The ListEditor
and OptionalFieldEditor
adaptors implement CompositeEditor
.
If the information required for the different types of questions is fundamentally orthogonal, then multiple OptionalFieldEditor
could be used with different fields, one for each question type. This will work when you have only a few question types, but won’t really scale well in the future.
A different approach, that will scale better would be to use a custom implementation of a CompositeEditor + LeafValueEditor
that handles a polymorphic QuestionData
type hierarchy. The type drop-down UI element would become an implementation detail of the CompositeEditor
. When a question type is selected, the editor will call EditorChain.attach()
with an instance of a QuestionData
subtype and the type-specific sub-Editor. The newly-created QuestionData
instance should be retained to implement LeafValueEditor.getValue()
. The implementation of CompositeEditor.setValue()
just creates the type-specific sub-Editor and calls EditorChain.attach()
.
FWIW, OptionalFieldEditor
can be used with ListEditor
or any other editor type.