Tartalomszervezési megoldások II. - Views és CCK modul

Negyedik megoldás: Views

Tételezzük fel, hogy egyesületünk honlapján a csapatnevek mellet nem 2 hanem 4 további kategóriát szeretnénk bevezetni: Fiúk, Lányok, Hazai játékosok, Vendégjátékosok. Ez a – rendkívülinek nem nevezhető – helyzet azt eredményezi, hogy webhelyünk szerkezete, és ezzel párhuzamosan a menürendszer kényelmetlenné és a kategóriák közötti átfedésektől függően nehezen áttekinthetővé vált:

• Piros csapat
• Piros fiúk
• Piros vendégjátékosok
• Piros vendégjátékos fiúk
• Fiúk
• Hazai játékos fiúk
• ...stb.

Ha például azt szeretnénk, hogy a hazai játékosoknak és a vendégjátékosoknak a csapatok mintájára külön oldaluk legyen (ne csak egy-egy lista), akkor ezeknek külön könyvet kell nyitnunk; és mivel egy oldalt (könyvlapot) csak egy könyvbe tudunk beilleszteni, a játékosok oldalait kétszer kell felvinnünk a honlapra. Hasonló problémát okoz az a korlátozás, hogy egy node-hoz csak egy útvonal álnevet rendelhetünk, ezért pl. egy Piros csapatban játszó vendégjátékos fiú oldalán vagy a Piros fiúk, vagy a Vendégjátékosok segédmenüpontot fogjuk tudni megjeleníteni (hacsak nem használunk többszörösen összetett útvonal álneveket, amivel éppen az álnév lényegét – egyszerűen megjegyezhető internetcím – veszítjük el). Ezen a ponton már a Drupal alapcsomag korlátait feszegetjük, és éppen ideje kiegészítők után néznünk: ismerkedjünk meg a Views modullal.

A Views a Drupal rendszer által készített listák felülírására, valamint új listák létrehozására használható. A felülírás azt jelenti, hogy egy adott webcímen, pl. a www.valami.hu/taxonomy/term/1 alatt nem a szokásos kategória-listát látjuk, hanem egy általunk megadott szempontok szerint módosított felsorolást. Lássuk, milyen módosításokat tesz lehetővé a Views:

• Lista megjelenítése nem csak önálló oldalon, hanem blokkban is
• Hozzáférés korlátozása felhasználói csoportok szerint
• Oldalaknak, blokkoknak egyéni cím
• Oldalaknak, blokkoknak egyéni fejléc és lábléc
• Listázott elemek megjelenítési módjának meghatározása (teljes node, bevezető, táblázat, felsorolás)
• Listában szereplő node-ok számának meghatározása
• Listában szereplő mezők meghatározása (pl. cím, beküldési idő, szerző neve, stb.)
• Lista szűkítése kategóriák, tartalomtípusok, közzétételi beállítások szerint
• Lista rendezése növekvő vagy csökkenő sorrendbe
• ... stb.

A fenti felsorolás nem teljes, de talán érzékelteti a modul sokoldalúságát. Számunkra most a legérdekesebb az a lehetőség, hogy a listázó oldalakhoz egyéni fejlécet készíthetünk. Eredeti problémánk az volt, hogy nem tudtuk a kategória listázó oldalak tetejére beszúrni a csapatok elérhetőségét és egyéb információit – ezt a feladatot szépen megoldhatjuk a listázó oldal felülírásával. Készítsük el tehát a kategóriákat és vigyük fel a játékosok oldalait:

• Piros csapat (taxonomy/term/1)
  • Játékos-1 (node/1)
  • Játékos-2 (node/2)
  • Játékos-3 (node/3)
  • stb.
• Kék csapat (taxonomy/term/2)
  • Játékos-4 (node/4)
  • Játékos-5 (node/5)
  • stb.

Ezután az admin/build/views/add oldalon készítsük el a nézeteket, amelyekkel felülírjuk a taxonomy/term/x oldalakat:

• Name (név): piroscsapat
• Access (hozzáférés): mivel mindenki számára elérhetővé kívánjuk tenni az oldalt, ne jelöljük be egyik csoportot sem
• Description (leírás): Piros csapat oldala (ezt a szöveget csak az adminisztrátor látja)
• Page (oldal)
  • Provide page view (oldal készítése): kipipálva
  • URL (webcím): taxonomy/term/1
  • View type (nézet típusa): Teaser List (bevezetők)
  • Title (az oldal látható címe): Piros csapat
  • Use Pager (lapozó használata): kipipálva
  • Breadcrumb trail should not include "Home" (A morzsa ne tartalmazza a 'Nyitólap' linket): hagyjuk üresen
  • Nodes per Page (node-ok száma): 10
  • Header (fejléc): ide illeszthetjük be a Piros csapatra vonatkozó információkat; ha HTML vagy PHP kódot használunk, ne felejtsük el átállítani a beviteli módot

Filters (szűrők):

• Node: Published -> Equals: Yes (csak a közzétett oldalak szerepeljenek a listán)
• Taxonomy: Terms for Csapatok -> Is One Of: Piros csapat (csak a 'Piros csapat' kategóriába sorolt cikkek szerepeljenek a listán); Option: 10 (ha szeretnénk, hogy a 'Piros csapat' kategória alá besorolt esetleges alkategóriák tartalmát is listázza)

Sort Criteria (sorrendezési szabályok):

• Node: Sticky -> Order: Descending ('kiemelt' cikkek az oldal tetejére, csökkenő időrendi sorrendben)
• Node: Created Time -> Order: Descending (többi cikk csökkenő időrendi sorrendben)

Látogassunk el a www.valami.hu/taxonomy/term/1 oldalra: a korábbi egyszerű listázó oldal helyett most a fejléccel kiegészített, teljes értékű Piros csapat oldalt látjuk. Természetesen használhatunk egyszerűen megjegyezhető webcímeket is; ehhez navigáljunk az 'Útvonal álnevek' menüpont alá, és adjuk meg, hogy a taxonomy/term/1 mellett legyen oldalunk a piros címen is elérhető. A 'Menük' oldalon állítsunk be egy piros címre mutató menüpontot is – ezzel el is készültünk a Piros csapat oldalával. Ismételjük meg a nézet készítés, útvonal álnév megadás, menüpont készítés lépéseket valamennyi kategóriánkra. Ha ezek után felkeressük bármelyik játékos oldalát, ott találjuk a kategória linkeket (Piros csapat, Fiúk, Vendégjátékosok); és ha bármelyik linkre rákattintunk, a Views által készített, fejlécekkel/láblécekkel feljavított nézet-oldalakra lépünk. Ezeket az oldalakat igen jól lehet sminkelni, tehát egyéni megjelenést is tudunk nekik adni; emellett a fejléc/lábléc szövegbe egyszerűen beilleszthetünk kombinált taxonómia-linkeket (pl. a Fiúk oldalon a hazai és vendégjátékos fiúk listájára mutató linkek), ill. Insert View modullal bármilyen más nézetet – így kordában tudjuk tartani a csak bizonyos oldalakon megjelenítendő másodlagos menük burjánzását. Webhelyünk ezzel áttekinthető szerkezetet és következetes navigációs struktúrát kapott.

Megjegyzés: A Views nézetkészítő űrlapján lehetőség van URL-ként útvonal álnevek megadására, valamint menüpont készítésre is. Ezeket a szolgáltatásokat akkor célszerű használni, ha teljesen új, a rendszerben nem szereplő listát készítünk (pl. ha a "Piros csapat" kategóriában szereplő "kép" típusú tartalmakat szeretnénk kigyűjteni egy külön képgaléria számára). Ha egy meglévő listát szeretnénk felülírni, akkor először készítsük el a nézetet a rendszer által meghatározott URL (pl. taxonomy/term/x) megadásával, majd külön lépésben definiáljuk az útvonal álnevet és a menüpontot. Ezzel elkerülhető, hogy webhelyünkön egymás mellett éljen a hagyományos oldal és annak felülírt verziója, ami esetleg megzavarhatja a barangoló látogatókat.

Ötödik megoldás: CCK + Views

A Views modullal már egészen összetett webhelyeket is építhetünk anélkül, hogy egyetlen sor PHP-kódot kellene írnunk; mégis elképzelhető néhány olyan eset, amikor még ez a megoldás sem elégíti ki az igényeinket. A Views kezelőfelülete meglehetősen bonyolult, márpedig minden egyes alkalommal, amikor új nézetet készítünk (pl. új kategóriával bővül a webhely), vagy meglévőt módosítunk (megváltozott a csapat telefonszáma), akkor kénytelenek vagyunk ezen a barátságtalan űrlapon dolgozni. Húsz-harminc nézetnél többet ilyen módon kezelni még akkor is kényelmetlen, ha a webhely karbantartását hozzáértő webmester végzi – laikusoktól pedig egyáltalán nem várható el, hogy kiigazodjanak a Views bokros opciói között.

Szintén tovább kell lépnünk akkor, ha szeretnénk kétszintes honlapunkat (játékosok, csapatok) három- vagy többszintessé bővíteni. Képzeljük el azt az esetet, amikor több tucat csapatunk van, és szeretnénk a csapatok részvételével versenyeket szervezni. Létrehozhatunk egy Versenyek kategóriát, de ehhez nem tudjuk hozzárendelni a csapatokat, mert azok nem node-ok, hanem kategóriák, ill. a kategóriák módosításával létrehozott nézetek. Ennek a problémának a megoldására született a Category kiegészítő modul – az ezzel a modullal létrehozott kategóriák tehát egyúttal node-ok is, amelyek tetszőleges információkat (elérhetőségek, verseny helyszíne, időpontja, stb.) tartalmazhatnak, és amelyeket a szokásos módon kategorizálhatunk és listázhatunk. A Category felülete azonban legalább olyan bonyolult, mint a Views modulé, és csupán egyetlen szolgáltatást kínál. Cikkünk megírásának időpontjában általában jobb megoldás a Content Construction Kit (rövidítve CCK) modul használata.

A Drupal alapcsomaggal létrehozott tartalomtípusok csak két mezőt tartalmaznak: a címet és a törzset. A CCK modul legfontosabb szolgáltatása, hogy lehetővé teszi a tartalomtípusok bővítését további mezőkkel. Ha jól strukturálható adatokkal dolgozunk, akkor a CCK segítségével a tartalmak beküldését és megjelenítését nagymértékben szabályozni tudjuk. Példánknál maradva hozzunk létre 3 tartalomtípust a szükséges mezőkkel:

• Játékos
  • Name: Játékos
  • Type: jatekos
  • Title field label: A játékos neve
  • Body field label: A játékos életrajza
  • Text field: A játékos telefonszáma
  • Node reference: Csapat
• Csapat
  • Name: Csapat
  • Type: csapat
  • Title field label: A csapat neve
  • Body field label: A csapat története
  • Text field: Az edző neve
  • Text field: Az edző telefonszáma
  • Node reference: Játékos
• Verseny
  • Name: Verseny
  • Type: verseny
  • Title field label: A verseny neve
  • Body field label: A verseny leírása
  • Text field: Helyszín
  • Date field: Időpont
  • Node reference: Csapat

A tartalomtípusok létrehozása után a "Tartalom beküldése" menüpont alatt megjelenik a 3 típus – az ezekhez tartozó beküldő űrlap kitöltése pedig a laikus felhasználó számára sem okoz gondot. Tartalomszervezés szempontjából figyelemre méltó a "Node reference" mező, amely megoldást jelent kategorizálási problémáinkra: ennek segítségével a versenyzőket a csapatokhoz, a csapatokat pedig a versenyekhez tudjuk rendelni. A gyakorlatban ez azt jelenti, hogy például egy új játékos létrehozása két lépésből áll: először is létre kell hoznunk a "játékos" típusú tartalmat, amelynek során kiválasztjuk a node reference listából, hogy az új ember melyik csapatban játszik; majd az adott csapat node reference listájára fel kell vennünk az új játékost. A munkafolyamatot tovább egyszerűsíthetjük, ha a csapatok tagjait nem node reference útján határozzuk meg, hanem Views modullal készítünk egy csapattagokat listázó nézetet, majd ezt beágyazzuk a Csapat tartalomtípusba.

• URL: csapat
• Filters:
  • Node Published -> Equals: Yes
  • Node: Type -> Is One Of: Játékos
• Arguments:
  • Argument type -> Node reference: Játékos (field_csapat)
  • Default -> Summary, unsorted

Ezzel lényegében megmondtuk a Views-nak, hogy készítsen listát azokból a játékos node-okból, amelyek rendelkeznek field_csapat nevű CCK-s mezővel. Ha a nézet nem kap argumentumot az URL végén (pl. a www.honlapneve.hu/csapat címen), akkor készít egy összesített listát, zárójelben a csapat játékosainak számával:

• Piros csapat (20)
• Kék csapat (18)

Ha a nézet az URL végén argumentumot kap (pl. www.honlapneve.hu/csapat/12), akkor kilistázza az adott csapatra – esetünkben a node/12 azonosítójú, csapat típusú tartalomra – node reference útján hivatkozó node-okat, azaz a csapat játékosait. Ezt a nézetet Viewfield modullal tudjuk beágyazni a csapat node-okba:

1. Egészítsük ki a Csapat CCK-s tartalomtípusunkat egy Viewfield mezővel.
2. Argumentumként adjuk át az aktuális node azonosítóját: %nid.
3. Ha ezek után felkeressük bármelyik Csapat típusú node-ot, ott látjuk az adott node-ra node reference útján hivatkozó játékosok listáját.

A CCK és a Views a legdinamikusabban fejlesztett kiegészítő modulok közé tartoznak, egyes funkcióik hamarosan az alapcsomagban is megjelennek. Számíthatunk rá, hogy a jövőben a hasonló rendszerező oldalak készítése tovább fog egyszerűsödni. Elég jó angol nyelvű dokumentáció található róluk a Drupal.org kézikönyvében:

• Views: Customized node lists
• Content Construction Kit Handbook
• CCK kiegészítők listája (folyamatosan bővül, érdemes figyelemmel kísérni)

További újdonságot jelenthet a Book modul tervezett átalakítása, amely kimondottan a hierarchikus honlapok készítését fogja megkönnyíteni.

Remélhetőleg a fenti példákból is nyilvánvalóvá vált, hogy szinte bármilyen tartalomszervezési problémával kerülünk szembe, találni fogunk a Drupal kínálatában olyan megoldást, amellyel PHP kód írása nélkül, esetleg pár soros kódrészlet beillesztésével a feladat megoldható. Azonban a Drupal csak a kódolás terhét tudja levenni a vállunkról – gondolkodni nem tud helyettünk. A számunkra optimális megoldást csak akkor tudjuk kiválasztani, ha a webhely építését megelőzően elemezzük, modellezzük a feladatot, és még a tartalmak tömeges felvitele előtt alaposan tesztelünk.