hosszu kálmán

Létezik egy jQuery fgv: show(). Ennek az a szerepe, hogy a nem látható html elemet láthatóvá teszi.

Tehát végülis annyi történik, hogy egy html elemet ami el van rejtve (display: none;) megmutat, mégpedig úgy, hogy inline css-sel ad neki egy display: block tulajdonságot.

Ez így rendben is lenne, ha nem akarnánk táblázatok soraira is alkalmazni (table tr). A probléma az, hogy pl. a Firefox szétcsúszik, ha a sor elemre vonatkozó css display: block. Erre a megoldás a display: table-row css definíció. Ezzel viszont az a gond, hogy az IE nem támogatja. Az IE viszont kezeli a táblázat soraira is a display: block tulajdonságot.

Nem értem miért nem építették bele a jQuery-be a böngésző ellenőrzését a show() fgv. meghívása esetében, de akkor vegyük figyelembe magunk, hiszen nem mindegy, hogy a táblázatunk így néz ki:

Vagy így:

Láthatjuk, hogy az első esetben a táblázat első oszlopa sokszorosára nőtt, ezért az oldal szétcsúszott.

JS-ből lekérdezni a böngésző típusát, nem nehéz, és a jQuery-be is beépített (core).

A következő kódot aztán símán beépíthetjük egy saját fgv-be.

Ügyfelünk kérése alapján el kellett készítenünk egy DropDown menüt a nyitólapjára. Most is - mint általában - a jQuery JavaScript könyvtárban kerestem a megoldást. Rövid keresgélés után megtaláltam a Superfish jQuery plugin-t, mely tökletesen megfelelőnek tűnt a célra…legalábbis első ránézésre.

A probléma a tesztelés során jelentkezett, mégpedig a szokásos IE6/IE7/FF kompatibilitási ellentétek keretében.
Mondanom sem kell, hogy a plugin FF alatt teljesen jól teljesített (ugyanúgy mint Safari-n vagy Opera-n), a Microsoft két böngészőjénél az oldal gyakorlatilag összeomlott.

A menü FF-ban:

Az internet Explorerben elég érdeksen mutatott:

Először úgy gondoltam megkeresem a megoldást, mert biztosan lokális gond van, hiszen az oldalon található bemutatókon nincs gond Internet Explorer alatt sem, de akárhogy csürtem csavartam nem akart működni. Nem csak a kinézettel volt összeakadás, hanem a funkcionalitás sem működött. IE alatt egyszerüen eltünt a DropDown menü amikor elhagytam az egérrel a legfelső meüelemet.

Néhány órányi küszködés után úgy felidegesítettem magam, hogy eldöntöttem inkább írok egy sajátot, hiszen nem egy atomfizika a DropDown menü, főleg a jQuery-t használva.

Nézzük meg, először a HTML osztályokat, az elrendezési szabályokat!

Íme egy főmeü, és a hozzá tartozó DropDown menü:

Az l() fgv. használata ne tévesszen meg senkit sem, ez egy beépített Drupal fgv., síma link generálódik belőle.
Tehát a

Sorok nyugodtan lecserélhetőek síma HTML elemekre:

Nézzük meg a css-t, hogy ki is nézzen valahogy, nameg azért vannak benne fontos részek:

Itt volt egy-két érdekesség, amit mindenképpen szeretnék megmelíteni!

Az ul.submenu css definícióban fontos elemek:

Az első három nélkül az oldal IE-ben szétcsúszik, a szélesség megadása nélkül pedig IE6-ban csak 70px lesz a lehullómenü szélessége.

Az “ul.submenu” és az “ul.submenu li a” css definíciónál is nagyon fontos a szélesség megadása, mert különben IE6-ban eltűnik a DropDown menü ha az első elemet elhagyjuk (tehát nem tudjuk kivűlasztani mondjuk a második, vagy harmadik elemet a mnüből).
Az a (link) elemnél nyiván a paddingot kivonjuk a szélességből, ezért lesz 40px-el kevesebb.

A harmadik dolog amire figyelni kell az, hogy mindenhol megadtam a margin-bottom értékét, mégpedig 0-nak. Ez is fontos, különben IE6 alatt nagy alsó margót rak minden menüelem alá.

Végül, mint IE6 mint IE7 alatt nem volt megfelelő az “ul.submenu” bal oldali margó értéke (65px), ezért teljesen kiment a DropDown menü a jobb oldalra. Erre a Conditional comments megoldással probálkoztam, vagyis:

De sajnos ez nem reagált semmit, úgyhogy megoldottam ezt is JavaScript-el:

Nézzük meg végül a lényeget, a HTML-hez tarotó jQuery kódot, amiben kivitelezzük a DropDown menüt:

Mit is csinál?

Az oldal betöltődése után létrehoz egy bool tipusú változót, melyben a DropDown menü aktivitását figyeljük, majd végigmegy az összes ddown-menu osztályon, és figyeli a hover esemény.
Amikor bekövetkezik, a hozzá tartozó submenu osztályt előhozza (show), majd ennek a megjelenített menünek figyeli a hover eseményét.
Ha bekövetkezik, akkor a submenu_active változó értéke igaz lesz, hiszen éppen a menüben vagyunk, ha pedig elhagyjuk, akkor elrejtjük, és a submenu_active értékét hamisra állítjuk.
Végül megnézzük, hogy a ddown-menu osztályba tartozó elemek hover eseményének végén a submenu_active igaz-e, és ha nem akkor a DropDown listát eltávolítjuk. Erre azért van szükség, mert olyan szituáció is elképzelhető, hogy valaki nem lép be a submenu-be, csak előhozza. Ha ez a sor kimaradna, akkor ilyen esetekben a sumenu nem tunne el.

Régebben írtam egy cikket a dinamikus form ellenőrzésről, és arra gondoltam leírom az eljárás modernebb változatát, azaz a hibaüzenetek nem alert ablakban jelennek meg, hanem DHTML segítségével.

Természetesen olyan kódot kell készíteni amely akárhány form-ra dinamikusan működik, tehát nem függ az input mezők számától, és az oldalon elhelyezett form-ok mennyiségétől.

A megoldást itt is a jQuery JavaScript könyvtár adja.

De mindenek előtt érdemes átnézni hogyan is kell felépíteni egy profi form-ot. Khauth György kollegám írt már erről néhány nagyon hasznos cikket:

• Regisztrációs űrlap tervezési minták
• Felhasználóbarát form kitöltés és ellenőrzés
• Ergonómikus formok készítésének irányelvei

Miután az alapelvek tanulmányozásával végeztünk készítsük el a form-ot:

Ha megnézzük a kód a css stílus felépítésével kezdődik, ez gyakorlatilag csak az átlátható kinézetet kezeli. A lényeg természetesen a form, és a form-on belüli osztályok elhelyezkedése!

A form-ot körülöleli egy div, a JavaScript kóddal ezen belül fogunk keresni. Ennek az a lényege, hogy akárhány form-on el tudjuk sütni az eljárást, ne kelljen minden form-nál újra és újra megírni, hozzáigazítani a form-hoz.
Három adatok kérünk be: keresztnév, vezetéknév, és email cím.
Ha megfigyeljük mindegyik alatt megtalálható a hozzá tartozó hibaüzenet is. A hibaüzenetek mindegyike a form-error osztályba van sorolva, így a kinézetük egységesen definiálható, és láthatóságuk egységesen kezelhető.
A hibaüzenetek nem csak a form-error osztályba tartoznak, hanem a hiba típusába is. Ezesetben mind a három input mezőhöz tartozik egy hianyos osztály, ami akkor jelenik meg ha üresen hagytuk, az email címhez pedig egy hibas osztály, ami akkor jelenik meg ha az email cím nem valós.

Nézzük meg a hozzá tartozó JavaScript kódot, melyben dinamikusan elleőrizzük az input mezők kitöltöttségét, és az email cím helyességét, valósságát is:

A dinamikus form ellenőrzésről írt cikkemhez képes van néhány eltérés, most ezekre térnék ki elsősorban.
Az első, hogy nem csak a mehet változót deklaráljuk, hanem a first_error bool típusút, és az error_obj html objektum típusút is. Ezek azt a célt szolgálják, hogy hibás kitöltés esetén le tudjuk tárolni melyik hiba volt az első a sorban, és automtaikusan oda ugorjunk az oldalon.
Utána láthatjuk a

részt, ami arra való, ha már egyszer hibásan töltöttük ki a form-ot, akkor eltűntetjük az összes hibaüzenetet, különben ottmaradhat második hibás kitöltés esetén olyan üzenet is, ami már nem aktuális.

Ezután ellenőrizzük a kitöltöttséget, tehát végigmegyünk a kötelező input mezőkön. Ha valameny nincs kitöltve akkor a szülö objektumának hianyos osztályát megjelenítjük. Végül ellenőrizzük az email cím helyességét, tehát hogy illeszkedik-e a szabványra, és ha nem a szülő html objektumának hibas osztályát megjelenítjük.

Végül ha nem találtunk hibát tobábbengedjük a submit eseményt, ha találtunk akkor az első hibás mezőhöz ugrunk.

Olyan oldalaknál ahol egy bizonyos node tipushoz sok beviteli mező tartozik elvárás lehet, hogy ne kelljen minden módosításnál lemenni a lap aljára.

A logikus megoldás az, hogy az ENTER gomb lenyomásával jelzi a felhasználó, hogy végzett a tartalom módosításával, feltöltésével.

Az eseményt a jQuery JavaScript könyvtárral könnyen meg lehet oldalni, utána pedig már csak egy nagyon egyszerű Drupal modult kell hozzá írni, és minden olyan weblapon alkalmazni lehet ahol szükség van rá.

Íme a JavaScript fájl amint majd hozzárendelünk az oldalhoz:

Menjünk végig a kódon, mi miért van!

Először is a writing változó, a node_edit változó és az oldal betöltésekor lefutó fgv-ek, vagyis a $(document).ready(function()).
A writing változó azért fontos, mert az ENTER lenyomása esetén nem feltétlenül a tartalom szerkesztésének befejeztét jelzi a felhasználó, hanem esetlegesen éppen egy olyan szöveget gépel be, amiben van sortörés. Az pedig elég nagy gond lenne, ha nem lehetne több sort bevinni egy node-ba :-)
Ezért aztán létrehozzuk a writing bool tipusú változót alapértelmezetten hamisra állítva, és figyelve az eseményeket változtatjuk, hogy éppen gépelés történik vagy sem.
Az odlal betöltődésekor a form-textarea osztályokhoz hozzárendeljük a focus() és blur() fgv-eket.
Amikor egy textarea-ba bekattint (focus) a felhasználó a writing változó értéke igazra változik, amikor elhagyja (blur) hamisat vesz fesz vel.
A node_edit bool tipusú változót azért hozzuk létre, mert a későbbiekben a hook_form_alter()-t fogjuk használni a js beépítésére, ez azonban nem csak a node-ok szerkesztésénél fut le, hanem például a felhasználók kezelési felületén is. Ezért megvizsgáljuk, hogy a node-form létezik-e, és csak akkor futtatjuk a kódót ha igen.

A billentyű lenyomása, a keypress(function).
Ezt magához az oldalhoz ($(document)) kell hozzárendelni, hiszen nem valamely beviteli mezőt figyeljük.
A fgv paramétere az event változó, ez tartalmazza a billentyűlenyomás tulajdonságait.
A keyCode a lenyomott billentyű ID-ját tartalmazza ami egy egész. Az ENTER gomb kulcsa a 13-as szám.
Emiatt a feltételben megvizsgáljuk, hogy a 13-as kódszámmal rendelkező billentyű lett-e lenyomva (ENTER), és hogy éppen folyik-e a gépelés (writing változó).
Ha a feltételnek megfelelőek az értékek és a felhasználó megerősítette (confirm_submit), hogy befelyezte a szerkesztést akkor végrehajtjuk a node mentését.

Lehetséges, hogy a

sor egy kis magyarázatra szorul.

Az node-form a form id attributuma.
Gondolhatnánk a legegyszerűbb meghívni a submit eseményt a submit() fgv-el. A probléma az, hogy a node szerkesztési felületén három submit gomb van: beküldés, előnézet, törlés. Emiatt a submit esemény nem egyértelmű, hiszen mind a három gomb, ugyanannak a form-nak a submit gombjai, és mindegyik mást csinál. Emiatt nem történik semmi.
A következő gondolat az, hogy oldajuk meg a problémát az edit-submit id-jú gomb click esemény meghívásával.
Ezzel a gond az, hogy a Drupal beépített form-jainak mind ez az azonosítója. Így pl ha engedélyezve van a search modul akkor annak a submit gombaja is ugyanezzel az id-val rendelkezik, tehát könnyen előfordulhat, hogy az enter lenyomása mondjuk keresést eredményez, nem pedig a tartalom elmentését.
Ezért magában a form-ban kell megkeresnünk a megfelelő gombot, viszont form-on belül nem lehet html objektumot keresni, ezért a form-ot körülölelő div-ben kell megtennünk.

Az utolső fgv. a megerősítés, vagyis rákérdez a felhasználótól, hogy valóban mentsük-e a tartalmat.

Ez a jQuery megvalósítás működik, mostmár csak be kell építeni a site-ba.

Mivel ennek a JavaScript-nek csak és kizárólag a node szerkeztési felületén kell megjelnnie, így a hook_form_alter()-t a legérdemesebb használni.

A modulunk, tehát az .info fájlon kívül ennyi:

A modul letölthető innen:
enter_node_submit.module

Sokszor felmerül a kérdés, hogy lehet a form mezőinek kitöltöttségét egyszerűen és újrahasznosíthatóan megírni.

Erre egy nagyon jó megoldást ad a jQuery JavaScript könyvtár.
A lényeg az, hogy egy kód megírásával lehessen ellenőrizni az oldalon található összes form kötelező mezőinek kitöltöttségét, függetlenül attól, hogy mely formnak hány kötelező mezője van.

Ehez fontos, hogy a form-okat a megfelőle stratégia szerint építsük fel…a lényeg a helyes osztályok használata. Ha a megfelelő input mezőket a megfelelő osztályokba soroljuk, akkor a megoldás néhány sor JS-el megoldható, és el lehet sütni akármikor a jövőben is.

Néhány napja az egyik ügyfelünknek kellett elkészítenem egy site részletet, ahol az oldalak összességét tekintve, kb. 20 formot kellett elhelyezni, namost ez sok, és ha mindet a szabványos JS módszerekkel próbáltam volna ellenőrizni (a mezőket ID alapján lekérdezem és ellenőrzöm, hogy ki van-e töltve), akkor sok kódot kellett volna írni, valamint a hibalehetőség is nagy. Ahol nagy a hibalehetőség azt minimum tízszer annyi idő tesztelni, mint egy megfelően elkészített form ellenőrzést.

Vegyünk egy egyszerű példát egy négy mezőböl álló form-ra, melynek három kötelező mezője, amiből az egyik email, tehát az email cím valósságát is ellenőrizni kell.

A form a következő képp néz ki:

Menjünk szépen végig a kódon mikre kell figyelni, mik a lényeges részletek!
Nyilván nem a CSS-en van a lényeg, az csak az elrendezés miatt van.
Ha megnézzük az egész form egy div-be helyezkedik el, és osztályba van sorolva. Ez nem véletlen. A későbbiekben ezen div adott osztályain fogunk végigmenni, és ellenőrizni a kitöltöttség helyességét. Azért nem a form-on, mert a mezők a div-hez tartoznak, nem pedig a form-hoz, tehát a formon belül nem tudunk osztályokat keresni.
A felépítést tekintve megfigyelhetjük, hogy a mezőknek van id paraméterük és egy label követi. Ez fontos és sokan elfelejtik. Egy modert formban a mező címére kattintva is a mező válik aktívvá, ez különösen pl. a checkbox-oknál igaz. Gondoljunk bele, milyen rosz megoldás ha van egy checkbox mellette egy sor szöveg, és csak akkor válik kiválaszottá a checkbox ha a kis négyzetébe kattintuk, ha a szövegre akkor nem történik semmi. Erre teljesen tökéletes a mező id és a label for párosítás.
A három kötelező mező a Vezetéknév, Keresztnév, és Email cím. Ezeket a kotelezo osztályba soroljuk. Megfigyelhetjük az Email cím mellett ott van az email oszály tag is. Itt megjegyezném, hogy ha egy HTML elemet szóközökkel elválasztva osztályokba sorolunk az azt jeleni, hogy az összes adott osztályba tartozik. Tehát például az Email cím az egyszerre tartozik a register-input-narrow, a kotelezo és az email osztályokba.

Nézzük meg a hozzá tartozó jQuery kódot:

Láthatjuk, hogy az oldal betoltődésekor fut le a kód. Végigmegyünk az összes feliratkozo-form osztályon és lekezeljük a submit eseményét. Ebbe az osztályba soroltuk be az oldalon talalhátaó összes ellenőrizendő form-ot.
Eztán végigmegyünk az összes olyan input mezőn amit a kotelezo osztalyba soroltunk, és a form szülő objektumába tartozik. Ez az objektum az a div amibe elhelyzetük a form-ot.
Ha valami nincs kitöltve akkor a mehet változót hamis értékre állítjuk.

Ha a mehet változó értéke nem igaz, akkor alert ablakban informáljuk a felhasználót a hiba okáról és hamis értékkel térünk vissza a ciklusból, tehát nem fog lefutni a submit esemény. Ha igaz akkor folytatjuk a további szükséges ellenörzéseket. ez jelen esetben az email cím helyessége.

Miután minden szükséges ellenőrzést megtettünk az adatok függvényében fut le a submit esemény, az oldalon elhelyezett akárhány form esetén.

Előnye hogy pár sor, nem függ a form mezőinek számától és lényegesen lerövidül a tesztelés időtartalma. Az osztályokkal való mezőellenőrzés ha működik egy form-ra akkor működik a többire is, ha nem működik akkor semmelyiknél se fog.

Természetesen olyan ellenőrzésekre is szükség lehet mint például hogy egy legördülő select-ből mindenképpen válasszon az felhasználó egyet, de azt is hasonlóképpen bele lehet vinni a kódba.

Biztos sokakban felmerült már a kérdés, hogy hogyan lehet olyan hyperlink-et készíteni ami új ablakban nyílik meg, mégis valid.

Ugyebár megvan a lehetőség HTML segítségével új ablakba nyíló hivatkozás készítésére, de sajnos a hyperlink-nek nincs valid target attributuma.

A kellő eredményt hozza a következő kódrészlet, de nem sajnos nem lesz valid:

Én a megoldásra a jQuery JavaScript könyvtárat használom. Ez amúgy alapól benne van a Drupal CMS-ben. Egy nagyon egyszerű eljárást alkalmazok:
Azokat a hyperlink-ekekt amiket új ablak szeretnénk megnyitni elhelyezem a new_window osztályba, és az oldal betöltődésekor a jQuery segítségével helyettesíthetem a target=”_blank” paramétert.