IIRC, the editor framework works by static analysis, so it doesn't work "well" with polymorphism (i.e. you'll have ValueAwareEditor<AbstractBean> or even LeafValueEditor<AbstractBean> all over the place, and in setValue/getValue/flush manually handle each subclass specificity). This also means, IIRC and AFAICT, you cannot quite have such a Group subclass but would have to put the (optional) listNodes property up in AbstractBean.
We made something like this, but without the type hierarchy: a single Criteria class with a CriteriaType enum property (group vs leaf) and all the possible properties in that class (actually into a CriteriaValue class).
Something like:
enum CriteriaType {
Group, Field; // we actually have And, Or, Except, Field
}
class Criteria {
CriteriaType criteriaType;
CriteriaValue value; // only used if criteriaType == Field, should be null otherwise
List<Criteria> criterias; // only used if criteriaType != Group, should be null/empty otherwise
// we actually also have:
// a 'field' property telling us how to interpret the CriteriaValue, that could be an enum with NodeDataType1, NodeDataType2 in your case
// an 'operator' enum property, that can be Equals, Contains, etc.
}
class CriteriaValue {
String stringValue;
Date dateValue;
Boolean booleanValue;
Integer integerValue;
// …
}
To make things more palatable, we've used a GroupCriteriaEditor and FieldCriteriaEditor, the GroupCriteriaEditor instantiates the right editor for each of its children depending on its type, in its setValue, but then also calling their setValue.
And the FieldCriteriaEditor instantiates the right CriteriaValueEditor subclass (StringCriteriaValueEditor, BooleanCriteriaValueEditor, StringAndBooleanCriteriaValueEditor, etc.) in its setValue too, but than also calling its setValue.
And the CriteriaValueEditor subclasses handle their sub-editors (TextBox, CheckBox, etc.) in their setValue/flush, calling their setValue/getValue and getting/setting the appropriate CriteriaValue field.
All in all, we made them all implement ValueAwareEditor "for consistency", but in the end we're not even using the Editor framework for this hierarchical data structure.
I think we could have leveraged the Editor framework had we built a CriteriaValueEditor with subeditors for each CriteriaValue field, and have subclasses initialise those subeditors (leaving the unneeded ones 'null') and handling the "view", but it was 8-ish years ago so I can't really tell whether we even tried it or not at the time, and what exactly (of Mongo/Morphia, RequestFactory and/or the Editor framework) shaped our choice for such a "flat" type "non-hierarchy" of data.