Ein weiterer Schritt in Richtung Offenlegung ist meine Darstellung zum objektorientierten Aufbau der Response-Seiten in meinem Framework:
http://rolfrost.de/fwcmsbodies.html

Herzstück der Datenhaltung ist ein Data-Abstraction-Layer für persistent Objects:
http://rolfrost.de/dal.html

mit einem speziellen Unterpunkt zum ORM, welches in diesem DAL auf einer nicht normalisierten Tabelle in MySQL basiert: Relationen werden mit einem Self-Join sozusagen rekonstruiert, was gezielte SQL-Statements ermöglicht, die sehr performant sind. Das Mapping heißt in diesem Fall, dass Attribute auf Alias-Felder/Alias-Tabellen gemappt werden und umgekehrt.

DAL heißt auch, dass die Datenfelder nicht MySQL bestimmt, sondern als Attribute in der jeweiligen Anwendung bestimmt werden, ggf. sogar in JavaScript. Also aufwändiges DB-Design nur noch in Spezialfällen, wo eine stärkere Bindung ans RDBMS gefordert ist (z.B. Buchhaltung, Faktura).

Und das alles ist in Perl, abwärtskompatibel zu 5.6.1

Von wegen, Perl ist unmodern. Unmodern sind höchstens Browser, die mit modernen JavaScript nicht klarkommen, das hier z.B. http://rolfrost.de/office_cms.html funktioniert nur mit modernen Browsern. Wobei es jedoch möglich wäre, dass auch mit bestimmten Einschränkungen im IE zu Laufen zu bringen, es betrifft jedoch nur die Browser-Backends fürs CMS.

Fürs Content-Management habe ich auch Webservices und Kommandozeilen-Clients in Perl, da ist der Editor nicht der Browser, sondern ein Editor wie Komodo oder TextPad und das Publizieren erfolgt per Shortcut (Click & Go).

Machbar ist alles. Einen Grund dafür, Perl in der Webentwicklung durch irgendwas Anderes zu ersetzen, kann nicht in Perl an sich liegen.