Egy hét Drupal 7: Oldal kiszolgálás és a drupal_render

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.

  1. function js_proba_page() {
  2. $oszlop = 10;
  3. $sor = 10;
  4. $data = array();
  5. $data['#header'] = array();
  6. $data['#rows'] = array();
  7. for ($i = 0; $i < $oszlop; $i++) {
  8. $data['#header'][] = 'Oszlop_'. $i;
  9. }
  10. for ($j = 0; $j < $sor; $j++) {
  11. $row = array();
  12. for ($i = 0; $i < $oszlop; $i++) {
  13. $row[] = 'Elem_'. $j .'_'. $i;
  14. }
  15. $data['#rows'][] = $row;
  16. }
  17. $data['#theme'] = 'table';
  18. $data['#attributes']['class'] = array('row-hover');
  19. $data['#attached']['library'] = array(array('js_proba_lib', 'row_hover'));
  20. return $data;
  21. }

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.

CsatolmányMéret
Package icon js_proba_2.zip1.9 KB

Hozzászólások

Ha views lapozojat akarod atteni vagy megjeleniteni a lista tetejen is, akkor az azert nem olyan bonyolult D6-ban sem, mert a pagert a template-ben illik atrakni a lista tetejere..
konkret pelda: http://drupal.org/node/378140#comment-1715142

de termeszetesen egyetertek, a D7 render nagyon jo dolog..

Lehet jobb példa lett volna a főoldal, vagy bármelyik taxonomy lista.

Mondhattam volna azt is, hogy tessék összehasonlítani a hatos főoldal megjelenítését a hetes főoldal megjelenítésével.

Előbbi hemzseg a HTML-től, míg utóbbiban csak elvétve találsz azt, ráadásul azt is úgy, hogy könnyedén felül tudod írni.

Új hozzászólás