Archive note
Configurable text filters and the case for point and click
An introduction to the idea behind Flexifilter: let site builders define text transformations in the interface instead of in code.
Text filters are the quiet machinery of a content system. They turn line breaks into paragraphs, bare addresses into links, and repeated patterns into structured markup. Most of the time they run without anyone thinking about them, which is the point.
The problem with hard coded filters
A filter written in code is precise and fast. It is also fixed. Changing the pattern means finding the person who can edit the module, waiting for a release, and hoping the change does not break something else. For a site builder with a small variation, that is a lot of ceremony.
Flexifilter explored a different trade off: let the site builder describe the transformation in the interface. Pick a pattern, pick an action, order the steps, and save. The result is a filter that can be adjusted without a deployment.
What a good filter interface asks for
- A name that describes the outcome, not the mechanism.
- A pattern that is easy to test with a sample.
- A clear order of operations.
- A safe preview before the filter is enabled.
The preview is not a luxury. Text transformations are hard to reason about in the abstract, and a filter that looks correct can mangle a page. Showing the before and after on real content is the simplest form of quality control.
Know when to write code
Interface driven filters are excellent for local conventions: a house style for notes, a repeated callout, a link pattern used by one team. They are a poor fit for complex parsing, performance critical work, or rules that need careful unit tests.
The useful question is not "can this be configured" but "who will maintain it". If the answer is a site builder who understands the content, configuration is a gift. If the answer is a developer who will need to debug it at midnight, code with tests is kinder.
A configuration screen is a user interface like any other. It deserves plain labels, sensible defaults, and a way to undo a mistake.
Why this matters beyond one module
Every feature that moves a decision from code to interface changes the balance of power in a project. It gives more people the ability to shape the result, and it asks the tool to explain itself. That is a healthy pressure. It forces the underlying model to become clear enough to present.
The Flexifilter project is one expression of that idea. The lesson is broader: when a repeated decision is well understood, it can often be handed to the people closest to the content.