objektum-orientált css i.

Úgy hangzik, mint egy oximoron vagy inkább badarság, nem igaz? Hogy lehetne egy statikus nyelv, ami inkább leírónyelv mint programnyelv objektum-orientált? A következő cikkben ebbe vezet be minket Andrew Burgess a NetTuts+ hasábjain. Aki szeretné letölteni a forráskódot, az az eredeti cikk mellett megtalálja.

Mi az az objektum-orientált CSS?

Az objektum-orientált css, alapvetően nem más mint egy tisztább, újrafelhasználhatóbb CSS. Ez nem egy új nyelv, "csupán" csak egy paradigma váltás. Valójában az objektum-orientált CSS néhány egyszerű minta és ajánlás.

Szóval akkor miért is objektum-orientált? Nos, a Wikipédián ez olvasható:

Az objektum-orientál programozás (OOP) egy programozói paradigma, ami "objektumokat" — adat struktúrákat, amik adatmezőkből és metódusokból épülnek fel — és azok kölcsönhatásait használja az alkalmazások és számítógépes programok megtervezéséhez.

(A fenti idézet az angol Wikipédia bejegyzés magyar fordítása - Thoer)

Ha ezt a definíciót át akarjuk írni CSS-re, akkor az a következőképp nézhetne ki:

Az objektum-orientált CSS az egy kódolási paradigma, ami "objektumokat" és "modulokat" - egymásba-ágyazható HTML kódrészletek, amik meghatározzák egy weboldal egy részét - ruház fel stílussal robusztus, újrafelhasználható stílusokkal.

Ez gyakorlatilag azt jelenti, hogy standardizáltuk az objektum fogalmat, ami a HTML struktúra, és vannak CSS osztályok, amiket az objektumainkra alkalmazunk és amik meghatározzák az objektumunk dizájnját és elrendezését.

Mi van a teória mögött?

Két fő alapelv van az objektum-orientált CSS mögött: az egyik a struktúra elkülönítése a dizájntól (szkintől) és a második a konténer elkülönítése a tartalomtól.

Ez az idézet Nicole Sullivantől van, aki az objektum-orientált CSS szülőanyja. Szóval, hogyan néznek ki ezek az alapelvek a megvalósítás szintjén?

A struktúra elkülönítése a dizájntól természetesen bármilyen módon megvalósítható, de érdemes valamilyen CSS keretrendszert használni hozzá. Több elterjedt rendszer létezik, de természetesen létrehozhatod a sajátodat is. Ha nem használsz keretrendszert, akkor valószínűleg az oldalad elsődleges objektum struktúráját határozod meg, mi is ezt fogjuk most tenni.

A konténer és a tartalom elkülönítése azt jelenti, hogy az objektumot (a konténert) fel kell készíteni mindenféle adat megjelenítésére. Például anélkül is megfelelően kell kinéznie, hogy kikötjük, hogy egy h3-as fejléc után egy rendezetlen lista lista lesz benne elhelyezve. Ez rugalmasságot és újrahasznosíthatóságot eredményez, ami tulajdonképpen maga a cél. Emellett a stíluslapjaid is kisebbé válnak és rendszerezettebbek lesznek. Ennek következménye, hogy egy későbbi dizájn módosítás vagy újrastrukturálás is könnyebb lesz.

Hogyan működik az objektum-orientált kódolás?

Az első lépés mindenképpen a HTML felkészítése. Általánosságban az objektumaidnak lesz egy fejléce, egy törzse és egy lábléce. Így néz ki egy alap-objektum:

<div class="object">
<div class="head"></div>
<div class="body"></div>
<div class="foot"></div>
</div>

Mielőtt bárki rosszul lenne a sok div-től, jegyezzük, meg hogy ez csak a manapság elterjedt HTML4-ben néz ki ennyire csúnyán. HTML5-ben ez sokkal szemantikusabbnak tűnik:<article>
    <header></header>
    <section></section>
    <footer></footer>
</article>

Ebben a cikkben, többek között a jobb olvashatóság kedvéért, ezt a verziót fogjuk alkalmazni, ez lesz az objektumunk. Természetesen egy éles weboldal készítésekor mérlegelni kell a html5 használatának lehetőségeit és hátrányait is, legalábbis a cikk megírásakor és fordításakor még ez a helyzet.

Gyorsan állítsunk össze egy tesztoldalt, legyen egy blog kezdőoldala egy poszttal, mint tartalom. Vigyázat, mi most HTML5 és CSS3 markupot is használni fogunk, de az objektum-orientált CSS "hagyományos" eszközökkel is megvalósítható!

index.htm

<!DOCTYPE html>
<html>
  <head>
    <meta charset='utf-8' />
    <title>Object Oriented CSS</title>
    <!--[if IE]><script src="http://nettuts.s3.amazonaws.com/450_ooCss/http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
    <!-- This makes IE recognize and use the HTML5 elements -->
    <link type="text/css" rel="stylesheet" href="css/reset.css" />
    <link type="text/css" rel="stylesheet" href="css/text.css" />
    <link type="text/css" rel="stylesheet" href="css/styles.css" />
  </head>
  <body>
    <article id="container">
      <header>
        <h1>Object Oriented CSS</h1>
        <h2 class="subtitle">(really just a bunch of best practices and patterns; not a new language)</h2>
        <nav>
          <ul>
             <li><a href="index.htm" class="selected">Home</a></li>
             <li><a href="=post.htm">Archives</a></li>
             <li><a href="#">About</a></li>
             <li><a href="#">Contact Us</a></li>
          </ul>
        </nav>
      </header>

      <section>
        <article class="post">
          <header>
            <span class="date">September 10, 2009</span>
            <h2><a href="post.htm">Check out WorkAwesome!</a></h2>
          </header>
          <section>
            <img src="http://nettuts.s3.amazonaws.com/450_ooCss/img/wa.jpg" alt="Work Awesome" />
            <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse quis urna dui,
            ut tempus tortor. Aliquam enim massa, porta a vehicula in, vehicula at lectus. Ut turpis
            diam, porttitor a iaculis quis, bibendum non lectus. Nullam vitae erat a felis pulvinar
            tempor ut id leo. Aenean accumsan feugiat ultrices. Duis rhoncus eros id odio faucibus
            imperdiet. Nulla nibh mauris, placerat sagittis placerat sed, commodo in mi.</p>
          </section>
          <footer>
            <ul>
              <li><a href="#">Read More . . .</a></li>
              <li><a href="#">Retweet!</a></li>
              <li><a href="#">Comments (4)</a></li>
            </ul>
          </footer>
        </article>
        <article class="post ext">
          <header>
            <span class="date">September 7, 2009</span>
            <h2>The Intro Post</h2>
          </header>
          <section>
            <img src="http://nettuts.s3.amazonaws.com/450_ooCss/img/wa.jpg" alt="Work Awesome" />
            <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse quis urna dui,
            ut tempus tortor. Aliquam enim massa, porta a vehicula in, vehicula at lectus. Ut turpis
            diam, porttitor a iaculis quis, bibendum non lectus. Nullam vitae erat a felis pulvinar
            tempor ut id leo. Aenean accumsan feugiat ultrices. Duis rhoncus eros id odio faucibus
            imperdiet. Nulla nibh mauris, placerat sagittis placerat sed, commodo in mi.</p>
          </section>
          <footer>
            <ul>
              <li><a href="#">Read More . . .</a></li>
              <li><a href="#">Retweet!</a></li>
              <li><a href="#">Comments (4)</a></li>
            </ul>
          </footer>
        </article>
        <article class="post">
          <header>
            <span class="date">September 5, 2009</span>
            <h2>Welcome</h2>
          </header>
          <section>
            <img src="http://nettuts.s3.amazonaws.com/450_ooCss/img/wa.jpg" alt="Work Awesome" />
            <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse quis urna dui,
            ut tempus tortor. Aliquam enim massa, porta a vehicula in, vehicula at lectus. Ut turpis
            diam, porttitor a iaculis quis, bibendum non lectus. Nullam vitae erat a felis pulvinar
            tempor ut id leo. Aenean accumsan feugiat ultrices. Duis rhoncus eros id odio faucibus
            imperdiet. Nulla nibh mauris, placerat sagittis placerat sed, commodo in mi.</p>
          </section>
          <footer>
            <ul>
              <li><a href="#">Read More . . .</a></li>
              <li><a href="#">Retweet!</a></li>
              <li><a href="#">Comments (4)</a></li>
            </ul>
          </footer>
        </article>
      </section>
      <aside>
        <article class="side-box">
          <header>
            <h3>Archives</h3>
            <p>look into the past</p>
          </header>
          <section>
            <ul>
              <li><a href="#">August 2009</a></li>
              <li><a href="#">July 2009</a></li>
              <li><a href="#">June 2009</a></li>
              <li><a href="#">May 2009</a></li>
              <li><a href="#"> . . . </a></li>
            </ul>
          </section>
        </article>
        <article class="pop-out side-box">
          <header class="post-it">
            <h3>Recent Comments</h3>
            <p>see what folks are saying</p>
          </header>
          <section>
            <ul>
              <li>
                <p>I think oocss is really cool!</p>
                <p class="meta">By J. Garret on Sept 12, about "The Intro Post"</p>
              </li>              
              <li>
                <p>Are you kidding? CSS can't ever be Object Oriented.</p>
                <p class="meta">By Joe Thomas on Sept 11, about "The Intro Post"</p>
              </li>              
              <li>
                <p>Envato has done it again; workAwesome is simply awesome!</p>
                <p class="meta">By GV on Sept 10, about "Check out WorkAwesome"</p>
              </li>              
              <li>
                <p>I really like the site's desing; another work of art from Collis.</p>
                <p class="meta">By Anonymous on Sept 10, about "Check out WorkAwesome"</p>
              </li>            
            </ul>
          </section>
        </article>
      </aside>

      <footer>
        <ul>
          <li>Standard</li>
          <li>Footer</li>
          <li>Information</li>
          <li>Yada</li>
          <li>Yada</li>
          <li>© 2009</li>
        </ul>
      </footer>

    </article>
  </body>
</html>

Grafikusan valahogy így fest a fenti kód doboz-modell szinten:

layout

Ismerős? Ez pontosan a mi objektumunk, csak a body két részre van osztva, a section és aside részekre. Mindjárt megnézzük a blogposztunkat is, de először nézzük meg a CSS-t.

Ha figyelmesen átolvastad a fenti html kódot, akkor észrevehetted, hogy három stylesheetet importáltunk be. Az első, a reset.css,h Eric Meyer reset stylesheetje. A második, a text.css fájl az objektum-orientált css egy fontos eleme, mely szerint az alapelemeket a designra vonatkozó stílusok előtt érdemes megadni. Ilyenek például a listák és fejléc elemek szövegre vonatkozó beállításai. Ezek a stílusok jó esetben az egész website részét képezik és egy konzisztens, átgondolt design benyomását keltik. Ezek az elemek általában aztán nem kapnak további stílust

A jelenlegi text.css-ünk a következő képpen néz ki:

body { font: 13px/1.6 Helvetica, Arial, FreeSans, sans-serif;}
h1, h2, h3, h4, h5, h6 { color:#333; }
h1 { font-size: 50px; text-shadow:1px 1px 0 #fff; font-family:arial black, arial}
h2 { font-size: 23px; }
h3 { font-size: 21px; }
h4 { font-size: 19px; }
h5 { font-size: 17px; }
h6 { font-size: 15px; }
p, h1, h2, h3, h4, h5, h6, ul { margin-bottom: 20px; }
article, aside, dialog, figure, footer, header, hgroup, menu, nav, section { display: block; }
Az első ténylegesen a weboldalra vonatkozó feladatunk az alap struktúra felépítése:

#container                                   
  { margin:40px auto;
    width:960px;
    border:1px solid #ccc;
    background:#ececec;
  }
  #container > header, #container > footer                        
    { padding:80px 80px 80px;
      width:800px;
      overflow:hidden;
      border: 1px solid #ccc;
      border-width:1px 0 1px 0;
    }     
  #container > header                        
    { background:url(../img/header.jpg) repeat-x #d9d9d7;
    }
    #container > header li, #container > footer li
    { float:left;
      padding:0 5px 0 0;
      background:none;
    }
  #container > section                       
    { background:#fdfdfd;
      padding:0 40px 40px 80px;
      float:left;
      width:493px;
      border-right:1px solid #ccc;
    }
  #container > aside                         
    { padding-top:20px;
      float:left;
      width:346px;
    }
  #container > footer                        
  { padding:40px 80px 80px;
    background:#fcfcfc;
  }
    #container > footer li:after             
    { content:" |"
    }
      #container > footer li:last-child:after
      { content:""
      }

Nézzük mitől lesz ez a stíluslap objektum-orientált. Előszöris, nem limitáltuk az osztályunkat egy adott elemhez. Ezzel megvalósítottuk a lehető legnagyobb flexibilitást, bármilyen elemre rá lehet húzni a stílusunkat. Aztán észre kell még venni, hogy nem adtunk meg szélességeket és magasságokat ezzel segítve a struktúra és a design szétválasztását. 

Ezen kívül minden elemnek egy elem-független módon adtunk stílusjegyeket. A szülő elemek nem igénylik bármilyen gyerek-elem jelenlétét, habár adtunk a gyerek-elemeknek stílust, de semmi nem fog megváltozni, ha nincsenek gyerek-elemek. Így például a h2 elem nem kapott külön stílust a dobozunkban, mert annak illik konzisztensnek maradni az oldalon szereplő többi h2 elemmel, amit viszont már meghatároztunk a text.css fájlban.

Van még egy érdekes rész a kódban, ami talán a legjobban emlékeztet az objektum-orientált programozásra, ez pedig a kiterjesztett osztályok esete. Valószínűleg feltűnt, hogy mint a .post img mind a .post.ext img kiválasztók (avagy szelektorok) definiálva lettek. Valószínűleg tudod, hogy ezek hogy működnek, de minden esetre itt egy kép szemléltetésképpen:

postext

Szimplán azzal, hogy hozzáadunk még egy osztály az objektunkhoz, megváltoztathatunk kisebb stílusbeli sajátosságokat. Fontos, hogy a két osztály közé ne rakjunk szóközt, mert az mást jelent! A .post.ext img kiválasztó egy post és ext osztállyal is rendelkező elemben definiált képeket keres, a .post .ext img kiválasztó viszont egy post osztállyal rendelkező elemben definiált ext osztályú elemben keres img elemeket.

A váz tehát megvan, a folytatásban részletesen bemutatásra kerülnek az egyes oldalemek is.

Címkék: css html5 css3

php keretrendszerek ii.

Az előző részben ott tartottunk tehát, hogy ma már nem feltétlen a CodeIgniter a kedvenc keretrendszerem, de mielőtt továbbmennék meg kell jegyeznem, hogy ez nem egy keretrendszer-összehasonlító teszt, csupán egy szubjektív poszt a témáról.

Szóval ott tartottam, hogy a CodeIgniter már-már tökéletes megoldás. Igen ám, csak hogy a fejlesztői nem a keretrendszer támogatásából élnek, hanem egy fizetős tartalomkezelő rendszerből, amit ugyan folyamatosan portolnak a keretrendszer alá, de a CodeIgniter magjának fejlesztésére mintha nem jutna elegendő energia. Másfelől a fejlesztő cég feje is elismerte, hogy ők a keretrendszert a lehető legminimálisabb szinten akarják tartani. Tulajdonképpen nincs is ezzel baj, azonban ismét kezdtek előjönni azok a problémák, hogy mások kódját kezdtem el használni kisebb-nagyobb problémák megoldásához, amikor nem akartam újra feltalálni a kereket. Igaz ez immár sokkal egységesebbnek tűnt, lévén mindegyik a CodeIgniter filozófiáját és kódolási stílusát követte, de megesett, hogy három projektben három különböző megoldást voltam kénytelen használni valamiért egy adott problémára.

Egyszer aztán egy komolyabb munka miatt több új és több régi könyvtárat kellett volna beépítenem a weboldalba. Körülnéztem és akármelyiket néztem, mindegyik felmerülő problémára találtam egy Kohana könyvtárat, amit a Kohana fejlesztői írtak, dokumentáltak és támogattak. Aki esetleg nem ismerné a Kohanát, annak mondom, hogy itt egy olyan keretrendszerről van szó, amit eredetileg a CodeIgniterrel elégedetlenkedő felhasználók írtak és amennyire tudom az eredeti kód alapja is maga a CodeIgniter volt. A történelmének nagyon nem jártam utána, de amennyire tudom, az elégedetlenség fő oka a CodeIgniter php4 támogatása volt, mert szerintük emiatt a kód nem elég tiszta, stb. Na most annak idején (talán még 2008 elején) én nézegettem a Kohanát, de akkor nekem még egyfelől a php4 támogatás mindig fontos volt, másrészt a Kohana akkoriban nagyon rosszul volt dokumentálva. Most viszont ott találtam magam egy projektben ami eleve php5-ös szerveren futott, másfelől azt találtam, hogy a Kohana dokumentációja nagyságrendileg azonos részletességű, mint a CodeIgniteré, ráadásul a két projekt szintaxisa, felépítése is igencsak hasonló. Elkezdtem hát használni a Kohanát és pillanatokon belül azon kaptam magam, hogy ez a rendszer maga a Kánaán. Az ORM rendszere, az Auth modul, a cache támogatás és a fájl kaszkádlás mind-mind azonnal megnyertek maguknak. Ráadásul szerintem a sebessége se rosszabb, mint a CodeIgniternek, noha a Hello World jellegű versenyekben rendre alulmarad a CodeIgniterrel szemben.

A Kohana fejlesztése ráadásul elég ütemes, igaz a jelenlegi tervek szerint a Kohana fejlesztői a Drupálhoz hasonlóan két verzió egyidejű támogatását tervezik, amikhez meglátásom szerint kicsi a támogató team. Mindenesetre hamarosan jön a Kohana 3. verziója, benne az ígéretek szerint minden földi jóval. Majd meglátjuk.

Ami viszont biztos, hogy jelenleg a Kohana kettes verziója stabil és nagyon jó szoftver a maga nemében, viszont sajnos erősen épít a Singleton tervezési modellre, ami nagyon egyszerű, a maga módján hasznos is, viszont tesztelhetőségi szempontból nagyon káros. Hogy ez alatt mit kell érteni azt igyekszem minél hamarabb kifejteni, most maradjunk a témánál.

A korábban említett összetett projekt immár fél éve zajlott, amikor igazán megértettem, hogy mennyire fontos az állandó tesztek futtatása. Idő közben kísérleti jelleggel belecseppentem a Kohana tesztelési projektjébe is, majd magam is kezdtem behatóbban megismerkedni a dologgal. Először talán a Google Talk videók között leltem néhány hasznos előadásra (Unit Testing, Inheritance, Polymorphism & Testing, Global State & Singletons, Don't Look for Things!) és meg sem álltam Miško Hevery blogjának átolvasásáig. Valószínűleg ebben a témában fogok először komolyabban elmerülni a blogomon, de addig is, akinek kedve van, nézelődjön a fenti linkeken, csak hasznára válhat.

Na jó, tehát arra már rájöttem, hogy a Kohana nem a legjobban tesztelhető rendszer a világon, gondoltam ideje szétnézni, hogy vannak-e profibb rendszerek. Az első számomra valamelyest egyértelmű lépés az volt, hogy a már korábban már kerülgetett, de valahogy mindig túl bonyolultnak találtatott Zend Framework-öt vettem górcső alá. Azt addig is tudtam, hogy a Zend mögött komoly bázis áll, hiszen eleve ők "A PHP's cég", legalábbis saját állításuk szerint biztosan. A Zenddel való ismerkedésem sajnos sokkal nehézkesebb volt, mint a két könnyűsúlyú rendszer esetében és ennek első számú oka az volt, hogy a bevezetőnek szánt oktató cikk egész egyszerűen nem működött, ha az ember Windows alól próbálta meg követni. Később aztán megkerestem a hibát és el is küldtem a fejlesztői gárdának, úgyhogy most már gyanítom mindez működik. Ezalatt és némileg ez után még jobban elmerültem a kódban és a dokumentációban és el kellett ismernem, hogy elképesztő mennyiségű minőségi munka van a projektben. Ugyanakkor azt továbbra is meg kellett állapítanom, hogy a Zend Framework használata elsőre (és másodszorra is) elég nehézkes, viszont valószínű, hogy ha az ember készség szinten elsajátítja, akkor nagyon jól testre szabható alkalmazások készíthetőek vele.

Ami a Zendben jól láthatóan különbség mondjuk egy CodeIgniter rendszerhez képest az számomra a következő:

  • A ZF mindenre, a CodeIgniter csak a legnyilvánvalóbb feladatokra kínál megoldást

  • A ZF gyakorlatilag teljesen moduláris, tehát csak azt a részét kell betölteni, amit az ember ténylegesen használ, míg a CodeIgniter néhány osztályt mindenképp betölt

  • ZF-ben az egyes megoldások részletesen ki vannak dolgozva, sokszor alternatívákkal együtt, a CodeIgniterben ezzel szemben a legtöbb feladat megoldása 1-1 okos kis osztályban merül ki, melyek viszont sokszor túl sok feladatot végeznek el.

  • A CI jelentősebb módosítások nélkül csak MVC stílusban használható, a ZF az MVC-t támogatja és ajánlja, de nem teszi kötelezővé.

  • Fentiek miatt a ZF-ben egy Hello World sebessége elvileg megegyezik egy PHP "Hello World"-del (lévén nem kell betölteni hozzá semmit a rendszerből), viszont ha már MVC keretrendszerként akarjuk használni, akkor lehet, hogy lassabb lesz, mint a CI. Ugyanakkor ez véletlen sem jelenti, hogy rosszabb hatékonysággal lenne megírva, egyszerűen csak sok több funkciót implementáltak, hogy meggyorsítsák egy komoly fejlesztés érdemi részét.

És ha már tesztelhetőségről ejtettünk szót, mint fő mozgató rugó a Kohana elhagyásában, említsük meg, hogy a ZF-ben ez a probléma önmagában nem létezik, ugyanis ott ezeknek a Singletonoknak a kezelése vagy kikerülése a programozó dolga, emiatt viszont érdemben mondhatjuk, hogy a ZF jól tesztelhető keretrendszer. Igen ám, de a ZF azért arra nem ad választ, hogy hogyan kerüljük el a Singletonok használatát. Pontosan erről fog szólni viszont a harmadik a sorozat következő része.

Címkék: php keretrendszerek

kedvenc szöveghelyettesítési technikám

Gyakori probléma, hogy vagy valamilyen egzotikus betűtípust szeretnénk használni a címsorok helyett vagy rögtön valamilyen képet. A probléma gyakorlatilag egyidős az internettel (de legalábbis a Netscape-pel) és rengeteg megoldás látott már eddig is napvilágot. Tökéletesnek egyik IR (Image Replacement) eljárás sem nevezhető, vagy keresőmotor-optimalizálás szempontból vagy bizonyos technológiai megkötésekből mindegyiknek van gyenge pontja, épp ezért szinte mindegyik technikának van létjogosultsága is. Egészen biztosan sok erre vonatkozó ötletet és tippet fogok idővel bemutatni, köztük lesz valószínűleg egy fordítása is Chris Coyier cikkének, melyben 9 css alapú képcsere technikát mutat be és hasonlít össze.

Most viszont egy olyan verziót fogok ismertetni, ami nem szerepel Chris cikkében és ami az én személyes kedvencem: A Malarkey metódust (MIR).

Hogy miért ez a kedvencem? Mert végtelenül egyszerű és szinte minden böngészőben működik. Először is semmilyen hozzáadott HTML tag-re, semmilyen JavaScriptre vagy Flash meghívására nincs szükség. Egyetlen hátránya, hogy bekapcsolt css és kikapcsolt képekkel való böngészés esetén nem látszik sem a szöveg, sem a kép. Keresőmotorok és felolvasó programok viszont minden további gond nélkül megtalálják az eredeti szöveget.

És a megoldás: az elrejteni kívánt szövegre, alkalmazzunk egy negatív betűtávolságot. Ha minden "mir" osztályú elem helyett a "replace.jpg" képet szeretnénk megjeleníteni, ahhoz a következő css stílust kell létrehozni:

.mir {letter-spacing: -1000em; background-image: url(replace.jpg);}

És hogy milyen böngészőkön működik? Csak egy rövid lista még 2007-ből:

  • Windows Firefox, Mozilla 1.6
  • Windows Internet Explorer 6, Internet Explorer 5.5, Internet Explorer 5.0
  • Windows Netscape 8, Netscape 7.1
  • Mac Firefox
  • Mac Safari
  • Mac Internet Explorer

Talán sokaknak feltűnt, hogy az Opera nem szerepel a listában. Ez sajnos egy Opera bug miatt van, aminek gyors-javítása pedig az Internet Exploreres megjelenítést elrontja Macintosh alatt, ezért egy olyan hacket kell használni, ami csak az Operát célozza meg. Ezzel a hackkel együtt a teljes kód a következő:

.mir { letter-spacing : -1000em; }
/* Just for Opera, but hide from MacIE */
/*\*/html>body .mir { letter-spacing : normal; text-indent : -999em; overflow : hidden;}
/* End of hack */
Címkék: seo css tipográfia

php keretrendszerek i.

Talán csak magamból indulok ki, de azt hiszem a nagyon sok ember úgy találkozik először a PHP nyelvvel, hogy rájön, a HTML nem elégíti ki minden igényét. Ilyenkor elkezd olvasgatni és rájön, hogy a tárhely, ahol az oldala van, támogatja a PHP-t. Utánaolvas, hogy az mi fán is terem. Feltelepíti a PHP-t, esetleg a MySQL-t is és elkezdi próbálgatni, amíg meg nem oldja az adott kérdést. Az ember szépen lassan elkezd komolyabb és komolyabb feladatokat megoldani, míg egészen rá nem érez az ízére és úgy nem érzi, hogy ő már bármit meg tud oldani. Az én esetemben, körülbelül itt tartottam, amikor először vállaltam el pénzért egy weboldal elkészítését a designért felelős barátommal karöltve, és szerintem nem voltam ezzel egyedül.

Az ember nagy megelégedésében aztán egyre összetettebb feladatokat kap, szép lassan elkezdi újrahasznosítani saját kódjait és ekkor rájön, hogy a PHP egy objektumorientált nyelv, lehet benne használható osztályokat is létrehozni. (Lehet, hogy ez ma már sokkal evidensebb, mint 5-6 éve volt, a PHP négyes verziója még elég kezdetleges objektum-modellt használt.)

Jobb esetben az ember előbb-utóbb találkozik néhány érdekes kódrészlettel vagy egy-egy jó cikkel, amik megragadják a fantáziáját, hogy elkezdje mások kódját olvasgatni esetleg fel is használni ezt-azt. Rosszabb esetben rögtön feltelepít egy Joomlát vagy Drupált és megállapítja, hogy soha többet nem kell programoznia, mert már minden problémájára van elérhető és letölthető megoldás. Félreértés ne essék, nem szeretnék belemenni, hogy ezek a tartalomkezelő rendszerek jók-e vagy rosszak, csak abban vagyok biztos, hogy nem nyújtanak mindenre megoldást.

Én a jobbik esethez sorolnám magam, először talán egy PHPMailer nevű levélküldő könyvtárat kezdtem használni, később a phpclasses.org-ról is gyűjtöttem be kódokat, majd PEAR könyvtár elemeit is beépítettem itt-ott. Minden nagyszerűen működött, de az egész rendszer egy nagy, feldarabolt spagetti volt és hát a sok különbözőképpen kódolt könyvtár összességében nem volt egy szép látvány.

2007 nyarán aztán aztán minden megváltozott. Találkoztam életem első komplett keretrendszerével, a CodeIgniter-rel. Azt hiszem, amikor láttam a videót, hogy hogyan lehet vele 20 perc alatt egy kezdetleges blogot elkészíteni, akkor már valahol el voltam veszve, de azért biztos, ami biztos körülnéztem az elérhető keretrendszerek között. Úgy emlékszem, akkoriban 4 rendszer volt ami egyáltalán felmerült: a már említett CodeIgniter, a Symfony, a Zend Framework és CakePHP. Azt tudom, hogy a Symfony és a Zend Framework rögtön kiestek, mert nem támogatták a php4-et és akkoriban még elég sok hazai szerveren az futott. A CakePHP talán támogatta a php4-et, de nem nagyon dicsérték a dokumentációját, ellenben a CodeIgniter már akkoriban is hasonlóan jól dokumentált volt, mint ma. Szóval ezek után könnyű volt a választás, és mit mondjak fantasztikus volt, hogy szinte mindenre egységes és jól dokumentált megoldást kínált, amire szükségem volt, ráadásul még parancssori telepítő sem kellett hozzá, mint a PEAR-hez, (meg amúgy a Zend Framework-höz és Symfony-hoz) csak kicsomagoltam/feltöltöttem és működött. Ráadásul az akkor nekem még teljesen új MVC szerkezeti minta is magával ragadott. Időközben a CodeIgniter igencsak népszerű lett, ennek köszönhetően mai napig jó néhány projektem ezt a keretrendszert használja.

A CodeIgnitert én egy nagyon jó keretrendszernek tartom, de mint az előző szakasz múlt idejű környezetéből talán kitűnt, ma már nem sorolnám a kedvenceim közé. Az viszont tény kérdés, hogy a programozó sémákkal csak újonnan ismerkedőknek egy nagyszerű választás, mert jól dokumentált, könnyű hozzá segítséget találni és sokat tanulhat belőle bárki, akinek az MVC netán nem mond semmit. Hogy miért tartok manapság más keretrendszereket többre, az kiderül a sorozat folytatásából.

Címkék: php keretrendszerek

prológ

Először is üdvözlök mindenkit az első szakmai blogomon! Eleddig a magyar blogoszférában szinte ismeretlen voltam, jobbára csak figyeltem az eseményeket, tanultam az okosabbaktól. Néha kisebb-nagyobb tanácsokat azért hozzászólásokban adtam eddig is, de most elérkezettnek érzem az időt, hogy komolyabb energiát fektessek az ismereteim továbbadásába.

Korábban nagyon szerettem a weblabor.hu cikkeit, melyekből annak idején magam is rengeteget tanultam. Sajnos az utóbbi pár évben az oldal szinte már csak link-gyűjteményként és fórumként üzemel, igaz annak elég színvonalas még mindig. A benne szereplő cikkek többsége a mai napig helytálló, így viszonylag gyakran fogok hivatkozni rájuk, de azt hiszem azért sok mindent hozzá is tudok majd tenni.

A várható posztok témái reményeim szerint igen változatosak lesznek. Tervben van, hogy bemutatom azokat az eszközöket, amelyek érzésem szerint megkönnyítik egy fejlesztő életét, legyen az akár egy böngésző akár egy sima rss olvasó. Lesznek programozással kapcsolatos általános leírások, sémák és trükkök és lesznek környezet-függő dolgok is, keretrendszerek, szoftverek ilyesmik. Ezen kívül lesznek honlapépítéssel kapcsolatos információk (html, css), böngészőfüggő megjelenítések, sőt még némi keresőmotor-optimalizálással is szeretnék foglalkozni. Ha ez mind nem lenne elég, valamilyen szinten még a távmunkáróll, ügyfél-kapcsolatról is szót szeretnék majd idővel ejteni.

Nem gondolom, hogy lesz energiám kimondottan új dolgokat bedobni a közös tudás várába, várhatóan a legtöbb leírás nem vagy alig lesz több egy egyszerű fordításnál vagy egy cikksorozat összefoglalásánál. Mégis remélem, hogy lesznek, akiknek tudok majd hasznos dolgokat mondani.

A blog célja természetesen elsősorban önmagam és saját projektjeim promótálása, de emellett azért abban is reménykedem, hogy idővel esetleg képzett, hozzám hasonlóan gondolkozó/dolgozó munkatársakra is szert teszek.

Mivel az ilyesmi nem megy egyik napról a másikra, ezért remélhetőleg ez egy hosszú életű blog lesz, de biztos ami biztos, most először és utoljára elnézést kérek mindenkitől a helyesírásomért. Igyekszem majd átolvasni az irományaimat, de biztos lenne vagy lesz is majd mit javítgatni utólag.

Jó olvasgatást és szép napot mindenkinek!