Genau! Die Business-Logik im Template zu platzieren ist grober Unfug. Einem Template können wir allenfalls ein paar einfache Kontrollstrukturen zubilligen und das geben die meisten Template-Engines her.

Andererseits ist doch der Programmablauf vom Request bis zur Response immer wieder derselbe. Nichts liegt also näher, als in der main ein Interface zu bauen, wobei sich Verzweigungen doch erst dann ergeben, wenn Benutzereingaben zu verarbeiten sind: Da wäre im Interface nur zu prüfen, ob überhaupt Request-Parameter vorhanden sind und die daran gehängte Logik wird komplett und im Detail bspw. als Parameter-Kontrollstruktur in eine der Response entsprechende Subklasse ausgelagert.

Sämtliche Platzhalter fürs spätere Template-Rendering liegen als Referenz fein säuberlich als Attribut in der Instanz derjenigen Subklasse, die zum Ausliefern einer Response zuständig ist. Hiermit hätten wir auch die Möglichkeit, dynamische Inhalte in eine Seite einbauen zu können auch dann, wenn keine Parameter im Request sind. Und wenn die Seite überhaupt keine Platzhalter hat, setzen wir einfach ein Attribut in die Website-Konfiguration, womit das Rendern übergangen wird.

Also, ich denke auch, EmbPerl, gute Idee, aber mit einer anderen Herangehensweise (Interface) ist das komplett überflüssig.