Heterogeneous schema

[James]

Does HeirarchicalDataSource support heterogeneous objects?
If my transport receives something like:
[{"id": 1, "name": "smith", "groups": [{"id": 1, "typeId": 1, "valueId": 1}]}]

How would the model be defined? Could you do something like:
groupModel = {
    id: "id",
    fields: {
        id: { editable: false, nullable: false, type: "number" },
        typeId: { editable: true, nullable: false, type: "number" },
valueId { editable: true, nullable: false, type: "number" },
    },
    hasChildren: false,
};

personModel = {
id: "id",
fields: {
        id: { editable: false, nullable: false, type: "number" },
name: {editable: true, nullable: false, type: "string" },
groups: groupModel,
},
hasChildren: function(item) {
return item.groups.length > 0;
}
} 
I then use the person object in the model field of the schema in my data source. 
I know the above doesn't work. If I move groups out side of the fields like it doesn't work either. It doesn't seem to know I want to define nested node objects. Do I explicitly need to new Node objects? 

[Dennis]

I would also like to know the answer to this. I find the HeirarchicalDataSource very underdocumented, no useful and real scenarios are covered in the documentation and there are no demos. This is one of them.

[Daniel]

Hello,

Binding to heterogeneous objects is supported by defining a separate dataSource for the children like demonstrated in this demo. The children should be loaded with a separate request in this scenario. If you are binding the data on the client or are using a single request to load the data, the objects should be homogeneous.

Regards,
Daniel
the Telerik team

[Mark]

I've viewed the demo but that seems to only work when you the numbers of nesting.

For example, lets say you have jagged nesting:

Men's Clothes
--->Shoes
--->--->SKU 1
--->Pants
--->--->Jeans
--->--->--->SKU 1

In this case the children of the category could be either a list of SKUs or a list of subcategories.

Does the heirarchical data source support this?

[Daniel]

Hello Mark,

You can bind indefinite number of levels with the HierarchicalDataSource if the data is homogeneous so that it will know how to access the children on each level if they exist. This scenario is demonstrated in remote binding demo where the children of each node can be loaded from the same service endpoint. This will also work for local data if the children can be accessed from the same field. 

Regards,
Daniel
Telerik

[Mark]

Yes - I realize that.  But my comment wasn't about homogeneous data... I was about nesting heterogeneous data when you don't have a uniform depth.

A simple file system type use case can not be supported... or an email service with nested.  E.g. a folder might have subfolders OR files... or and email folder might have emails OR subfolders.  Its is rare that you would ever know how many nestings there are ahead of time.



If the Node object provided some form of a type field/string/object/function to describe the corresponding model that would be very valuable. the library could instantiate the appropriate type at run time. This would also be useful for templating where a simple switch statement could be used to present templates based on the type. I imagine there would be challenges with the datasource fetch as there could be multiple service endpoints a cross the children of a node based on the number of child types. You might consider solving this by changes children from an array to an array of arrays. And you could populated children with the number o possible types, each type having its own endpoint.

Anyway it's a pretty common use case so please forward to product management for roadmap consideration. I'd probably consider that #1 on my list.

[Alex Gyoshev]

Hello Mark,

Indeed, such scenarios seem sensible. From a configuration point of view, the HierarchicalDataSource does not provide a easy way of describing such cases (i.e. where should each type of item take its children from). However, the transport.read configuration option can specify a callback function, as seen in this jsBin sample. This way you can decide (independently for each item) where to fetch its children from. I believe this will fit your described scenario?

Regards,
Alex Gyoshev
Telerik

[Mark]

Alex - perhaps this would work but I don't think the problem is WHERE to read the data from, but rather what TYPE the data is.  The parent data source at transport.read time is already going to be expecting a certain schema/model.   So using the file system analogy... when the transport.read is called that data source would already be expecting a model of a certain type either folder or file.  So if transport read returns a mix of files and folders how would the data source know which to handle?

I don't totally know what's going on under the covers with data source but i'd think the only way to resolve this is to specify different children collection types:  files collection & sub-folder collections, both of which map to a specific kendo model.  Or alternatively, allow the child item in the returned collection to present a field that specifies what kendo model to use.

-mark

[Alex Gyoshev]

Hello Mark,

Indeed, a generic solution for different types of items would require a different implementation. What I was suggesting is to unify the models until such a feature is implemented in the treeview. In particular, folders and files can be specified by the same model, like shown in the templates example. Since JS is not strongly typed, you can serialize whatever data you need for each item, and it does not need to be consistent (as long as you can figure out the logic for displaying an item's text through a template).

Regards,
Alex Gyoshev
Telerik