Best practices for DaDaBIK applications development, part 2/2
Hello everybody,
in the first part of this blog post (if you missed it, https://blog.dadabik.com/post/112 ) I discussed how important is a correct database design when you want to build a complex DaDaBIK application.
In this second part, I'll discuss other aspects you should consider during DaDaBIK apps development. I am a software developer with tens of years of experience but when I have to develop a typical enterprise application (business processes automation, dashboards/analytics, ..), I don't code it from scratch, I use DaDaBIK: typically I can finish the work in a fraction of time, avoiding repetitive tasks and focusing on the code that matters. That's why I think I can give some general advice to developers who are not expert low-coders yet.
Here are my suggestions.
- Avoid, unless it's really, really the only way, to modify the DaDaBIK core code to customize the layout of your applications. There are some PHP core files that you can, if you want, modify (for example /views/results_grid.php or /views/form.php). If you are a coder, it's tempting because a little modification on form.php can render the form exactly as you like. However, when a new version of DaDaBIK comes out and you want to upgrade, your modifications will be overwritten and you have to re-apply them, maybe to a slightly different code.
You can avoid that: not only the form configurator is now a quite complex tool that allows you to customize your forms in great details, but there are at least three other ways to impact on the DaDaBIK layout without editing the DaDaBIK core code:
- CSS: you can edit the styles_screen_custom.css file, a file dedicated to CSS customizations
- Layout hooks: you can write your own code (PHP, HTML, Javascript) that will be executed when a particular part of the layout is rendered; for example, the customers before edit form header hook - long name, I know :) - is executed before displaying the header of the customers edit form
- Datagrid templates: DaDaBIK, by default, creates standard reports: results grids representing the records you have in your table/view (or the results of a search). In case you want to represent your records using a different layout, you can optionally write your own HTML template.
Finally, if in your application you need a page that is very different from the classic DaDaBIK pages (forms, tabular grids, charts, …) , you should think about creating a custom page that, again, is not overwritten during a DaDaBIK upgrade. - CSS: you can edit the styles_screen_custom.css file, a file dedicated to CSS customizations
- VIEWS are very powerful, you should really learn how to use them. Views can be used in DaDaBIK to create pre-defined reports or filtered versions of a table (e.g. I can create a view italian_customers that shows only the customers whose country is "Italy" and add it to my main menu, just after the "standard" "Customers" menu item), but this is just the basic use. More in general, it often happens that you can overcome a DaDaBIK limitation using a VIEW, creating a "virtual" data structure that represents the information in the way that DaDaBIK expects.
Let me give you an example: let's say you have three tables:- products (id_product, name_prodcuts id_brand, price_product)
- brands (id_brand, name_brand, id_country)
- countries (id_country, name_country)
When you display your products, you might want to see the name of the corresponding brand: easy, you should just declare id_brand in products as a lookup field and "link" the table brands. But IF you want to see the country of the brand as well, you are stuck, the country's name is in the table countries and DaDaBIK doesn't find it.
The easy solution is the following: you create a brands2 view that joins brands and countries and use it as a source of your lookup field instead of brands. You kept your database normalized and, at the same time, you gave DaDaBIK what it wants.
DaDaBIK treats a VIEW exactly as it treats a table and don't forget that, despite what most of the people think, if your VIEW is updatable (see what it means for MySQL, for example: https://dev.mysql.com/doc/refman/8.0/en/view-updatability.html) you can also INSERT records in a VIEW (the records will be inserted in the underlying base table).
If you learn some basic SQL and how to create VIEWS, this can really make the difference if you need to create a complex applications and you can probably learn the basics in a couple of hours just by following my tutorials:
- Spend an appropriate amount of time thinking about your validation functions. As you know, with DaDaBIK, you can rely on built-in validation functions (e.g. if you declare a field as email, DaDaBIK checks if the value inserted is a valid email) but you can also add your own validation function, written in PHP. Weather you rely just on built-in validation or you use your custom validation function, the validation of your users' input is very important.
You might think that you have trusted, tech-savvy final users who won't add garbage to your database but in my experience this is ALWAYS a wrong assumption, at some point someone, by mistake or on purpose, will add some content that is not allowed and this can have an impact on your whole application. - Permissions: if you care about your data (and you should), when you grant permissions to your DaDaBIK users you must follow the Principle of least privilege (https://en.wikipedia.org/wiki/Principle_of_least_privilege) and give to each group only the permissions the users need to work.
With DaDaBIK it's easy to copy permissions from one group to another so, for example: if only Bob and Alice of the group Red need some additional privileges, don't add the privileges to the whole group, create another group Green, copy the privileges from Red to Green, add the additional privileges and move Bob and Alice to Green. - Audit/Revisions & logs are extremely useful, and they can help you manage critical situations. Even if you think to have planned everything well, in my experience at some point you might end up in situations where you don't understand why your data don't look as expected:
“how can this order be in APPROVED status if the corresponding product is not available? ”
If you have enabled Audit/revisions and logs, you can check the history of a particular record, see when the status has changed and who (or what) made the change. DaDaBIK, by default, tracks in the logs table only the Insert, Update, Delete operations executed using the standard, built-in, interface.
You can, however, log also your own custom operations! Let's say, for example, that you created a custom button "APPROVE" for the orders table, when a user clicks on it, the status of the order is changed and some other operations are executed. Inside your custom function, you can manually call the log_operation function using a specific label, e.g.
log_operation('approve_order', '');
this function call will create an entry in your logs table containing information about who and when approved the order, that, together with the Audit/Revision entries, can help you understanding what happened. - Row-level custom filters is another very powerful feature, in particular when you have to deal with Multi-tenant applications: let's say you want to use the same DaDaBIK application to serve several different organizations and you need each organization to see only its own data: you can add a field to your users table that defines the organization each user belongs to (e.g. id_organization), use this field also in all the tables you want to "partition" and then add a row-level custom filter that show, to each user, only the records belonging to their organization.
That's it, I hope this second part has been useful to you!
Best,
Eugenio Tacchini
DaDaBIK founder