Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

DataTables Template That Simplifies the Work

DZone 's Guide to

DataTables Template That Simplifies the Work

A flexible and understandable tool for configuring grids.

· Web Dev Zone ·
Free Resource

This article is dedicated to how nopCommerce, the most popular e-commerce platform on .Net Core, has switched to using the DataTables library on jQuery. With the help of a wrapper template for DataTablese, we tried to simplify for ourselves and third-party developers such a painstaking and tedious task as declaring the tables used in a project.

Why We Decided to Move Away From Kendo UI to DataTables

In nopCommerce up to the last 4.20 version we used quite popular UI framework by Telerik - Kendo UI. This client framework, based on jQuery, allows users to render visual controls such as tables, input fields, drop-down lists, etc.

IKendo UI is a powerful framework with a large community and thus a good support - what else is needed for successful use in an open-source project? But the tools in free open-source product should have the same features. After the Kendo UI 2014.1.318 version, Telerik developers decided to exclude their Grid from the free kernel  (https://github.com/telerik/kendo-ui-core).

Features Included by Telerik

Features included by Telerik


This forced us to use the build from 2014 up to 2019 without updates that would fix and improve this library. For the same reason, as the part of nopCommerce project, we had to support the outdated jQuery 1.10.2 assembly, while simultaneously supporting the latest build of this library. 

Clearly, this approach was not sustainable. Finally, we decided to leave the outdated grid in favor of something more universal that was open source and offered a high level of flexibility.

This tool turned out to be DataTables.

Why DataTables?

First of all, this tool is well-known to developers. It can be easily integrated and expanded. The grid is written in jQuery. Finally, it supports Bootstrap 3, which is used in nopCommerce and is distributed under open MIT license. 

Building the Template
After we decided on using the tool, we had some technical tasks to think about when implementing DataTables to nopCommerce project. 

The first thing we wanted to modernize was the very essence of building a grid on the View. While writing any view that should contain a table (a quite common situation in the administration panel), the developer needed to configure Kendo grid in the raw, as required by the documentation. So the code looked something like this:

<script>
     $(document).ready(function () {
         $("#activitylog-grid").kendoGrid({
             dataSource: {
                 type: "json",
                 transport: {
                     read: {
                         url: "@Html.Raw(Url.Action("ListActivityLog", "Customer"))",
                         type: "POST",
                         dataType: "json",
                         data: function() {
                             var data = {
                                 CustomerId: '@(Model.Id)'
                             };
                             addAntiForgeryToken(data);
                             return data;
                         }
                     }
                 },
                 schema: {
                     data: "Data",
                     total: "Total",
                     errors: "Errors"
                },
                 error: function(e) {
                     display_kendoui_grid_error(e);
                     // Cancel the changes
                    this.cancelChanges();
                 },
                 pageSize: @(Model.CustomerActivityLogSearchModel.PageSize),
                 serverPaging: true,
                 serverFiltering: true,
                 serverSorting: true
            },
             pageable: {
                 refresh: true,
                 pageSizes: [@(Model.CustomerActivityLogSearchModel.AvailablePageSizes)],
                 @await Html.PartialAsync("_GridPagerMessages")
             },
             editable: {
                 confirmation: "@T("Admin.Common.DeleteConfirmation")",
                 mode: "inline"
            },
             scrollable: false,
             columns: [{
                 field: "ActivityLogTypeName",
                 title: "@T("Admin.Customers.Customers.ActivityLog.ActivityLogType")",
                 width: 300,
             }, {
                 field: "IpAddress",
                 title: "@T("Admin.Customers.Customers.ActivityLog.IpAddress")",
                 width: 100
            }, {
                 field: "Comment",
                 title: "@T("Admin.Customers.Customers.ActivityLog.Comment")"
            }, {
                 field: "CreatedOn",
                 title: "@T("Admin.Customers.Customers.ActivityLog.CreatedOn")",
                 width: 200,
                 type: "date",
                 format: "{0:G}"
             }]
         });
     });
 </script>



This became bulky quickly, especially considering that this example was one of the simplest tables in the project. We constantly had to look in the documentation to check what each setting was responsible for and to understand what to use in a given situation. Therefore, we decided to implement the grid-building template in such a way that a developer would not have to read documentation and other descriptions and could simply write the code on С# instead.

In this form, the same table looks much more compact and clear:

@await Html.PartialAsync("Table", new DataTablesModel
 {
     Name = "activitylog-grid",
     UrlRead = new DataUrl("ListActivityLog", "Customer", new RouteValueDictionary { [nameof(Model.CustomerActivityLogSearchModel.CustomerId)] = Model.CustomerActivityLogSearchModel.CustomerId }),
     Length = Model.CustomerActivityLogSearchModel.PageSize,
     LengthMenu = Model.CustomerActivityLogSearchModel.AvailablePageSizes,
     ColumnCollection = new List<ColumnProperty>
     {
         new ColumnProperty(nameof(CustomerActivityLogModel.ActivityLogTypeName))
         {
             Title = T("Admin.Customers.Customers.ActivityLog.ActivityLogType").Text,
             Width = "300"
        },
         new ColumnProperty(nameof(CustomerActivityLogModel.IpAddress))
         {
             Title = T("Admin.Customers.Customers.ActivityLog.IpAddress").Text,
             Width = "100"
        },
         new ColumnProperty(nameof(CustomerActivityLogModel.Comment))
         {
             Title = T("Admin.Customers.Customers.ActivityLog.Comment").Text
         },
         new ColumnProperty(nameof(CustomerActivityLogModel.CreatedOn))
         {
             Title = T("Admin.Customers.Customers.ActivityLog.CreatedOn").Text,
             Width = "200",
             Render = new RenderDate()
         }
     }
 })


All this is done directly on the View, and of course, after rendering the page, it transforms into expanded View. But the beauty of this approach is that you don’t have to describe each table from scratch. You just need to configure the single template that sets a clear framework of available functions. 

The scheme below demonstrates the main template’s features that the developer can use at the moment.

Main template features



Main Features

  • Filter parameters - filtering the data displayed in the table, is superimposed on the Data source.

Table-Setting Features

  • Data source - the data source can be either an array or a generated JSON. Additionally, it can be loaded from the server via an AJAX request.

  • Inline edit - it’s not a secret that out-of-the-box DataTables does not provide editing functionality directly in the table row (in the free version). We added this functionality in our template so it would be really convenient to use it.

  • Localization - we also made sure that users could customize the localization of their tables

  • Service buttons - in addition to the standard View, Edit and Delete buttons, for working with data in the row, the template allows to add user’s own custom buttons for any functionality the developer may need. For example, the Grid update button is now implemented according to this principle.

  • View/Style - the template has built-in functionality to customize the appearance of each table individually. For example, you can disable the pager if you know for sure that the data in the table will be only a couple of rows or set the way to display the preliminary totals in the table footer.

  • Paging - you can not only determine the number of elements displayed on the page, but also change the style of pager itself (e.g. by removing the Forward/Back navigation buttons and leaving only the numeric page number).

  • Hierarchical - nopCommerce uses the tables of the Parent-Child type, which means that the tables can be nested in each other. Therefore, in the template, we have implemented the possibility of recursive inheritance of tables of any nesting. Even in this matter, we tried to provide developers with the possibility of complete customization.

Column-Setting Level

  • Size - it is possible to set the size of the column using CSS styles, i.e. in pixels (px), percent (%), etc.

  • Visible - columns can be excluded from visibility programmatically if required by the task.

  • Data - for inline editing, the following data types are supported:

    • number

    • boolean

    • string

Individualized Styling

  • Render styling - to visualize various kinds of information in the columns, special templates can be used to render the source data, or service data if it comes to rendering buttons. The template is able to render links, pictures, calendar dates, and custom buttons with specified functions above the data in the row. But if this functionality is not enough, and you need to display something specific - it’s not a problem. For this we have implemented custom render, which can be programmed as you need, using all the features of JavaScript.

Further Plans and Developing This Idea

After implementing the template, we got rid of the need to keep an outdated version of Kendo UI and jQuery 1.10.2 library in the project. 

In the next version, we plan on updating Kendo UI to the latest version and removing all unnecessary libraries. As for the template itself, there are plans to further simplify the grid configuration notation. Perhaps new functions will be added such as contextual search on the selected column, the ability to dynamically sort the data, etc.

Conclusion

Starting from nopCommerce 4.20 version, a convenient tool for configuring grids of any complexity has appeared. Our main task was to provide third-party developers with a flexible and understandable tool that would not require studying a new library or technology. Of course, not all the functions available in DataTables are supported in our solution, but everything you need is there. For enthusiasts, it is always possible to expand the template, thereby participating in the development of nopCommerce.


Topics:
c# ,web dev ,kendo ui ,datatables ,javascript and jquery ,tutorial

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}