Re: Hierarchical data with Editor

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.

On Sunday, September 27, 2020 at 11:52:55 AM UTC+2, pierre...@gmail.com wrote:

Hi,

My use case is to edit an hierachical list of node and group of nodes.

Starting from a root group, user can create/delete groups and create/delete/edit nodes inside group.

The Node have dynamic types. Type and the corresponding data is choosen at creation time.

Node is a leaf in the hierachy. Only 1 node can be edited at a time, all others are just displayed.

The model is :

// abstract for Node and Group of Node

class Abstractbean

{

String id;

String name;

}

class Node extends Abstractbean {

enum typeNode

NodeData data

}

class Group extends Abstractbean

{

List<Abstractbean> listNodes;

} 

//examples of type of data

class NodeDataType1 implements NodeData

{

String model;

..

}

class NodeDataType2 implements NodeData

{

Date model;

..

}

Do you think that Editor framework is a good choice for such an use case ?
Thanks in advance for any hints

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/2db54a45-ffd2-4c6e-930e-92f28291040fo%40googlegroups.com.