nicht angemeldet
Rolf bWenn Du Code generierst, ist es im Prinzip egal wieviele Klassen Du hast. Du instanziierst sie ja hoffentlich nicht zu Fuß, sondern über eine Factory - und wenn Du der sowas sagst wie
interface MessageProvider {
public function provideStrings($topic);
}
$mp = MessageFactory::GetMessages("de");
$i18nStrings = $mp->provideStrings($topic);
Dann kann es Dir im Code total wurscht sein, ob die MessageFactory einen DatabaseMessageProvider erzeugt (der eine Table liest), einen XmlFileMessageProvider (der XML importiert) oder einen DeMessageProvider (der die Texte konstant enthält). All das sind valide Implementierungen, und je nach Implementierung stellst Du deine Strings anders bereit.
Wichtig finde ich nur, dass deine provideStrings-Methode einen Parameter hat, mit dem Du Ressourcen zu einem bestimmten Oberbegriff abrufen kannst. Es wäre sicherlich Zeitverschwendung, immer alle deutschen Texte für alle HTML Seiten deines Projekts zu laden. Und du kapselst damit die technische Abbildung deiner Ressourcen. Warum soll dein Code wissen, ob "formular.error.categories" und "test" in der gleichen Ressourcendatei liegen. Sag dem Provider, dass Du diese Ressource willst, und der soll sich drum kümmern, in welcher Datei er gucken muss. Ob er das zur Laufzeit entdeckt, oder dein Generator es ihm einspeichert - das ist ein Implementierungsdetail. Möglicherweise wirft das nun deinen bestehenden Code durcheinander, weil der eine Array-Hierarchie erwartet, da könntest Du Dir einmal das ArrayAccess Interface anschauen, um die Ressourcen-Arrays hinter einem Objekt zu verstecken.
Eine DB-gestützte Ressourcenhaltung ist - finde ich - als Entwicklungsplattform gar nicht verkehrt, vor allem nicht, wenn Du sie schon hast und damit zurecht kommst. Wenn Du da umsteigen willst - nagut, da gibt es viele Möglichkeiten, wie man das designen kann, und ich würde an deiner Stelle dann nach einem Standardtool für das Management von internationalisierten Ressourcen suchen.
Verkehrt wäre nur, wenn Live-System und Entwicklungsungebung auf die gleiche Datenbasis zugreifen, da muss auf jeden Fall ein Deployment-Schritt dazwischen sein. Dieser Deployment-Schritt konvertiert dann auch nach Bedarf das Datenformat der Entwicklungsumgebung für die Produktivumgebung.
Das kann das Kopieren in eine andere DB sein, das kann das Generieren von PHP Klasssen sein, oder das Generieren von XML-Dateien. Muss auch nicht XML sein - es gibt andere Formate, die ggf. effizienter sind, z.B. kannst Du das Array für eine Sprache (oder ein Topic in einer Sprache) erzeugen, serialisieren und den serialisierten String als Datei speichern. Die heißt dann messages.de oder bestellform_messages.de oder messages/de/bestellform.res, da kannst Du Dich austoben.
Du kannst es auch so machen, dass Du in der Entwicklungsumgebung mit einem DatabaseMessageProvider arbeitest, der direkt auf die Texttabellen deines Ressourcenpflegesystems zugreift, und im Produktivsystem nutzt Du einen anderen MessageProvider, der auf die Produktionsversion der Ressourcen zugreift - in welchem Format auch immer.
Wenn es nicht zu viele Texte sind, spricht nichts gegen generierte Klassen. Bei einer größeren Webseite würde ich die Ressourcen schon in Topics aufteilen und nur die Texte für dieses Topic laden.
Nun ja. Das war jetzt ein rolf.brain.dump(). Vielleicht ist was für Dich dabei :)
Rolf