'Complex' DataSource model validation

[Vito]

Hello,

I am building a grid with a complex datatype. Example below.

I am trying to do some custom validation, but it is not working. It doesn't even seem like it is hitting it.

If I do it on the 'LegacyID' field, which is the only not 'complex' field, it works perfectly fine.

Am I missing something? Doing something wrong?


schema: {

           model: {

               id: 'LegacyID',

               fields: {

                   LegacyID:{type:'number', editable:false},

                   Clean:{

                       ID: { type: 'number' },

                       JobID: { type: 'number' },

                       ProcessFlag: { type: 'string' },

                       OverallStatus: { type: 'string' },

                       LastRecordUpdater: { type: 'string' },

                       LastUpdatedDateTime: { type: 'date' },

                       CleansingComments: { type: 'string' },

                       MaterialNumber: {

                           type: 'string',

                           validation: {

                               custom: function (input) {

                                   console.log(input);

                                   if (input.val().length > 18) {

                                       input.attr("data-maxlength-msg", "SAP Material Number cannot exceed 18 characters.");

                                       return false;

                                   }

                                   return true;

                                    

                               }

                           },

                       },

                       MaterialBaseNumber: { type: 'string' }

 

           }

       },

[Alexander Valchev]

Hi Vito,

The dataSource is designed to work with flat (not nested) data. Defining a 'complex' objects in the schema.model is not supported. In other words the syntax:

    fields: {
        LegacyID:{type:'number', editable:false},
        Clean:{
            MaterialNumber: {
                type: 'string',
                validation: {
                    custom: function (input) {
                         //....
                    }
                },
            },
            MaterialBaseNumber: { type: 'string' }
}

is not a valid one.

It would be best if you could flattern the data on the server, but in case this is not possible you can use the from property of the model field. For example:

schema: {
    model: {
        id: "id",
        fields: {
            id: { type: "number", editable: false },
            materialNumber: {
                type: "string",
                from: "clean.materialNumber",
                validation: {
                    custom: function(input) {
                        console.log("input");
                        return false;
                    }
                }
            }
        }
    }
}

For your convenience I prepared a small runnable example:

• http://jsbin.com/qakiboti/2/edit

Regards,
Alexander Valchev
Telerik

[Vito]

Alexander,

Thank you for your reply! I was trying to avoid flattening the data, but it seems to be the right choice.

The problem with using the from, as you suggested, is that it interferes with how the data is submitted.

For instance, here is how the data would look when it hits the 'POST' function:

Object{
   Clean{
      OverallStatus: { type: 'string' },
      LastRecordUpdater: { type: 'string' },
      LastUpdatedDateTime: { type: 'date' },
      CleansingComments: { type: 'string' },
   },
   Legacy{<data>}
      //.....
   }
}

But after using the 'from' tag, here is how the data looks:

Object{
   Clean{
      OverallStatus: { type: 'string' },
      LastRecordUpdater: { type: 'string' },
      LastUpdatedDateTime: { type: 'date' },
      CleansingComments: { type: 'string' },
   },
   Clean.OverallStatus: { type: 'string' },
   Clean.LastRecordUpdater: { type: 'string' },
   Clean.LastUpdatedDateTime: { type: 'date' },
   Clean.CleansingComments: { type: 'string' },
   Legacy{<data>}
      //.....
   }
}

So, when I post this, it only reads the top-level 'flattened' data, when I need it to read all of it, including both objects.

The reason why this wont work for me is partially because I am using quite complex editor templates that gets/sets the item value manually.

In the end, I have it figured out (in the least ideal way possible), which was flattening the data on the server side.

--------------------------

This all would have been avoided if validation is supported for 'complex' or nested data. 

Are there any plans to implement something like this? I'm sure that I'm not the only one that is having this kind of issue.


Thank you for your help, I appreciate it!

[Vito]

SORRY, let me try that code example again!

Object{
   Clean{
      OverallStatus: "<value>",
      LastRecordUpdater: "<value>",
      LastUpdatedDateTime: "<value>",
      CleansingComments:"<value>",
   },
   Legacy{<data>}
      //.....
   }
}

But after using the 'from' tag, here is how the data looks:

Object{
   Clean{
      OverallStatus: "<oldValue>",
      LastRecordUpdater: "<oldValue>",
      LastUpdatedDateTime:"<oldValue>",
      CleansingComments: "<oldValue>",
   },
   Clean.OverallStatus: "<newValue>",
   Clean.LastRecordUpdater: "<newValue>",
   Clean.LastUpdatedDateTime: "<newValue>",
   Clean.CleansingComments: "<newValue>",
   Legacy{<data>}
      //.....
   }
}

[Alexander Valchev]

Hello Vito,

I am afraid that providing the ability to define complex data fields in the dataSource's schema is not in our immediate plans.
If I understood correctly, the problem with 'from approach' is that the Grid sends back to server incorrectly formatted data. In such case you can use the parameterMap function of the transport which purpose is to convert the request parameters to a format suitable for the remote service.

For more information and code sample please check the corresponding documentation.

• http://docs.telerik.com/kendo-ui/api/framework/datasource#configuration-transport.parameterMap

Regards,
Alexander Valchev
Telerik

[Vito]

Alexander,

I appreciate you responding! Thank you for that information! I will try and apply it to my code.

If it doesn't work, I will reply, but it seems promising!!


Thank you for all of your help!