Most, hogy gőzerővel készülök az Integral Vision Workshop rendezvénysorozatunkra, úgy gondoltam megosztok egy pár érdekességet, gondolatot a Drupal 7 verziójáról.

Ma az oldalkiszolgáló mechanizmus egyik legnagyszerűbb újdonságáról fogok beszélni.

Eddig a Drupal oldalkiszolgáló mechanizmusa a következőképpen működött: Amennyiben nem adtunk vissza semmit az oldal tartalmát előállító függvényben, akkor a Drupal feltételezte, hogy a kimenetet már mi magunk kiküldtük, és ezért ő “semmit nem csinált”. Abban az esetben, ha visszaadtunk egy szöveget akkor azt úgy tekintette, mint a weboldalunk tartalmi része. E köré a tartalmi rész köré rakta a régiókat és mindenféle egyéb okosságot ami szükséges volt az oldalunk megjelenítéséhez. (A fent jelzett okosságokat egyébként a sminkünk, page.tpl.php (6.x, 7.x) és html.tpl.php (7.x) fájljában találhatjuk meg)

A hetes Drupalban azonban van egy merőben új lehetőség, mely azok számára, akik valaha is állítottak elő űrlapot a Drupalban, csak örömöt, újdonságot nem fog jelenteni.

A drupal_render függvényről röviden

Van egy függvény a Drupalban mely segítségével egy tömbben leírt adathalmazból tudunk előállítani HTML kimenetet. Ez első körben ez azért jó, mert azt, hogy pontosan milyen HTML kimenet lesz ebből a tömbből, azt a sminkünk mondja majd meg. Totális kontrollunk van tehát a HTML kimenet felett. A másik nagyszerű dolog ebben, hogy lehetőségünk van arra is, hogy a renderelő függvénynek átadott adathalmaz adattartalmát, a HTML kimenet előállítása előtt megváltoztassuk. Függetlenné tettük tehát az adathalmazunkat a megjelenésétől. Lehetővé tettük, hogy a megfelelő helyen, mindenfajta csúnya trükközés nélkül módosíthassuk a megfelelő elemeket.

Ezt a mechanizmust a hetes Drupal már a teljes oldal kialakításra és renderelésre használja ellenben a hatossal, ami csak az űrlapoknál és a node tartalmi részének előállításánál használta azt.

Nézzük, hogy hogyan kell kinéznie ennek a tömbnek: Kétfajta kulcs lehet a tömbben, olyan ami # jellel kezdődik, és olyan ami a nélkül áll. Fontos tudnunk, hogy minden # jellel kezdődő elem tulajdonság, míg az a nélküli elemekre úgy fog tekintetni a render függvény, mint gyermekelemre. A gyermekelemekre pedig ismételten meghívja önmagát mindaddig, amíg van gyermekelem. Ezt azért is jó tudni, mert ha értelmetlennek tűnő és egyben furcsa hibaüzeneteket kapunk az azért van, mert lehagytuk a # jelet a tulajdonság elejéről.

A tegnapi modult egy picit átalakítottam. Először is szétszedtem két modulra. Az egyik csak a JavaScript könyvtárat adja hozzá a rendszerhez, a másik pedig csak az oldalt valósítja meg.

function js_proba_page() {
  $oszlop = 10;
  $sor = 10;
  $data = array();
  $data['#header'] = array();
  $data['#rows'] = array();
  for ($i = 0; $i < $oszlop; $i++) {
    $data['#header'][] = 'Oszlop_'. $i;
  }
  for ($j = 0; $j < $sor; $j++) {
    $row = array();
    for ($i = 0; $i < $oszlop; $i++) {
      $row[] = 'Elem_'. $j .'_'. $i;
    }
    $data['#rows'][] = $row;
  }
  $data['#theme'] = 'table';
  $data['#attributes']['class'] = array('row-hover');
  $data['#attached']['library'] = array(array('js_proba_lib', 'row_hover'));
  return $data;
}

Nézzük, mi változott. Az első az, hogy a header és rows kulcsok immár #header és #rows nevet viselik, lévén nem olyan elemek amiket le kéne renderelni, vagyis nem a táblázat gyermek elemei, hanem a táblázat tulajdonságai. A #theme paraméterrel tudjuk megmondani a rendszernek, hogy hogyan is kéne ezt az elemet sminkelni, amit nem szabad összetéveszteni a #type paraméterrel, mert az az elem típusát hivatott megmondani. Amennyiben nem adjuk meg a #type paramétert, a Drupal sima markup elemként fogja lerenderelni az adathalmazt. Itt pedig most pontosan ez a célunk. Beállítjuk a táblázat osztályát, hogy a hozzá csatolt JavaScript könyvtárban található függvény könnyedén rátaláljon.

A végén látható a legnagyobb medzsik, ugyanis az egész tömböt adjuk vissza, amit majd a Drupal fog nekünk HTML-é alakítani. Ez teszi lehetővé, hogy még könnyebben testre tudjuk szabni a rendszerünket.

Gondoljunk bele, hogy eddig hogyan oldottuk volna meg azt a problémát, hogy egy listánál a lapozó ne csak alul, hanem a tartalom tetején is megjelenjen? Mintaillesztő kifejezéssel kiszedtük a lapozót és betettük előre. Aztán ha picit is változtattak a lapozón (mert mondjuk valaki a views-ban minilapozót állított be), nyúlhattunk bele a kódba. Most úgy tudjuk átrakni a lapozót, hogy nem kell tudnunk hogyan néz ki, vagy hogyan fog majd kinézni.

Természetesen a fenti példa nem a legjobb, hisz ahhoz, hogy működjön, a megfelelő osztályt hozzá kell adnunk, a megfelelő könyvtárat pedig csatolnunk kell a táblázatunkhoz. Elegánsabb lett volna egy speciális tulajdonság felvétele, melyet a proba_js_lib modulunk egy előfeldolgozóban figyel, és a megfelelő elemeket már ő adja hozzá. Figyelhettük volna azt is, hogy adott class van-e a táblázaton és akkor ennek függvényében adhattunk volna hozzá a könyvtárat. Arra is lett volna lehetőségünk, hogy egy új elemet hozunk létre ami hasonlóan működik a táblázathoz, csak a megfelelő plusz elemekkel már rendelkezik.

Javaslom, hogy a fenti lehetőségek egyikét, vagy mindegyikét próbáljuk meg önállóan megvalósítani.