Sprachvariablen für allgemeine Pakete richtig anlegen

Profile of "Teralios"

Dear visitor, welcome to WoltLab Community Forum. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Teralios

Member
- "Teralios" is male
- Register now!
You have to register first, to connect to this user.

Rating:

by Teralios, Tuesday, August 25th 2009, 3:14pm

Durch den Fehler „Nutzungsbestimmungen in den verschiedenen EAs“ ist mir etwas aufgefallen, was doch zumindest für die Entwickler unter euch sehr interessant sein dürfte.

Hier steckte weniger ein Logikfehler dahinter, als einfach eine Unachtsamkeit. Sprachvariablen werden aktuell für eine Endanwendung und nicht für ein Paket gespeichert, braucht man diese nun in einer anderen Endanwendung, müssen diese erneut erstellt werden. So ein Schönheitsfehler ist aber bei Paketen wie Nutzungsbestimmungen oder auch bei der Hilfe nicht gerade gewünscht.

Die Lösung hinter diesem Problem ist aber relativ einfach. Dem LanguageEditor wird in der Methode updateItems die packageID des Paketes übergeben. Dafür besitzt das WCF die Methode getPackageID.

Folgender Code zeigt, wie es gemacht wird.

	PHP Source code
1 2 3	$language = new LanguageEditor($languageID); $language->updateItems(array('wcf.test.test' => $name), 0, WCF::getPackageID('paket'));

Jetzt besteht nur noch das Problem, dass wir die Sprache der einzelnen Endanwendungen aktualisieren müssen, da reicht ein Aufruf der Funktionen deleteLanguageFiles und deleteCompiledTemplates , mit der entsprechenden languageID und der Kategorie.

	PHP Source code
1 2	LanguageEditor::deleteLanguageFiles($languageID, 'wcf.test'); LanguageEditor::deleteCompiledTemplates();

Zusammen sieht es nun so aus:

PHP Source code

$language = new LanguageEditor($languageID);
$language->updateItems(array('wcf.test.test' => $name), 0,
WCF::getPackageID('paket'));
LanguageEditor::deleteLanguageFiles($languageID, 'wcf.test');
LanguageEditor::deleteCompiledTemplates();

Man sollte dabei beachten, dass diese Art der Speicherung von Sprachvariablen nur in einem einzigartigen WCF-Paket erfolgen sollte, da es sonst zu anderen Fehlern kommen könnte.

Nutzungsbestimmungen in den verschiedenen EAs

This article has been read 2,971 times.

Categories: Community Framework, Tipps und Tricks

Go to the top of the page

Comments (5)

5

by Tr3kk3r (Sunday, February 27th 2011, 10:48pm)

deleteCompiledtemplates() ist keine statische Funtion, richtig wäre statt LanguageEditor::deleteCompiledTemplates(); folgendes zu nutzen: $language->deleteCompiledTemplates(); , sonst gibt es einen netten Fatal Error, wenn man sich an die Strict Standard hält: "Strict Standards: Non-static method LanguageEditor::deleteCompiledTemplates() should not be called statically in XXX"
4

by GameR (Friday, September 4th 2009, 4:06pm)

Ufdada, ich glaub ich kann schon erwarten, dass ihr euch auch mal die Methoden anschaut. In dem Fall steht aber Paket für den Paketbezeichner, und wcf.test für eine Sprachkategorie.
3

by ufdada (Tuesday, September 1st 2009, 12:57pm)

Könntest du die Beispielnamen vielleicht etwas genauer beschreiben? Es geht nämlich leider nicht hervor ob wcf.test.test nun ein Paketbezeichner oder die Sprachvariable ist (ich geh von zweiterem aus). Zudem Frage ich mich für was paket steht: Für den Paketbezeichner oder für den Namen?

Beim LE::dLF wird wcf.test wohl die Sprachkategorie sein, deren Variablen gelöscht werden sollen.

Ansonsten muss ich sagen gut zu wissen
2

by GameR (Wednesday, August 26th 2009, 9:28am)

Nein, sowas brauchst du aber z.B. bei der Hilfe wenn die Hilfe für mehre Sprachen da sein soll.

In den Nutzungsbestimmungen war es so, dass die Sprachvariabeln, die ja dynmaisch angelegt werden, immer nur für die Endanwendung angelegt wurden, damit waren sie in anderen EAs nicht verfügbar, mit dem "Trick", kann man das aber umgehen.
1

by Toby (Tuesday, August 25th 2009, 9:25pm)

Das wäre dann in einem Postinstallscript drin, oder?