CSS

Drupal-ban az elsődleges linkek (primary links) helyére képek a themes_links() fgv. kifejtésével

Nekem már többször előfordult olyan problémám, hogy a Drupal elsődleges menüjének (primary links) egyedi kinézete miatt, kizárólag képekből álló menüt kellett készítenem. Ezalatt azt értem, hogy nincs a háttérkép felett semmilyen szöveg, a menü címe is a képen szerepel.

A háttérképeket egyszerűen megadhatjuk, a menüpontok egyedi azonosítója miatt (pl. menu-130 stb.), viszont a rajta lévő szöveget el kell tüntetni valahogy.

CSS-ben ha levesszük a betűméretet 0px-re sajnos nem a megfelelő megoldás, mert IE-ben, Chrome-ban és Operában kicsiben, de látszik.

Egy megoldás, ha a hyperlinkek szövegét span elemek közé tesszük, és a span elemeket tüntetjük el CSS-ben a display: none; definícióval, tehát a cél az lenne, hogy így nézzen ki egy menüelem:

<li class="menu-129"><a class="menu-129" href="/"><span class="primary-title">Nyitólap</span></a></li>

Ekkor minden további nélkül megadhatjuk CSS-ben a következőt:

ul.primary-links span.primary-title {
display: none;
}

Igenám, de hogy érjük el, hogy a Drupal span elemek közé tegye a linkek címét?

A megoldás az, hogy a sminkünk template.php fájljába kifejtjük a theme_links() fgv-t.

Íme a kód:

/**
 * Csak kepekbol allo menu elkeszitesenek alapjai
 *
 * @param unknown_type $links
 * @param unknown_type $attributes
 * @return HTML
 */
function phptemplate_links($links, $attributes = array('class' => 'links')) {
  global $language;
  $output = '';
 
  if (count($links) > 0) {

Internet Explorer vs. PNG átlátszóság

Észrevehetjük, hogy az Internet Explorer régebbi verziói nem tudják támogatni a PNG fájlokat. A jelenség az, hogy nem kezeli az átlátszóságukat, és ez elég nagy probléma mivel (sajnos) a mai napig is a felhasználók legnagyobb része IE6-ot használ.

Szerencsére erre is van megoldás, nem is bonyolult, nem is sok idő megoldani.

Mindösszesen három fájlra lesz szükségünk:

Az első css fájlt a Conditional Comment feltételes megoldással kell beilleszteni a weboldalunkba (Drupal CMS esetén a page.tpl.php fájlba):

<!--[if lt IE 7]>
  <link rel="stylesheet" href="http://www.kalman-hosszu.com/ie-fix/ie.css" type="text/css" media="screen" />
<![endif]-->

Ezzel elérjük azt, hogy az IE7 előtt böngészőknél hozzáadja az oldalhoz az ie.css fájlt is.

Ha megnézzük ennek a css fájlnak a tartalmát akkor láthatjuk, hogy hova kell elhelyezni a többi fájlt:

img {
  behavior: url(/images/png.htc);
}

Tehát az itt megadott könyvtárba (esetemben /images) elhelyezzük a png.htc és a transparent.gif fájlokat, és IE alatt is használhatunk PNG képeket.

jQuery show() hiba: táblázatok soraira (table tr) nem érvényes, a táblázat szétcsúszik

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:

 block

Vagy így:

 table-row

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.

<script type="text/javascript">
function show_tr_element(object) {

DropDown menü készítése jQuery-vel és a velejáró IE-fix

Ü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:

DropDown menü FF

Az internet Explorerben elég érdeksen mutatott:

DropDown menü IE

DropDown menü IE

DropDown menü IE

From mező ellenőrzés DHTML-el és jQuery JavaScript könyvtárral

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:

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

<style type="text/css">
.form-row {
  padding-bottom: 10px;
  width: 290px;
}
 
.form-row label {
  float: left;
  width: 100px;
  padding-right: 10px;
}
 
.form-row input {
  float: left;
  padding: 3px;
  width: 160px;
}
 
.clear {
  clear: both;
}
 
.form-error {
  text-align: center;
  color: #C52020;
  border: 1px solid #DD7777;
  background: #FFCCCC;
  margin: 10px 0;
  display: none;
}
</style>
 
<div style="margin: 0 auto; width: 300px;">

Az alapok: fejlszetőkörnyezetek, avagy minden jobban megy ha látom

Mert ugye, hiába a jó munkamódszer, ha rosz szofvereket használunk!

Hihetetlen, hogy mennyiben meg tudja könnyíteni, vagy éppen nehezíteni egy fejlesztőkörnyezet a programozó dolgát. Ha nem megfelelő a szoftver amit használunk, nagyon sok időt veszítünk, és párhuzamosan rengeteg ideget nyelünk. Semmelyik se valami jó ráadásul a kettő hatással van egymásra. Ha valami miatt egy egyszerű feladaton sokat kell dolgozni, akkor az felidegesít, es ha felidegesít akkor még lassabb lesz a munka...és ez így megy körbe-körbe, amíg a végén mar teljesen értékelhetetlenné válik az ember munkája.

Ugyebár ezt szeretnénk elkerülni ha egy mód van rá :-)

Létezik ennek az ellenkezője is, amit nagyon könnyen meg lehet szokni, és utána már teljesen természetessé válik, hogy az időm nagyrészét kreatív munkával tudom tölteni, nem pedig a forráskódom helyesírási hibáinak javításával, vagy éppen azzal, hogy az átláthatan szerkesztőbe kétszázadjára siklok el a megoldandó probléma felett.

A kód szerkesztésére én a Zend Studio-t javaslom. Pont annyit tud amennyit egy PHP fejlesztőkörnyezetnek tudnia kell. Kitölti a változókat, ismeri a php beépített fgv-eket és a leírásukat, tehát ha elkezdem beírni a fgv nevét, kiírja a lehetőségeket, melyik milyen paramétereket vár stb. Érzékeli a szintaktikai hibákat, és jelzi mi a gond...egy szóval pont arra jó amire akjuk használni.
Külön megemlíteném, hogy van Windows és Mac OS X rendszerre is.

Aztán van a css. Végülis a Zend is be tudja tölteni ezt a feladatot, de én sokkal jobbat használok.