Pragmatic Choices – Web Application Development with WordPress and CMB2 #2

When you choose to use some kind of component you are accepting that even though this component may not be perfect, considering all the pros and cons, it’s still a better solution (in time, cost, etc.) than developing your own solution from scratch. This also means that sometimes you end up doing things that feel kind of strange, when you compare to what you would do if you were starting with a “blank sheet” of code.

How far you can stretch that strangeness usually depends on how pragmatic your programmer can be. Is he the type of guy that really just wants to get things done, even if it means you end up with some kind of technical debt or is he the kind guy that would rather work extra-time to make that code really clean, beautiful and also effective?

In our time tracking application we have, for now, 2 main dependencies, WordPress and CMB2, and we’re trying to make the most of them. This means that we’re trying to use all the functionalities they give us and also implement some requirements in a way that makes the most sense for those components.

In our 2nd week of development we’ve ran into a situation that, I think, represents this kind of choice and that has to do with Roles and Capabilities.


One of the goals of our time entry application is to register on what projects / subjects our consultants worked during the day. So we have something like consultant, subject, client, date, worktime, and so on. Relevant to this issue we also have the concept of teams and team lead. A simple consultant can only register something that he did but team leaders can register entries on behalf of their team members. On our roadmap is also the idea of logging changes in records, that is register who made some change to a specific record.

There were some options to solve this. One would be to simply use post_author to record who was registering the time entry. This solution would have the added benefit of allowing the use of the WordPress capabilities and reduce the number of tables we would have to include to filter tasks by consultants, we could simply use wp_quer. But since team leaders can also register on behalf of their team members and also because we wanted to keep track of who made the changes this wasn’t possible.

The other solution would be to simply ignore post_author and create 2 post metas, one to save the user that was recording the time entry and the other to register the consultant associated with the time entry. This would be a totally viable option, and since we’re building an application to track tasks and times and we’re not really doing anything with posts there was no reason to consider fields like post_author. This option would however make some queries a bit more complex and probably more cpu intensive since we would have to include not only the posts table but also post_meta with its “infinite” number of records.

Since, after data entry, data selection and filtering is a huge part of our application, and having to reimplement all of this requirements didn’t seemed to make sense to us, we chose to use an hybrid solution and so we ended up using post_author to record the consultant associated with this time entry and we’ve created a post_meta to save the user that registered this entry. Best of both worlds? We will see, but in the meantime if you think we could have done differently feel free to tell us.








Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *