{ "uuid": [ { "value": "25833838-38b9-414d-bca6-de0bf5c2ac28" } ], "langcode": [ { "value": "en" } ], "type": [ { "target_id": "daily_email", "target_type": "node_type", "target_uuid": "8bde1f2f-eef9-4f2d-ae9c-96921f8193d7" } ], "revision_timestamp": [ { "value": "2025-05-11T09:00:22+00:00" } ], "revision_uid": [ { "target_type": "user", "target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849" } ], "revision_log": [], "status": [ { "value": true } ], "uid": [ { "target_type": "user", "target_uuid": "b8966985-d4b2-42a7-a319-2e94ccfbb849" } ], "title": [ { "value": "Don't put business logic in templates" } ], "created": [ { "value": "2024-01-10T00:00:00+00:00" } ], "changed": [ { "value": "2025-05-11T09:00:22+00:00" } ], "promote": [ { "value": false } ], "sticky": [ { "value": false } ], "default_langcode": [ { "value": true } ], "revision_translation_affected": [ { "value": true } ], "path": [ { "alias": "\/daily\/2024\/01\/10\/dont-put-business-logic-in-templates", "langcode": "en" } ], "body": [ { "value": "\n

Here is some code from my website:<\/p>\n\n

\"A<\/p>\n\n

If you want, you can also view it on GitHub<\/a>.<\/p>\n\n

It is business logic responsible for counting the number of talks I've given at different events so I can display it on my Talks page.<\/p>\n\n

It starts at zero, loops over each talk, and increments the talk count if the event is the current day or a past date.<\/p>\n\n

It's only used in a single place, so the same logic isn't duplicated elsewhere.<\/p>\n\n

But it's in the page's Twig template.<\/p>\n\n

It has no test coverage.<\/p>\n\n

If I need to change or refactor it, I'd need to test it again manually.<\/p>\n\n

Don't do this.<\/p>\n\n

So, what should I do?<\/h2>\n\n

It's OK to put simple presentational logic, such as looping over a list or whether to show or hide a value within a template, but not complex business logic.<\/p>\n\n

Business logic should be separated and executed elsewhere. The values should be passed to the template to be rendered.<\/p>\n\n

This makes the business logic easier to test as you can test the logic itself and determine the value passed to the template is correct without being concerned about the templating engine.<\/p>\n\n

In an application, you may need to output a value to a template and a terminal. You'd have one source of truth, such as a Service, Action or Command class that calculates the value before passing it to the appropriate output.<\/p>\n\n

Once the logic is separated, you only need to test it once.<\/p>\n\n

Here's the thing<\/h2>\n\n

In a previous version of my website, I did this by creating a custom Twig function.<\/p>\n\n

It was as simple as adding <\/code> to the template.<\/p>\n\n

All the logic was moved from the template to my custom extension.<\/p>\n\n

The logic was separated.<\/p>\n\n

It had tests.<\/p>\n\n

This is the approach I'd take to achieve the same result for a client application.<\/p>\n\n

For a client, I want to run a test suite and be confident my logic works as expected - now and in the future.<\/p>\n\n

For myself, and for calculating something simple, this is fine.<\/p>\n\n ", "format": "full_html", "processed": "\n

Here is some code from my website:<\/p>\n\n

\"A<\/p>\n\n

If you want, you can also view it on GitHub<\/a>.<\/p>\n\n

It is business logic responsible for counting the number of talks I've given at different events so I can display it on my Talks page.<\/p>\n\n

It starts at zero, loops over each talk, and increments the talk count if the event is the current day or a past date.<\/p>\n\n

It's only used in a single place, so the same logic isn't duplicated elsewhere.<\/p>\n\n

But it's in the page's Twig template.<\/p>\n\n

It has no test coverage.<\/p>\n\n

If I need to change or refactor it, I'd need to test it again manually.<\/p>\n\n

Don't do this.<\/p>\n\n

So, what should I do?<\/h2>\n\n

It's OK to put simple presentational logic, such as looping over a list or whether to show or hide a value within a template, but not complex business logic.<\/p>\n\n

Business logic should be separated and executed elsewhere. The values should be passed to the template to be rendered.<\/p>\n\n

This makes the business logic easier to test as you can test the logic itself and determine the value passed to the template is correct without being concerned about the templating engine.<\/p>\n\n

In an application, you may need to output a value to a template and a terminal. You'd have one source of truth, such as a Service, Action or Command class that calculates the value before passing it to the appropriate output.<\/p>\n\n

Once the logic is separated, you only need to test it once.<\/p>\n\n

Here's the thing<\/h2>\n\n

In a previous version of my website, I did this by creating a custom Twig function.<\/p>\n\n

It was as simple as adding <\/code> to the template.<\/p>\n\n

All the logic was moved from the template to my custom extension.<\/p>\n\n

The logic was separated.<\/p>\n\n

It had tests.<\/p>\n\n

This is the approach I'd take to achieve the same result for a client application.<\/p>\n\n

For a client, I want to run a test suite and be confident my logic works as expected - now and in the future.<\/p>\n\n

For myself, and for calculating something simple, this is fine.<\/p>\n\n ", "summary": null } ] }