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

• #3952 cucka addikt Sk8erPeter #3947

  Új Válasz 2010-02-08 09:57:32 #3952

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  cucka

  addikt

  válasz Sk8erPeter #3947 üzenetére

  Mivel lenne olyan max. 6 menüpont, így nem tudom, érdemes-e egyáltalán azonosítószámot rendelni az egyes menüpontokhoz, vagy elég lenne, ha mondjuk lenne két összetartozó elsődleges kulcs, mondjuk PRIMARY KEY (oldal_rovid_neve, nyelv), vagy ez már gagyibb megoldás?
  Amiről te beszélsz, azt kompozit kulcsnak hívjuk és jelen esetben igen, gagyibb lenne.

  Ha normálisan szeretnéd megcsinálni, akkor valamilyen újrafelhasználható megoldásban gondolkozz. Például itt egy táblaszerkezet olyan esetre, amikor 1 menü van az oldalon:
  
  Van egy menü tábla, ahol a menüpontok vannak. A parent_id mező a menü táblában saját magára mutat, így tudsz tetszőleges mélységű menüt létrehozni. A controller mezőben azt tárolom, hogy a menüponthoz milyen tartalom tartozik. (Pl. sima szöveges oldal, kezdőlap, fórum, stb., amire szükség van). A menu_content táblában a menüponthoz tartozó szöveges tartalom található. Nyilván, ha a menüpont nem egyszerű szöveges tartalom, akkor a mezők lehetnek üresek (de pl. a címre szükség van). Ide kerülhet bármi, ami a menüpont függvényében változik az oldalon és nyelvfüggő (pl. fejléc cím, meta tag-ek, utolsó módosítás, vagy amit csak akarsz).

  Amúgy a menü kérdését én úgy oldottam meg, hogy írtam egy általános fa osztályt, aminek van hozzáadás, törlés művelete, le lehet kérdezni a fa csúcsainak tartalmát, stb.
  Írtam hozzá egy serializer interface-t, aminek az a szerepe, hogy feltöltse a fát adatokkal és elmentse a változtatásokat. Írtam még hozzá egy visualizer interfészt, aminek a szerepe, hogy a fából html-t gyártson. Ezáltal van egy olyan fa struktúrám, amit bármire fel lehet használni, a tartalmát tetszőleges helyről tudja beszedni és ugyanoda el is tudja menteni saját magát és tetszőleges módon lehet kiiratni. (A serializer és visualizer osztályokat kell ehhez cserélgetni). Ebből a fából származtattam egy menü osztályt, aminek egyetlen plusz funkciója van, az aktuális url-ből meg tudja mondani, hogy mely menüpont van kiválasztva. Kb. ennyi, ezzel a struktúrával viszonylag egyszerűen bármilyen fa adatstruktúrát könnyen lehet kezelni. (pl. menü, webshop kategóriák, könyvtárstruktúra, stb.).

• #3949 Tele von Zsinór őstag Sk8erPeter #3947

  Új Válasz 2010-02-08 06:52:40 #3949

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Tele von Zsinór

  őstag

  válasz Sk8erPeter #3947 üzenetére

  Igen, így kérem le. Van benne még rendezés, oldalra szűrés, de a lényeg ez.
  Az esetek 90%-ában elég, ha az általad írt módon, a legutolsó módosítás adatai megvannak, ha ez elég a megrendelőnek is, akkor meg is vagy. Ha mégsem lenne, akkor beleraksz még egy verzió (int) oszlopot, és egyesével növelgeted, selectben pedig a legnagyobb verziójút kéred.
  Az életem egyszerűsítése kedvéért kapcsolótáblákat kivéve szinte mindenhova pakolok auto_inc elsődleges kulcsot, az _i18n táblába kivétel - itt az ős (itt: tibia_news) tábla auto_inc kulcsa és a nyelv együtt a primary key. Ide külön kapcsolótábla nem kell, egyszerű 1:n relációnk van.
  Nem értem pontosan ezt a menüpontokhoz azonosítószámot dolgot. Úgy érted, hogy statikusra csinálod, és a főoldal mondjuk az 1, fórum a 2, stb.? Én maradnék ennél, ahelyett, hogy a menüpont nevét használom kulcsként - ki tudja, mikor kell majd átnevezni később, de az id-je nem fog változni.

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