Template Method in Laravel: One Algorithm for Different Content Blocks

After the Page Builder in ICanUp gained Hero, CTA, Highlight, Cards, Steps, and FAQ, another kind of duplication became visible.

Those blocks have different content, configuration fields, and variants. But their overall structure is the same: build default data, validate content and configuration separately, require a variant, and produce correctly prefixed validation attributes.

Copying that skeleton into every definition would create several almost identical implementations that could slowly drift apart.

That is where Template Method appeared naturally in the code.

This is an important sign of Template Method. I did not try to make Hero and Cards identical. They remain different.

What is shared is the algorithm used to build the contract. The base class fixes that order while subclasses provide the variable parts.

These three public methods are the template methods.

defaultData() always returns the same top-level shape.

rules() always adds structural rules, prefixes concrete rules, and validates the variant.

attributes() always builds labels using the same process.

A concrete block cannot accidentally replace that skeleton because those methods are final.

The base class knows when defaults, rules, variants, and attributes are needed, but it does not know what exactly they are.

That is the inversion inside Template Method: the algorithm belongs to the parent class while selected steps are supplied by concrete implementations.

Hero can contain a title, text, and buttons. Steps contains a title, introduction, and items. Cards has an even more complex structure.

But the editor and backend always receive the same top-level contract: content plus configuration.

A concrete definition does not need to remember that wrapper. It returns only its own pieces.

Hero does not implement defaultData(). It does not build prefixes and does not add the common variant validation.

It knows only its own part: which fields belong to Hero, what their defaults are, and which rules they require.

When the parent calls those hooks, the concrete values automatically become part of the shared algorithm.

The subclass does not control the order of this method.

The parent always requires two arrays, always prefixes content rules, always prefixes configuration rules, and always validates the variant against variants().

The subclass controls only the values placed into those slots.

Small details like this often create divergence after copy-paste.

One definition might return alignment, another might return configuration.alignment, while a third prefixes rules and attributes differently.

The base class owns structural knowledge so concrete definitions can work with local field names.

abstract tells a subclass: you must provide this step.

final tells a subclass: you must not replace this algorithm.

Without final, one presentation block could override rules() and forget the common configuration.variant, while another could return defaults in a different structure.

Template Method is useful when part of the flow needs to remain stable.

Steps does not look like Hero in terms of content shape. It has an items array and completely different validation rules.

But the presentation contract is the same, so the parent algorithm remains useful.

This is a useful criterion for inheritance: subclasses do not need identical data, but they should genuinely follow the same algorithm skeleton.

This is one of the most important parts of the case.

Regular Code, Image, Notice, and other blocks can implement ContentBlockDefinitionInterface directly. Even FormBlockDefinition implements the presentation interface without extending AbstractPresentationBlockDefinition because its data contract is different.

I do not force every definition through one parent. Template Method is useful only for a family of classes that genuinely shares one flow.

1. Create a concrete definition extending AbstractPresentationBlockDefinition when the block fits this contract.
2. Provide its own contentRules() and configurationRules().
3. Define variants() and editor options.
4. Provide defaultContent() and defaultConfiguration().
5. Provide localized content/configuration attributes.
6. Add its DTO through makeData().
7. Register the definition in the Content Block registry.

There is no need to reimplement the defaults wrapper, validation-rule prefixing, or the common variant rule.

Template Method couples subclasses to an inheritance hierarchy. That is a stronger relationship than an interface with composition.

Changing the final algorithm affects every subclass, so the base class should stay small and stable.

It is also a bad sign when the base class accumulates dozens of protected hooks because one block needs an exception. Composition is often cleaner in that situation.

In ICanUp, AbstractPresentationBlockDefinition does not try to understand what Hero, Cards, or FAQ mean.

It knows only the stable algorithm: how defaults are assembled, how validation rules are built, and how attributes are produced.

Concrete definitions provide the variable steps. final methods prevent them from accidentally breaking the structural contract.

That is a practical Template Method to me: inheritance is not used to reuse arbitrary code, but to fix one algorithm skeleton with explicit extension points.