How to change item definitions

[Regis Bittencourt]

Hi,

If you compare the way you override the item definitions here:

• http://docs.kendoui.com/getting-started/web/treeview/overview#item-definition

"The text, imageUrl, spriteCssClass and url fields can be changed through the datatextfield, dataimageurlfield,dataspritecssclassfield, and dataurlfield, respectively."

And the way you override it here:

• http://docs.kendoui.com/getting-started/framework/hierarchicaldatasource/overview#the-haschildren-property

The hasChildren property

The hasChildren boolean property indicates whether a data item contains children that can be fetched from the server. You can either hard-code it, map it to another property, or compute it with a function:

You can see that there is no standand. 
I need something like that to my project's datasouce options:
    schema: {
           model: {
               id: "Id",
               hasChildren: "HasChildUnits",
               expanded: "ChildrenDownloaded"
           }
       }
But that does not work as expected. The hasChildren made me believe that this would work.

I think it is a bug.

[Alex Gyoshev]

Hello Regis,

Data projection is not currently supported. In case you need to map the fields, you supply a schema.parse function that makes a one-way projection of the data, as shown in this jsBin sample.

Kind regards,
Alex Gyoshev
the Telerik team

[Regis Bittencourt]

That is definetely what I need and it works!
That should be on the Get started or better documented or exemplified in here
http://docs.kendoui.com/api/framework/datasource#schemaparse-function.

Thank you very much.

[Tim]

It seems the parse function gets in front of AngularJS's HTTP intercept functions. This is problematic as any service logic there will have to be repeated in my parse function. I use it to pass back out of band status data and other structured information in addition to the requested json text.

Can you all consider moving parse behind $httpProvider interceptors? That would greatly simplify the usage of this routine for Angular implementations and fit the expected behavior.

Otherwise this is clean and effective!

Thanks

[Alex Gyoshev]

Hello Tim,

If you are using the default transport, perhaps you can resolve this via a custom transport function that calls $http?

transport: {
  read: function(options) {
    $http(options);
  }
}

If that doesn't help, can you please show an example of the problematic functionality?

Regards,
Alex Gyoshev
Telerik