nicht angemeldet
Wovon sprichst du bitte?
Der Ansatz der in dem Link besprochen wird, ist soetwas von nicht Objektorientiert und eignet sich für eine Sprache für Java imho (zumindest nach guten Stil) sowas von überhaupt nicht.
Objektorientierung ist überbewertet, die Motwendigkeit wird meistens von Menschen angekreidet, die sie nicht verstanden haben.
Ob du diesen Ansatz nur als Prozedur verwendest oder in eine Klasse verpackst ist völlig egal - das sind ein paar zweile extra Code.
Dann kannst du meinetwegen auch einen Setter einbauen, der die Sprache einmalig konfiguriert und du nächstes mal nur rausklauben musst.
Nach dem müsste ich ja in jeder UI diese Arrays definieren und wenn ich dann ne Sprache hinzufügen möchte, na Prost Malzeit :D
Ja - das ist genau der Sinn der Sache, die Sprachroutine merged dann alle Arrays zu beginn und die Sache ist erledigt. Nur so ist eine Modulare Verwaltung der Sprachen und Pakete überhaupt möglich.
Alternativ könnte man natürlich ne Statische Klasse schreiben, wo die Arrays Drin liegen und nen Zugriff a la Sprache.HashMap.get("titel"); machen, schön ist was anderes!
Warum liegen die Arrays nicht in externen Konfigurationsfiles und werden durch die Klasse nur gelesen? Wer sagt denn, dass die Sprachkonfiguration hardcodiert sein muss?
Außerdem sollen Sprachen hinzufügbar sein, dass heißt, die Daten müssen außerhalb des eigentlichen Programmes (z.B. als Datenbank oder xml-file) liegen.
XML, CSV, ein Array - völlig egal - du wirst es nicht für möglich halten, aber TYPO3 vervolgt exakt den ansatz, den ich beschrieben habe.
Die Klasse heisst tslib_fe - die nötigen Funktionen sind ab Zeile 4736 zu finden.
Also nichts Bullshit, sondern doch durchaus was dabei gedacht :)
Ja, aber nicht sehr weit :)