szakma

Sorrendezhető táblázatok

Ismét egy hasznos kis Drupal modulra bukkantam, amit meg kell osztanom. Történt, nem is olyan régen, hogy bizonyos nodeok között egy sorrendet kellett meghatározni. Néhány oldalból álló, előre-hátra lapozható termékbemutató oldalra kell gondolni.

Szépen fel is vettem a CCK-ban egy új mezőt, oldalszám néven, amit egy legördülő menüből lehetett kiválasztani. A nodeok megjelenítése és a lapozás megvalsóítása a theme rétegbe került. Viszont szükség volt még valami adminisztrációs felületre, a node lista szerkesztéséhez. Persze a beépített szerkesztő oldalon, az oldalszám select input mező már adott egy szerkesztési lehetőséget, de így nagyon kényelmetlen lett volna a használata.

Arra gondoltam, a legjobb megoldás egy táblázat lenne, ahol a sorok mozgathatóak a drupal tabledrag.js használatával. Ilyen van pl. a menü és a blokk szerkesztésnél is. Első gondolatom az volt, hogy írok erre egy saját modult, nem egy nagy kalad, legrosszabb esetben is egy óra alatt megvan. Aztán eszembe jutott, hogy a Views modul tud táblázatokat megjeleníteni, de az nem a szerkeszthető verzió, hanem egyszerű táblázat. Elkezdtem nézelődni a Views *.tpl.php smink fájlok környékén, hátha van egy ügyes trükk, amivel rá lehetne venni a Viewst a tabledrag.js használatára.

Nem tudom, hogy végülis van-e ilyen trükk, de mint kiderült, szerencsére nincs rá szükség. Ugyanis, ez az igény másoknál is fellépett, és már megírták helyettünk. A DraggableViews nevű modulról beszélek, amely a Viewsnak egy kiegészítése. Egy új formázási stílust ad hozzá a Viewshoz, a meglévő táblázat, HTML lista és Grid stílus mellett megjelenik egy sorrendezhető táblázat. A nézet létrehozásánál a Draggable Table stílust kell kiválasztani, majd a stílus beállításoknál a sorrendezés alapját képező mezőt megadni. Ennyi az egész.

Íme egy demó, amit a Draggable Table modullal hoztam létre:

A demó már nem elérhető.

Elvileg tud hierarchikus és csoportos rendezéseket is, mint a beépített menü és a blokk szerkesztés. Én ezeket nem próbáltam, nekem csak egy egyszerű rendezhető lista kellett, amire tökéletesen meg is felelt.

A Drupal közösség ismét meglepett, hogy ilyen modul is van már. Úgy tűnik tényleg igaz a mondás, hogy a Drupalban a legnehezebb feladat, találni egy olyan funkciót amire még nincs kész modul :)

PHP komment csiki-csuki

Most láttam egy jópofa megoldást, amit meg kell osztanom.

PHP forráskód barkácsolás közben gyakran előfordul, hogy egy nagyobb kódrészletet, egy teljes blokkot "ki kell kommentezni", azaz megjegyzésbe tesszük, hogy ne fusson le. Majd később visszatesszük a forráskódba, majd megint kivesszük, és így tovább jó sokszor.
Persze lehet használni ezt:

<?php
/*
  $foo = 'bar';
*/
?>

De két külön sorban van, két helyen kell kivenni-betenni.

Milyen jó lenne, ha egy teljes forráskód blokkot egyetlen sorban, egy rövid mozdulattal lehetne megjegyzésbe tenni, és kivenni onnan. Hát kérem itt a megoldás:

<?php
/* 
function foo($bar) {
  return $bar . ' a foo fuggveny NEM letezik';
}
// */
?>

<?php
function foo($bar) {
  return $bar . ' a foo fuggveny letezik';
}
// */
?>

Inkább nem magyaráznám el, hogy működik, elég egyértelmű.

Én még nem ismertem ezt, és örülök neki :)

HtmlBox + Resizable Body - a sitebuilder barát WYSIWYG szerkesztő

A WYSIWYG szerkesztők a Drupalban egy örök téma. Több megoldás is van, de különbözőek az igények, különbözőek a funkciólisták és különbözőek az egyes megoldásokkal járó bug halmazok is :)

Aki esetleg nem lenne tisztában a fogalommal: a WYSIWYG a "What You See Is What You Get" rövidítése, és egyszerűen fogalmazva, ezek ügyes kis javascript eszközök, melyek segítségével úgy lehet szöveget (HTML-t) szerkeszteni egy böngészőben, mint pl. a Word-ben.

Személy szerint szeretek a HTML felett teljes uralommal lenni, ezért több kipróbált modul után, úgy döntöttem hogy, nem használok ilyen eszközt. Valahogy túl nagyok és böszmék voltak. Az volt az érzésem, mintha azt hinnék, nálam is jobban tudják hogy én mit akarok. Egyszóval nem volt jó az összkép. Egy Drupal felhasználói találkozón, még a corvintetőn, CHX ajánlott egy modult amit a NowPublic-kal közösen fejlesztettek ki.

A modul neve HtmlBox, hasonlóan a JavaScript eszközhöz, amin alapul. Anno kipróbáltam, de nem ment, nem tudom miért. Ma viszont adtam neki egy második esélyt és működik, ráadásul első ránézésre bíztató: egyszerű, nincs túlzsúfolva minden funkcióval, gyors, és teljes kontrollt ad a generált HTML kódon. Igaz ez utóbbit a többi hasonló megoldás is tudja, viszont nekem úgy tűnt (2 használat után!) hogy tisztább kódot generál. Elkezdtem hazsnálni, majd elválik mennyire jó.

Egy gondom volt vele: az alapesetben átméretezhető szövegdoboz már nem az, ha használjuk a HtmlBox-ot. Ez viszont nem jó, mert van aki szereti ha sok szöveget lát egyszerre. Pl. én.

De szerencsére erre van egy egyszerű megoldás a Resizable Body modul képében. Pofonegyszerű amit nyújt: meg lehet határozni hogy a node  szerkesztő oldalakon a body szövegdoboz hány sorból álljon. Ennyi.

A fenti két modul kombinációja  hasznos eszköz lehet egy sitebuilder kezében, vagy olyan szerkesztőnek aki nem fut anyuhoz sírva, ha meglát egy kis HTML kódot.

Drupal bejelentkezés több aldomainen.

Kis kihagyás után folytatnám egy újabb villám Drupal tippel:

Tegyük fel, hogy készítünk egy új oldalt, legyen: example.com. Ha megfelelőek a web és dns szerver beállítások, akkor új oldalunk elérhető lesz mind a www előtaggal, mind anélkül, tehát ezeken a címeken: http://example.com és http://www.example.com. Ez eddig jó hír, de ha meglátogatjuk az oldalt az egyik formában, bejelentkezünk, majd átváltunk a másik verzióra, ott bizony nem leszünk belépve. Ez viszont zavaró, mert a később ránk mutató külső linkek valószínüleg mindkét verziót használni fogják. A felhasználók akik meg ezekről a külső oldalakról jönnek, nem fogják érteni, hogy miért vannak néha belépve, néha meg nem.

Belepillantva a .htaccess fájlba, azonnal láthatjuk a megoldást: a látogatókat át kell irányítani, úgy hogy mindig csak az egyik verziót használják. Ez mindössz két sor roppant egyszerű átírást jelenti a .htaccess fájlban, a művelethez pedig bőséges információ található megjegyzés formájában, erre nem is térnék ki.

De van egy másik lehetőség is, amelyet a settings.php rejt. Ebben a fájlban van elrejtve a $cookie_domain beállítás, amelyet ha nem állítunk be a drupal automatikusan kitalál. És pont itt jön be a gond: néha example.com -nak néha www.example.com-nak fogja kitalálni. Viszont ha mi fixen beállítjuk így:

<?php
$cookie_domain = '.example.com';
?>

akkor mindkét esetre érvényes sütit állít elő majd a kód. A lényeg a pont az emaple.com előtt, amely annyit jelent hogy minden .example.com végű un. hostra érvényes a süti.

Egy átlagos weboldalnál ez a módszer nem jobb a .htaccess-es megoldásnál. De ha például egy oldalcsoportot készítünk, ahol különböző aldomaineken (a.exmaple.com; b.example.com, ...) különböző drupal telepítések szolgálnak ki más-más tartalmat, de közös felhasználó adatbázissal, akkor ezzel a megoldással már meg is valósítottuk az un. Single Sign On-t, amikoris egyszer kell belépni, és a felhasználó minden aloldalon belépve marad.

Most látom, nem is lett ez annyira rövid tipp, de remélem hasznos lesz néhány olvasónak.

Félkész böngészők harca

Megjelent a Chrome 2.0, küszöbön a Firefox 3.1 az új TraceMonkey Javascript motorral és készülget az Opera 10 is. Itt az ideje a már hagyományos Javascript teljesítmény tesztnek.

Ezek az új tesztek nem összehasonlíthatóak a régi eredményekkel, mert megváltozott a Dromaeo, illetve ez most másik gépen is futott.

Az új teszt környezet:

  • Intel T7200 processzor (2GHz, 2 mag)
  • 1.5 Gb 667 Mhz ram
  • Frissen telepített Win XP SP3, csak a böngészők lettek installálva

Amit nagyon fontos megjegyezni: Egyik böngésző sem használta ki a két magot, minden teszt 50% processzor terhelés mellett futott.

A tesztek közül a Recommended csomagot futtattam le.

Akkor nézzük az eredményeket abc sorrendben:

Böngésző Eredmény Link
Chrome 1.0.154.43 34054.20 runs/s link
Chrome 2.0.156.1 42879.89 runs/s link
Firefox 3.05 32128.64 runs/s link
Firefox 3.1b2 46860.39 runs/s link
Opera 9.61 7029.80 runs/s link
Opera 10.00 alpha (1139) 10051.06 runs/s link
Safari 3.2.1 (525.27.1) 10797.74 runs/s link

A Firefox 3.1b a legygyorsabb, egy hajszállal megelőzve a most megjelent Chrome 2.0-t. Az eredmények további kiértékelése házi feladat :)

Oldalak

Feliratkozás RSS - szakma csatornájára