Hirdetés

Keresés

Új hozzászólás Aktív témák

  • cucka

    addikt

    válasz Sk8erPeter #3980 üzenetére

    Most mit kötekszel? Nem arról volt szó, hogy fingom sincs, mi az a gráf vagy fa, hanem arról, hogy jelen esetben Te hogy oldottad meg a gyakorlatban.
    Nem kötekedésként írtam. A fa tárolási eljárásom amúgy teljesen szokványos megoldás, nincs benne semmi hókuszpókusz. Azért kérdeztem, hogy tanították-e, mert általában egyetemeken ilyesmiket meg szoktak mutatni gyakorlati órákon, tehát nem kell mindent az alapoktól magyaráznom :) .

    A kérdés oka az volt, hogy először úgy képzeltem, hogy a language táblát is azért kell joinolni, mert mondjuk úgy kérdezel le, hogy "... WHERE language.name='en';", és akkor tényleg kellett volna joinolni, mivel akkor különben honnan szeded a nevet?
    Egy lekérdezésnél akkor kell bejoin-olni egy táblát, ha szükséged van valamilyen mezőre belőle. A nyelvek kezelését egy nyelvkezelő osztállyal oldom meg, amely a konstruktorában betölti a rendszerben található összes nyelvet. Ha szükségem van arra, hogy a "hu" nyelvnek mi az azonosítója, akkor megkérdezem a nyelvkezelő objektumtól (és nyilván fordítva is, ha mondjuk a 2-es nyelv szöveges nevére van szükség). Így megspórolom, hogy minden egyes, többnyelvű adatot érintő lekérdezésbe bele kelljen join-olni a nyelv táblát is.

    Igen, viszont így megnő az esélye annak, hogy elcseszi a fájlt, és ha nem ért a HTML-hez, akkor néz, hogy miért nem működik.
    Félreértetted. A felhasználó által szerkesztett menü egy xml-ben van, a felhasználó által szerkesztett szöveges tartalom pedig file-okban. Magát a honlap sablonját nem piszkálhatja, egyszerűen csak kap egy fckEditor-t, ahova beírhatja a szöveges tartalmakat. Így nem tud elrontani semmit.

    Akkor meg már mondjuk az a kérdés is felmerül, hogy miért is ne használjunk adatbázist a saját életünk megkönnyítésére, és alakítunk ki egy jó admin felületet a megrendelőnek, ahol sokkal szebb felületen tudja szerkesztgetni a menüpontokat és a belső tartalmat.
    A most említett file-os megoldásom pontosan ugyanazt tudja, mint ha adatbázisból működne a dolog. A korábban említett, oop-s fa reprezentációm pont ezért hatékony, mert a hozzá tartozó alkalmazáslogika, adminisztrációs felület vagy megjelenítés szempontjából érdektelen, hogy adatbázisban vagy xml-ben tárolod a fát/menüt.

    A file-ban tárolós megoldás azért hatékony, mert sok ügyfél csak egy pár menüpontból álló szöveges honlapot kér. Ezt megfelelő keretrendszerrel ezt 1-2 nap alatt meg lehet csinálni és csak egy php-s tárhelyre van szükség hozzá. Gyakorlatilag csak a html/css részét kell elkészíteni, a többi már kész van, ezért fontos követelmény a programkódnál az újrafelhasználhatóság.

Új hozzászólás Aktív témák