Identifying Data table

CRUD is one of the most core features used in applications, particularly in the back-end administration areas. However, it can be extended, using the Data table extension, in ways which are not immediately obvious. It is the purpose of this article to help you identify not only the standard ways that Data table could be used, but also the non-standard not-quite-so-obvious ways.

About Data table.

If you haven’t already, make sure you are familiar with the basics of the extension by reading the Data table Extension Overview article, focusing on the section at the top where it covers what it is and is not suitable for. For an example of it in action, explore the back-end of one of your codebots-built applications. A large portion is made up of CRUD, as every entity used in the application has a Data table representing it for administrative purposes.

As Data table has a multitude of views, it is quite a versatile extension that can be used for a great number of purposes. The first step in being able to identify the Data table extension is to be familiar with its core views: create, read, update, and delete. Once you are familiar with those four, it becomes far more simple. For each view, there is a different way of identifying it.

Identifying a potential Data table

In its basic form, CRUD can be found anywhere there is a list of data, a create view, or a screen where you can edit the details of an entry. Pretty self-explanatory. When it comes to getting a bit more creative, you need to start looking at things in a bit more abstract manner.

For example, consider a “list” of images being displayed in a gallery-like manner on a page. While it is not a traditional list in the CRUD sense, it is still the displaying of a selected group of data in an order. You may even have some sorting or filtering available. This scenario would require some custom code of course, the images won’t be displaying by default, but using Data table means you can use the sorting and filtering features without having to implement them from scratch.

Rather than just taking the interface at face value, consider what sort of data processing is going to be happening in the background. Is a new entry going to be created against an entity, maybe multiple entities? Are you viewing or editing existing data using a form like interface?

It should be noted that when it comes to collecting data, there is a fine line between when a CRUD edit view should be used, and when a form should be used. For more information on this, please read the Identifying Forms article, where the problem and possible solutions are laid out in full.

Examples of Data table

New Patient Form (Create View)

When you go to a new doctor or dentist, you always need to fill out a “New Patient” form, and this data always gets put into the clinic’s database (whether it is you doing it yourself on a tablet, or one of the staff doing it on their computer). This is a prime example of what a CRUD create view could be used to achieve, as it presents all of the available fields which can be filled out.

From there, the doctor could use the read view to view your details, and if you ever wanted to change your address, the staff could open up your entry and use an edit view to update your details.

Bucket List

Kind of a give-away since the word list is in the title, but a bucket list is a prime example of CRUD. You would have a list of activities which you may want to sort by order or type, you can add or delete activities, or you can edit them to mark them as complete.

Phone Contacts

The contacts stored on your phone make use of all of the primary features of CRUD. You can create a new contact, view it’s details, update the information, or delete it from the list.