ilch Forum » Ilch Clan 1.1 » Kritik und Verbesserungen » Sprachen Klasse

Geschlossen
  1. Di. 30.03.2010 23:09 Uhr #1
    User Pic
    Cartment Mitglied
    Registriert seit
    14.02.2007
    Beiträge
    372
    Beitragswertungen
    0 Beitragspunkte
    Ich hab mir mal die Mühe gemacht und eine wirklich kleine Klasse
    geschrieben, mit hilfe der man kinderleicht seine Sprachvariabeln
    abrufen kann.

    Vorteil:
    Der Speicher für das bisherige Sprach Array würde vollständig entfallen.
    Es kann via select zu eienr belibigen Sprache gewechselt werden.
    Es können variable Ersetzungen gesetzt werden.
    Bsp:
    Hallo %username%.
    Deine Registrierung vom %regist% wird in den nächsten %days% Tage/n freigeschaltet
    Alle Entwickler können diese belibig ergänzen ohne andere zu ersetzen
    Bessere Sprach Kompatiblität

    Ich denke das wäre etwas für die 1.2 er Version.
    Da man das ganze relativ leicht in das existierende System ergeänzen kann.


    Codebeispiel: 

    $lang = new language();

$id = $lang->select(\'de\');
print $id; // ID der gewählten Sprache

$login = $lang->get(\'user_login_successful\', array(\'username\'=>\'Peter\') );
print $login; // Inhalt der Sprachvariable, samt der Ersetzung


    Paket:
    externer Link

    verwendete ilchClan Version: 1.1


    Zuletzt modifiziert von Cartment am 30.03.2010 - 23:15:23
    0 Mitglieder finden den Beitrag gut.
  2. Di. 30.03.2010 23:44 Uhr #2
    User Pic
    Mairu Coder
    Registriert seit
    16.06.2006
    Beiträge
    15.334
    Beitragswertungen
    386 Beitragspunkte
    Also nicht gegen Klassen, die sicher besser sind, aber die von dir genannten Vorteile treffen irgendwie nicht zu, eine Klasse braucht auf jeden Fall mehr Speicher als ein bloßes array, es sei denn du hälst die Daten nicht vor, was dann aber zu mehr Lesezugriffen führen würde und insgesamt langsamer wäre.
    Das Spracharray kann man auch einfach in eine andere Sprache ändern.
    Und das mit dem Sätzen wird ja ähnlich schon gemacht, ist aber wohl der einzige Vorteil, eine Klasse ist aber ordentlich eingesetzt, sicher besser als Array, nicht dass ich jetzt falsch verstanden werde zunge
    Und auch immer mal ein Blick auf die FAQ werfen. | Mairus Ilchseite
    0 Mitglieder finden den Beitrag gut.
  3. Di. 30.03.2010 23:48 Uhr #3
    User Pic
    Cartment Mitglied
    Registriert seit
    14.02.2007
    Beiträge
    372
    Beitragswertungen
    0 Beitragspunkte
    Wenn du dir die Klasse einmal anschaust,
    greift sie auf eien Tabelle zu in der die Variablen abgelagert sind.
    Ich nehm einfach mal eine Zahl. Beispielsweise wir haben knapp 400
    Sprachvariablen. Würden diese alle in einem Array abgelegt und damit
    immer gleichzeitig aufgerufen, würde das einen größeren Speicher-
    aufwand erzeugen.

    Ich hoffe du dachtest jetzt nicht, das das gesamte einfach
    in einer Klasse abgelagert würde.


    Zuletzt modifiziert von Cartment am 30.03.2010 - 23:48:54
    0 Mitglieder finden den Beitrag gut.
  4. Mi. 31.03.2010 02:07 Uhr #4
    User Pic
    Mairu Coder
    Registriert seit
    16.06.2006
    Beiträge
    15.334
    Beitragswertungen
    386 Beitragspunkte
    Naja soviel Speicher ist das in den meisten Fällen nicht, gerade wenn man dann ggf. noch nach Module aussortiert, ist es in jedem Falle sie in einem Rutsch aus der Datenbank zu holen (und zwischenzuspeichern) als 10 einzelne Zugriffe auf die Datenbank zu haben, denn RAM >>> db-Zugriffe, optimalerweise sollte es wie gesagt, noch mit Kategorien, für Module z.B., eingeschränkt werden, damit nicht immer 400 geladen werden müssen, das ist richtig.

    Vom Speicheraufwand, braucht du die ja nur mal die Größe der Sprachdateien anschauen, das sind ein paar Kb, also wirklich nicht besonders viel, natürlich wird mit assoziativen Arrays bei vielen Einträgen auch langsamer, deswegen wie schon erwähnt, weniger Einträge sind besser.

    Wenn man jetzt noch weitergeht, sollte man die Templates dann auch gleich mit Spracheersetzungen dann gleich cachen, dann braucht man am Ende die Zugriffe auf die Sprache sehr selten, aber das wird dann langsam offtopic.
    Und auch immer mal ein Blick auf die FAQ werfen. | Mairus Ilchseite
    0 Mitglieder finden den Beitrag gut.
  5. Mi. 31.03.2010 12:11 Uhr #5
    User Pic
    Cartment Mitglied
    Registriert seit
    14.02.2007
    Beiträge
    372
    Beitragswertungen
    0 Beitragspunkte
    Ich versuche nur die Vorteile zu verdeutlichen.

    Aber ok.
    Ich habe das mit der Tabelle mal etwas genauer analysiert.
    Getestet wurde an einer Tabelle mit 1000 Einträgen. 
    SELECT
	COUNT(languageItemID) AS count,
	languageItemValue
FROM
	`ic1_language_item`
WHERE
	languageID = '0' AND
	languageItem = 'test'
LIMIT 2


    Bytes_sent: 396

    Würde man das ganze jetzt auch noch kategorisieren,
    könnte dieser Wert fast halbiert werden, da er bisher
    die gesamte Tabelle durch geht.

    Die de.php alleine besitzt schon eine größe von 17 KB,
    die während jedem Aufruf mit in das System eingebunden
    werden müssen. Wobei die "de" alleine, weniger als 400
    Einträge besitzt.

    Würde ich diese nun um weitere 600 Einträge ergänzen,
    wie es mit einer zweiten Sprache gut aus der Fall sein
    kann, wären dies mehr als 30 KB.


    Das ist wie gesagt, aber auch nur ein Vorteil.
    Ein großer Aspekt wären auch dei Entwickler, die sich endlich auf
    ein flexibles Sprachsystem einstellen können, das jederzeit verändert
    werden kann. Bei dem jetzigen ist dies nicht der Fall. Man könnte, diese
    zwar ergänzen, doch wird es spätestens beim 2. oder 3. Paket Probleme geben.

    Was ich noch ergänzen würde, zu dem jetzigen System von mir,
    wäre eventuell eine Verwaltung im ACP. Sodass es jedem User ermöglicht
    würde, seine Variabeln individuell zu bearbeiten oder auch neue Sprachen
    hinzuzufügen.
    0 Mitglieder finden den Beitrag gut.
  6. Mi. 31.03.2010 12:26 Uhr #6
    User Pic
    Mairu Coder
    Registriert seit
    16.06.2006
    Beiträge
    15.334
    Beitragswertungen
    386 Beitragspunkte
    Du hast mich da vielleicht nicht ganz richtig verstanden, es geht meist um Zeit, sicher auch um Speicherauslastungen, aber KBs sollte man sicher nicht streiten.

    Und Datenbankabfragen sind in der Regel langsam, und in jedem Fall langsamer als Speicherzugriffe, deswegen sollte man immer versuchen Datenbankabfragen zu minimieren, dabei geht es nicht darum, wie viele Daten von der Datenbank zurück kommen, sondern die Zeit die vergeht, bis du deine Daten von der Datenbank hast, wenn jetzt jeden Wort nachgeschlagen werden muss, ist das in jedem Fall sehr ineffizienter, als mal mit einem Rutsch viele zu holen und im Speicher zwischenzuspeichern.

    Und ich wiederhole nochmal, eine Klasse ist sicher besser als ein Array in der Benutzung, Erweiterbarkeit usw. allerdings waren die von dir angesprochenen Punkte in meinen Augen nicht unbedingt die ausschlaggebenden Argumente, eher im Gegenteil.
    Und auch immer mal ein Blick auf die FAQ werfen. | Mairus Ilchseite
    0 Mitglieder finden den Beitrag gut.
Geschlossen

Zurück zu Kritik und Verbesserungen

Optionen: Bei einer Antwort zu diesem Thema eine eMail erhalten