A megoldás lényege, hogy valahol a vinyón van egy PHP bináris, amit megfuttatunk a -l kapcsolóval, ami nem futtatja a fájlt, hanem csak szintaxisra ellenőriz. A válasz a PHP szokásos "parse error" szövege lesz, ami azt írja ki, hogy hol hasalt el a fordító, ami nem feltétlen esik egybe azzal, hogy hol van a hiba. A kódot többféleképpen meg lehetne valósítani (pl. parancsként, amit menüből, vagy billentyűkombinációra lehet futtatni), én azt választottam, hogy mentés eseményre automatikusan fusson le, ha megfelelő a fájl kiterjesztése:

import sublime, sublime_plugin, os, subprocess, re

class PhpLintEventListener(sublime_plugin.EventListener):
    key = "php_lint_syntax_error"
    
    def on_post_save(self, view):
        if not view.settings().has("php_lint"):
            return
        
        config = view.settings().get("php_lint")
        
        bin_path = config.get("binary", "")
        name, ext = os.path.splitext(view.file_name())
        
        if not bin_path or ext not in config.get("extensions", []):
            return
        
        view.erase_regions(self.key)
        view.erase_status(self.key)
        
        shell = sublime.platform() == "windows"
        p = subprocess.Popen([bin_path, "-l",  view.file_name()], shell=shell, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        (stdout, stderr) = p.communicate()
        
        if "" == stderr:
            data = stdout
        else:
            data = stderr
        
        result = re.match(r"(.+?) in (.+?) on line ([0-9]+).*", data, re.M | re.S)
        if result:
            error = result.group(1)
            line = result.group(3)
            
            view.add_regions(self.key, [view.full_line(view.text_point(int(line) - 1, 0))], "markup.deleted", "dot")
            view.set_status(self.key, error + " on line " + line)

Nem egy bonyolult jószág, ha létezik a config és a fájl kiterjesztése benne van a configban megadott listában, akkor megfuttatjuk a PHP binárist és megkeressük a kimenetében, hogy hányadik sorban volt a hiba. A hibás sort kiemeljük és a hiba szövegét a státuszba ki is írjuk. A szükséges config pedig valahogy így néz ki:

"php_lint" : {
    "binary" : "d:\\php\\5.2\\php.exe",
    "extensions" : [".php"]
}

Ezt lehet pakolni a Preferences > Settings - User részbe vagy akár a projekt beállításai közé is (a .sublime-project fájlon belül a "settings" blokkba).

• A modern kor elvárásaihoz némiképp igazodva az oldal valamivel reszponzívabb lett.
• A kommentelési lehetőség kikerült, a továbbiakban a bejegyzéshez kapcsolódó Google+ postban lehet majd megjegyezni dolgokat.
• Like/+1 gombok sincsenek, csak hogy letisztultabbak és egyszerűbbek legyünk.
• Bár még mindig nem vittem túlzásba a tartalmat, de már nem csak "Folyamatban..." van az Archívum oldalon. :)

Ééés nagyjából ennyi... Nem vittem túlzásba. :) Aztán biztos maradt egy rakat hiba és hiányosság benne, amit majd az elkövetkezendő évek során bőven lesz időm javítani.

Vagy mobilosoknak egy kényelmesebb market alkalmazás linken:

Amit tud:

• Listákat kezelni! :)
• Külső alkalmazás segítségével QR kódot beolvasni és azt elmenteni listaelemként az egyszerű és gyors felvitel érdekében.
• Ha linket kap listaelemnek, azt feldolgozza és a meta adatokkal együtt jeleníti meg (a Facebook-os Open Graph tagek hozzák igazán lázba, mással nem nagyon foglalkozik :)).
• Megosztani egy listát (pl. e-mailben elküldeni).

Nagyjából ennyi, nem egy bonyolult jószág. Az elkészítésében az ActionBarSherlock volt a segítségemre, ami remekül valósítja meg a 4.0-s Action Bar-t 4.0 előtti készülékeken is. Kellemes listázást. :)

Most, hogy már van egy virtuális szerverünk, kellene kezdeni vele valami mókás dolgot. Lehetne mondjuk egy távolról is vezérelhető build rendszerünk (a "távolról" mondjuk ebben az esetben talán egy kicsit túlzás :)), amit a kedvenc szövegszerkesztőnk automatikusan tudna vezérelni. Az úgy kellőképp mókásan hangzik ahhoz, hogy belevágjunk. :)

Ahhoz, hogy legyen értelme a build rendszernek, nem árt, ha van mit build-elni. Tegyük fel mondjuk a példa kedvéért, hogy CSS helyett szeretnénk Sass-t, JavaScript helyett pedig CoffeeScript-et használni. Természetesen a rendszer képességei nem merülnek ki ennyiben, lehetne mondjuk olyat is csinálni, hogy a sablon fájlokat fordítsa le PHP-ra, vagy a konfigurációs XML-ekből gyártson tömböket, esetleg minden unit tesztet lefuttasson. A lehetőségek száma, ahogy mondani szokás, végtelen, de maradjunk az eredeti kettőnél, a többi a kedves olvasó fantáziájára van bízva. Kezdjük is rögtön a telepítéssel:

Sass

sudo apt-get install ruby rubygems
sudo gem install sass

A Sass [Syntactically Awesome Stylesheets] nevezetű előfeldolgozó néhány hasznos kiegészítéssel segít ráncba szedni az elvadult CSS kóddzsungelt.

CoffeeScript

sudo apt-get install nodejs npm
sudo npm install coffee-script

A CoffeeScript a funkcionális programozási nyelvekre és talán egy csöppet a Ruby-ra emlékeztető nyelv a JavaScript egy komolyabb újragondolása (a Sass-CSS viszonylathoz képest), de mentségére legyen mondva, hogy egy az egyben valid JavaScript-re fordul.

Építkezzünk

A build-elésben segítségünkre lesz a vicces nevű PHP-s build eszköz, a Phing. A következő módon érhetjük el, hogy feltelepüljön:

sudo apt-get install php-pear
sudo pear channel-discover pear.phing.info
sudo pear install phing/phing

A példához a következő minimális projekt könyvtárszerkezetet fogjuk használni:

• assets/
  • coffee/
  • sass/
• www/
  • css/
  • js/
• build.xml

Az assets/ könyvtárban vannak a nyers fájlok, a www/ könytárba mennek a generált fájlok, amiket nem árt kívülről is elérni. A kulcs pedig a build.xml, ami a Phing számára tartalmaz utasításokat. Kezdetnek valami ilyesmi például megteszi:

<?xml version="1.0" encoding="UTF-8"?>
<project name="MyProject" default="assets">
    <property name="sass_dir" value="${project.basedir}/assets/sass/" />
    <property name="coffee_dir" value="${project.basedir}/assets/coffee/" />
    
    <property name="css_target" value="${project.basedir}/www/css/" />
    <property name="js_target" value="${project.basedir}/www/js/" />
    
    <target name="sass">
        <exec command="sass --no-cache --update &quot;${sass_dir}:${css_target}&quot;" />
    </target>
    
    <target name="coffee">
        <exec command="coffee -o &quot;${js_target}&quot; &quot;${coffee_dir}&quot;" />
    </target>
    
    <target name="assets">
        <phingcall target="sass" />
        <phingcall target="coffee" />
    </target>
</project>

A projekt könyvtárában (egy szinten a build.xml-lel) állva ki tudjuk adni a következő három parancsot, amivel a Sass-t, CoffeeScript-et és mindkettőt egyszerre lefordíthatjuk (ha nem adunk meg semmit a phing után, akkor a default assets fog lefutni):

phing sass

phing coffee

phing assets

Az alkalmazás

Már csak azt kellene elérni, hogy a fájlok módosítása után a megfelelő parancs automatikusan lefusson. Bár mind a Sass, mind a CoffeeScript rendelkezik megoldással a problémára (--watch), a későbbiekre is gondolva inkább valami általánosabb megoldásra lenne szükség. Mondjuk egy webes minialkalmazás, ami a kapott paraméterek függvényében meghívja a megfelelő parancsot. A kódszerkesztő alkalmazásunk pedig ezt a paraméterezett URL-t hívogathatná. Mondjuk valami ilyesmit:

http://builder.vbox/index.php?project=projektneve&target=target

Az a bizonyos index.php pedig valami ilyen kis egyszerű dolog lenne (az egyszerűség ára az, hogy élünk azzal a feltételezéssel, hogy az egyes projektek a /var/www/projektneve.vbox/ könyvtárban vannak és eltekintünk az olyan dolgoktól, mint például a target valódiságának az ellenőrzése):

$dir = '/var/www/' . get('project') . '.vbox/';
if (!file_exists($dir . 'build.xml')) {
    exit('invalid_project');
}

$target = get('target');
if (!$target) {
    exit('no_target');
}

chdir($dir);
shell_exec('phing ' . escapeshellcmd($target));
exit('ok');

function get($name) {
    if (empty($_GET[$name])) {
        return '';
    }
    return preg_replace('/[^a-z0-9\-\.]/i', '', $_GET[$name]);
}

A plugin

Ezzel meg is van a távolról is vezérelhető egyszerű kis build rendszerünk. A kedvenc szerkesztőnkhöz írhatunk egy plugin-t, ami mentésre meghívja a megfelelő URL-t, hogy legenerálódjanak a CSS/JS fájlok (vagy akár tetszőleges billentyűkombinációra tetszőleges build parancsot meghívhatunk). Sublime Text 2 esetén valahogy így nézne ki a dolog:

import sublime, sublime_plugin
import urllib, urllib2
import os, threading

class BuilderThread(threading.Thread):
    def __init__(self, project, target):
        threading.Thread.__init__(self)
        self.project = project
        self.target = target
    def run(self):
        try:
            data = urllib.urlencode({
                'project': self.project,
                'target': self.target,
            })
            request = urllib2.Request('http://builder.vbox/index.php?' + data)
            response = urllib2.urlopen(request).read()
            return
        except (urllib2.HTTPError) as (e):
            err = '%s: HTTP error %s contacting API' % (__name__, str(e.code))
        except (urllib2.URLError) as (e):
            err = '%s: URL error %s contacting API' % (__name__, str(e.reason)) 
        
        sublime.error_message(err)

class BuilderEventListener(sublime_plugin.EventListener):
    def __init__(self):
        sublime_plugin.EventListener.__init__(self)
    
    def on_post_save(self, view):
        name, ext = os.path.splitext(view.file_name())
        project = view.settings().get('builder_project_name', False)
        
        if (False == project):
            return
        
        if (ext == '.coffee'):
            BuilderThread(project, 'coffee').start()
        elif (ext == '.scss' or ext == '.sass'):
            BuilderThread(project, 'sass').start()

A plugin használ egy builder_project_name nevű beállítást, amit az éppen aktuális projekt .sublime-project fájljában érdemes megadni:

{
    "settings": {
        "builder_project_name": "test-project"
    }
}

Ezzel meg is volnánk, kellemes építkezést.

Épp a sorozatos oldal második verziójának fejlesztésébe készülök komolyabban belevágni. Ennek kapcsán eszembe jutott, hogy milyen jó bejegyzést lehetne ebből kanyarítani. Mármint abból, hogy milyen módjai vannak a kényelmes otthoni projekt fejlesztésnek.

Összepiszkíthatnánk például a jelenlegi operációs rendszerünket mindenféle web- és egyéb szerverekkel, de ez nem egy szép megoldás. Telepíthetnénk egy extra operációs rendszert egy külön partícióra, de az, hogy a jelenlegiből ki kell lépni, oda pedig be... esélytelenné teszi a fejlesztést egy kellően lusta ember számára (én :)). A legjobb lenne egy külön gép, amit hálózaton keresztül elérünk. Ennek a legköltséghatékonyabb változata a virtuális gép, így ezen a vonalon fogunk tovább haladni. Hozzávalók egy személyre:

• VirtualBox
• Ubuntu Server
• némi sör és pár napra elegendő hideg élelem

Pro tipp: az Ubuntu szerver iso-ját ne a VirtualBox telepítése közben töltsük le, mert a VirtualBox telepítés közben hajlamos időlegesen megkavarni az internet kapcsolatot és jól meg fog szakadni a letöltés.

Telepítés

A letöltések és a szokásos next-next-finish telepítés befejeztével hozzáadhatunk egy új Linux / Ubuntu típusú virtuális gépet és egy új virtuális merevlemezt a varázsló segítségével. Még mielőtt elindítanánk, a Settings / Shared Folders részben érdemes hozzáadni egy könyvtárat a saját gépünkről, amiben a projekteket fogjuk tárolni, hogy ne kelljen később Samba-t telepíteni. Az Auto-mount részt ne pipáljuk be, azt később kézzel beállítjuk majd. A Settings / Network részbe se árthat benézni és az Adapter 1-et ízlés szerint megpiszkálgatni. Nálam a Bridged Adapter volt a nyerő az Attached to részben. A VirtualBox elég okos és az első indításnál felajánlja, hogy etessünk meg a géppel egy CD-t. Ajánlatos itt beadagolni a korábban letöltött Ubuntu szerver iso-ját, mert az nagyban megkönnyíti a telepítést. :)

Az Ubuntu nem egy bonyolult jószág, így valószínűleg a telepítéssel se lesznek problémák. Amíg fut, tetszés szerint lehet fogyasztani a bespájzolt hideg élelmet illetve sört. Hogy, hogy nem előbb-utóbb eljutunk egy ilyen képernyőhöz:

Itt a LAMP server-t az Apache-PHP-MySQL szentháromság miatt erősen ajánlott bepipálni, mert valószínűleg szükségünk lesz rá. Én telepíteni szoktam OpenSSH server-t is, mert már annyira hozzászoktam a PuTTy használatához. :)
Ha ezzel megvagyunk, az első belépés után rögtön érdemes is nyomni egy frissítést:

sudo apt-get update
sudo apt-get upgrade

Valamint telepíteni a VirtualBox Guest csomagját a jobb támogatás érdekében:

sudo apt-get install virtualbox-guest-utils

A projekt könyvtárak beállítása

A fejlesztés a /var/www/ könyvtárban fog történni a virtuális gép nézőpontjából. Hogy kényelmes legyen, érdemes ezt kivezetni valahova a gazda gép merevlemezére. Ezért állítottuk be korábban a Shared Folders részt. A művelet elvégzéséhez a következő sorokat kell felvenni az /etc/fstab fájl végére (na jó, a komment nem kötelező :)):

# VirtualBox Shared Folder
projects /var/www vboxsf auto,rw,uid=1000,gid=33 0 0

A projects helyére a Shared Folder felvitelénél megadott nevet kell írni. Az uid=1000 a rendszer telepítése során létrehozott felhasználó, a gid=33 a www-data csoport. A módszernek az az előnye is megvan a Samba-féle megoldással szemben, hogy nem kell futnia a virtuális gépnek ahhoz, hogy a fájlokat módosítani tudjuk. Az uid és gid értékeként megadható számok után az /etc/passwd és /etc/group fájlokban lehet érdeklődni.

Szerver elérés

Ha minden jól ment, az ifconfig eth0 által kidobott ip címen el tudjuk érni a gépet. Ha nem, akkor a VirtualBox beállítások Network részénél érdemes a lehetőségeket végigpróbálgatni, hogy melyik jön be (ahány hálózat, annyi beállítás).
Az egyszerűséget szem előtt tartva érdemes valami egyedi, egyébként nem létező domain-el felruházni a gépet, hogy ne ip címeket kelljen mindig írogatni. Nálam a *.vbox domain-ek vannak erre fenntartva. A legegyszerűbb, ha a hosts fájlba felvesszük őket (Windows: c:\Windows\System32\drivers\etc\hosts, Linux: /etc/hosts), pl.:

192.168.1.117 default.vbox
192.168.1.117 projektneve.vbox
192.168.1.117 subdomain.projektneve.vbox

Apache, PHP, MySQL beállítás

Az egyes projektek a /var/www/projektneve.vbox/ könyvtárban kapnak helyet. Az alap Apache confignak csinálunk egy default.vbox nevet/könyvtárat:

mkdir /var/www/default.vbox
sudo mcedit /etc/apache2/sites-available/default

A megnyíló fájlban a DocmentRoot és a Directory résznél szereplő /var/www/ után kell még egy default.vbox/-ot írni. Aztán pedig

sudo service apache2 reload

A /etc/apache2/httpd.conf-ba esetleg még érdemes egy ServerName default.vbox sort beledobni és újraindítani az Apache-ot, hogy megszűnjön a "Could not reliably determine the server's fully qualified domain name" hibaüzenet.

A projekt VirtualHost beállításai a /etc/apache2/sites-available/projektneve.conf fájlba kerülnek. Egy egyszerű példa, hogy nagyjából mit is tartalmaz egy ilyen:

<VirtualHost *:80>
    ServerName projektneve.vbox
    ServerAlias www.projektneve.vbox

    DocumentRoot /var/www/projektneve.vbox/www
    <Directory />
        Options FollowSymLinks
        AllowOverride All
    </Directory>
    <Directory /var/www/projektneve.vbox/www/>
        Options FollowSymLinks
        AllowOverride All
    </Directory>

    ErrorLog /var/www/projektneve.vbox/log/apache_www_error.log
    CustomLog /var/www/projektneve.vbox/log/apache_www_access.log combined

    LogLevel warn
</VirtualHost>

A kész site beállításokat a következő parancsokkal tudjuk engedélyezni:

sudo a2ensite projektneve.conf
sudo service apache2 reload

A MySQL-en nincs sok beállítani való, telepítéskor elkérte a root felhasználójához az új jelszót, mást meg nem nagyon kell piszkálni. A vizuálisabb típusoknak esetleg egy phpmyadmin telepítése még nem árthat:

sudo apt-get install phpmyadmin

Ha kértük, a csomagból telepítés során be is köti magát az Apache-ba a /etc/apache2/conf.d/phpmyadmin.conf segítségével és a http://ipcím/phpmyadmin/ címen el is érhető az oldal. Ehelyett, ha kedvünk tartja létrehozhatunk neki egy saját VirtualHost-ot is akár.

A PHP beállításánál érdemes arra törekedni, hogy minél jobban hasonlítson az éles rendszerre, így ezzel kapcsolatban nem sokat tudok mondani.

Első körben ennyi, kellemes telepítgetést. :)

Jelenleg még üres, de a terv az, hogy leváltja az oldalsávban a "Linkek" rész alatt használt Google Reader-ből jövő megosztás listát és ezentúl ott lesznek megosztva az érdekesnek tűnő linkek.

Szóval lájkoljatok plusszoljatok! :)

Érdekes módon a deadlime kedvenc kódszerkesztő alkalmazása a Sublime. Egyrészt azért, mert a többszörös kijelölés az bizony hihetetlenül fantasztikus egy találmány. Másrészt pedig Python-ban lehet hozzá plugin-eket írni.

Kedves kollégám említette a minap, hogy egyik régebben használt szerkesztőjében volt valamiféle funkció, amivel a vágólap korábbi tartalmait lehetett újra felhasználni. Aztán elkezdtem gondolkodni rajta, hogy vajon lehetne-e egy ilyen plugin-t írni Sublime-hoz. Aztán megírtam. :)

Ha már így alakult, ragadjuk meg az alkalmat és nézzük meg kicsit, hogyan is néz ki egy Sublime plugin. A funkció meglepően kevés kódból megoldható: először is felül kell csapnunk a beépített copy és cut utasításokat sajáttal úgy, hogy megmaradjon az eredeti funkcionalitás is, de közbe mentsük egy tömbbe az adatokat.

class ClipboardHistoryCopyCommand(sublimeplugin.TextCommand):
    def run(self, view, args):
        saveSelections(view)
        view.runCommand('copy');

Egy kis XML-lel meg is mondjuk a proginak, hogy a mi parancsunkat használja a Ctrl+C nyomkodása esetén:

<bindings>
    <binding key="ctrl+c" command="clipboardHistoryCopy" />
</bindings>

A cut nem túl meglepő módon elég hasonlóan néz ki (csak a beépített cut parancsot hívjuk meg a végén). A saveSelections végzi a munka javát. Végigmegy az összes kijelölésen és amelyik nem üres, azt elpakolja egy tömbbe, aminél még arra is figyelünk, hogy ne lehessen túl nagy:

clipboardMaxSize = 100
clipboardData = []

def saveSelections(view):
    for region in view.sel():
        if region.begin() != region.end():
            clipboardData.insert(0, view.substr(region))
            if len(clipboardData) > clipboardMaxSize:
                clipboardData.pop()

Annyi maradt már csak, hogy valami kellően kézreálló billentyűkombinációra meg is jelenítse az előzményeket és tudjunk belőle kedvünkre válogatni. Legnagyobb szerencsénkre tudjuk használni a beépített lista ablakot, amiben még kereső is van (ugyanaz, ami a Ctrl+P vagy a Ctrl+R kombinációkra is bejön):

class ClipboardHistoryPasteCommand(sublimeplugin.TextCommand):
    def pasteSelected(self, view, index):
        for region in view.sel():
            view.insert(region.begin(), clipboardData[index])
    
    def run(self, view, args):
        view.window().showSelectPanel(
            clipboardData,
            functools.partial(self.pasteSelected, view),
            None,
            sublime.SELECT_PANEL_MONOSPACE_FONT
        );

És természetesen a hozzá tartozó kis XML részlet:

<binding key="alt+shift+q" command="clipboardHistoryPaste" />

Nem a legtökéletesebb megoldás, például plugin újratöltéseknél elveszik a clipboardData tömb tartalma (lehetne például fájlba menteni menet közben), de kezdetnek megteszi. A teljes csomagot innen le lehet rántani (érdekes módon ClipboardHistory.sublime-package fájlnévvel nem mentek volna a billentyűparancs felüldefiniálások, mivel az Sublime ABC sorrendben tölti be a plugineket és a Default később van... :)).

[a képet köszönjük ShutterBugChef-nek]

Bár nem tegnap történt, hogy az 5.3-as sorozat első verziója kijött, gondoltam kicsit körbejárom a névtelen függvények témakörét az ősidőktől napjainking. Az ősidő alatt itt természetesen a 4-es verziót értem, amikor még csak a call_user_func állt a rendelkezésünkre. Lássuk, hogyan is ment ez.

A create_function módszer (attól tekintsünk el, hogy a __FUNCTION__ varázskonstans csak a 4.3-as verzióban jelent meg):

$f = create_function('', 'echo __FUNCTION__ . "\n";');
call_user_func($f);

A függvény neve stringként módszer:

$f = 'myFunction';
call_user_func($f);

Az osztály és a statikus metódus neve tömbként:

$f = array('MyClass', 'myStaticFunction');
call_user_func($f);

Az objektum és a metódus neve tömbként:

$c = new MyClass();
$f = array($c, 'myFunction');
call_user_func($f);

Az osztály és a statikus metódus neve stringként (5.2.3-as PHP-tól):

$f = 'MyClass::myStaticFunction';
call_user_func($f);

Az objektum meghívása (5.3.0-s PHP-tól):

$c = new MyClass();
call_user_func($c);

És ezzel el is érkeztünk a jelenhez. Az 5.3.0-s verzióval megjelentek a closure-ök (az újfajta névtelen függvények), amolyan JavaScript-es definiálással:

$f = function () {
};

Természetesen a teljes visszafelé kompatibilitásról ne is álmodjunk ezért kezdjük is el végignézni az előző módokat, hogy mi működik továbbra is:

A create_function módszer megy továbbra is (emlékeim szerint 5.3 előtt is működött így, ezért ez nem túl meglepő):

$f = create_function('', 'echo __FUNCTION__ . "\n";');
$f();

A függvény neve stringként módszer (működik):

$f = 'myFunction';
$f();

Itt sajnos meg is állhatunk. A tömbös rendszerek (PHP Fatal error: Function name must be a string) és az osztály+statikus metódus neve stringként (PHP Fatal error: Call to undefined function MyClass::myStaticFunction()) nem működik.

Maradt még az objektum direkt meghívása, ami működik, de ez sem túl nagy meglepetés, mivel az 5.3.0-s verzióbal vezették be hozzá az új varázsmetódust:

$c = new MyClass();
$c();

Ilyenkor (és a call_user_func-os esetben is) az osztály __invoke() metódusa hívódik meg.

Ezzel azt hiszem nagyjából ki is veséztük a különböző callback típusok és névtelen függvények hívhatóságát. Maradt még némi scope kérdés, de az házi feladat (annyit megsúgok, hogy a use a kulcsszó). Egy kis segítség hozzá:

• Anonymous functions [php.net]
• Callback pseudo-type [php.net]
• RFC: Lambda functions and closures [wiki.php.net]

Ha vesszük az értékesítő-pénztáros-árukiadó modellt, érzésre úgy tűnik, hogy a több sor végigjárása miatt többet is várunk. De a sorbanállás pszichológiája fura egy dolog. Jó példa erre a hipermarket, ahol N pénztárnak van N sora azért, mert az N pénztár 1 sor felállás zavaró lehet az embereknek a hosszú sor miatt, holott a várakozási idő úgy kevesebb lenne.

Itt az ideje szimulálni. Két eset lesz (meg talán egy bónusz :)). Az egyikben van 4 ember, aki értékesít, 1 kezeli a pénzt és 1 kiadja a vásárolt árut. A másikban 6 ember, aki a teljes vásárlási folyamatért felelős. Mindkét esetben ahány ember van, annyi sor is, valamint hirtelen nagyobb mennyiségű vásárló esik be a boltba, akik mindig a legrövidebb sort célozzák meg. A helyek közötti közlekedésre szánt időt figyelmen kívül hagyjuk. Nincsenek kezelve az olyan vásárlók, akik az értékesítés után "feladják" és hazamennek (csak érdeklődni jöttek be a boltba). Az egyes helyeken töltött időt random generáltam a következő intervallumokat használva:

Értékesítés:

30 és 300 másodperc között

Pénztár:

15 és 30 másodperc között

Árukiadás:

30 és 120 másodperc között

Az első változat eredményei 4 különböző adathalmazra, 25 egyszerre érkező vásárlóval (az eredmények percben vannak):

A kettes számú verzió a 6 eladóval, aki nem specializálódott:

Ezzel úgy tűnik el is dőlt, hogy a többszörös sorbanállás nem csak lassabbnak érződik, de lassabb is. Már amennyire meg lehet bízni az általam írt szimulációkban. :)

A bónusz eset megegyezik a kettes verzióval annyi különbséggel, hogy nem eladónként van egy sor, hanem egy sor van összesen:

A különbség nem annyira látványos, de azért még sikerült lefaragni valamennyit az időkből (az A2 idejét leszámítva, az valamilyen rejtélyes oknál fogva több lett).

A kód egyébként Python-ban készült és a használt adathalmazokkal együtt letölthető itt. Kellemes szimulálást. :)

Ja... a cím: s01e01.hu

Vegyünk is egy egyszerű példát. Tegyük fel azt, hogy már annyira jók vagyunk, hogy az SQL szerverrel is csak l33t nyelven vagyunk hajlandóak kommunikálni. Persze a mysqld (vagy egyéb tetszőleges daemon) nem ilyen megértő, és folyamatosan panaszkodik, hogy nem ért meg minket. A probléma elsimítása érdekében származtatunk a beépített PDO osztályból egy sajátot:

class L33tPDO extends PDO {
	private static $from = array(
		's3l3ct', 'fr0m', 'wh3r3', 's3t', '1ns3rt', '1nt0', 'upd4t3', '0rd3r', '4sc', 'd3sc', 'l3ft', 'r1ght', '1nn3r', 'j01n'
	);
	private static $to = array(
		'SELECT', 'FROM', 'WHERE', 'SET', 'INSERT', 'INTO', 'UPDATE', 'ORDER', 'ASC', 'DESC', 'LEFT', 'RIGHT', 'INNER', 'JOIN'
	);
	public function query($statement, $type = false, $param1 = false, $param2 = false) {
		$statement = $this->convertStatement($statement);
		
		if ($type && $param1 && $param2) {
			return parent::query($statement, $type, $param1, $param2);
		}
		if ($type && $param1) {
			return parent::query($statement, $type, $param1);
		}
		if ($type) {
			return parent::query($statement, $type);
		}
		
		return parent::query($statement);
	}
	public function prepare($statement, $driver_options = array()) {
		$statement = $this->convertStatement($statement);
		parent::prepare($statement, $driver_options);
	}
	private function convertStatement($statement) {
		return str_ireplace(self::$from, self::$to, $statement);
	}
}

Hogy takarékoskodjunk a hellyel, a kulcsszavak listája nem teljes. Nézzünk is egy példát a használatra:

$conn = new L33tPDO('pgsql:host=localhost port=5432 dbname=test user=test password=test');

$stmt = $conn->query("s3l3ct * fr0m users wh3r3 id > 1 0rd3r by login_name 4sc" );

var_dump($stmt->fetchAll());

Bár a felhozott példa nem igényli, a PDOStatement osztályból is származtathatunk sajátot, csak meg kell mondanunk a saját PDO osztályunknak, hogy az általunk írt PDOStatement-tet adja vissza a megfelelő függvényei. Ehhez bővítsük ki a L33tPDO osztályunkat egy konstruktorral:

function __construct($dsn, $username = null, $password = null, $driver_options = array()) {
	parent::__construct($dsn, $username, $password, $driver_options);
	
	$this->setAttribute(PDO::ATTR_STATEMENT_CLASS, array('L33tPDOStatement', array($this)));
}

És egy hozzá passzoló statement osztály:

class L33tPDOStatement extends PDOStatement {
	private $dbh;
	protected function __construct($dbh) {
		$this -> dbh = $dbh;
	}
}

Ennyit mára. További kellemes kódolást.

A kiterjesztés mögött rejlő ötlet rettentően egyszerű (és talán éppen ezért olyan fantasztikus): küldjünk ki pár speciális fejlécet valamiféle JSON tartalommal, amit kliens oldalon a kiegészítő feldolgoz és a Firebug segítségével szépen meg is jelenít. Ezek lehetnek több prioritásba sorolható egyszerű szöveges üzenetek (hasonlóak a Firebug beépített üzeneteihez), táblázatok, szépen formázott backtrace-ek vagy akár print_r()-hez hasonló információk változókról.

Nézzünk is egy példát a felhasználásra: jelenítsük meg az oldal legenerálása során küldött SQL lekérdezéseket, külön kiemelve azokat, amik lassabban futnak, mint szeretnénk (a példához Doctrine van használva):

class My_Doctrine_Logger extends Doctrine_EventListener {
    private $queryTime;
    public function preQuery(Doctrine_Event $event) {
        $this->queryTime = microtime(true);
    }
    public function preStmtExecute(Doctrine_Event $event) {
        $this->queryTime = microtime(true);
    }
    public function postQuery(Doctrine_Event $event) {
        $this->logQuery($event->getQuery());
    }
    public function postStmtExecute(Doctrine_Event $event) {
        $this->logQuery($event->getQuery());
    }
    private function logQuery($queryString) {
        $t = microtime(true) - $this->queryTime;
        
        $msg = '['.str_pad(round($t, 5), 7, '0').']: '.$queryString;
        
        if ($t > 0.01) {
            FB::warn('Slow SQL Query: '.$msg);
        }
        else {
            FB::info('SQL Query: '.$msg);
        }
    }
}

És ehhez még nem árt valami ilyesmit is hozzácsapni, hogy a Doctrine tudjon a mi kis osztályunkról:

$conn = Doctrine_Manager::connection( $dsn );
$conn->addListener(new My_Doctrine_Logger());

Az egészből az FB:: kezdetű sorok érdekesek csak. A működésükhöz szükség lehet az output buffering bekapcsolására vagy kellő önuralomra, hogy az utolsó FB::-s hívásig nem nyomunk ki semmit a kimenetre. :)
Ami még érdekes lehet, hogy Ajax-os kérések és Location fejléccel átirányított oldalak hasonló üzenetei is megjelennek a Firebug ablakában, szépen csoportosítva, ezzel végtelenül egyszerűvé téve az Ajaxos kérések és a rájuk érkező válaszok hibamentesítését, sok-sok órát megspórolva ezzel szegény fejlesztőknek. Mindezt természetesen anélkül, hogy az eredeti tartalmat teleszemetelnénk mindenféle nem odavaló dologgal (csúnyán is nézne ki a JSON válasz közepén egy méretes var_dump() kimenet, arról nem is beszélve, hogy a kliens oldalon se tudna vele túl sokat kezdeni a JavaScript).

function error_handler($errno, $errstr, $errfile, $errline)
{
    throw new ErrorException(
        $errstr, 0, $errno,
        $errfile, $errline
    );
}
set_error_handler('error_handler');

Egyéni ízlés kérdése, de én még az alábbi kóddal kiegészíteném, hogy fatal error-ok helyett inkább valami olvasható dolgot kapjak:

function exception_handler($ex)
{
	print('<pre>'.$ex.'</pre>');
}
set_exception_handler('exception_handler');

És hogy miért is lenne hasznos? Elég sokan kikapcsolják az E_NOTICE-ok jelzését még fejlesztés alatt is, mondván hogy az nem számít. Pedig elég sok kisebb hibára (pl. változó név vagy tömb kulcs elgépelésekre) hívhatná fel a figyelmet, amik így csak a tesztelési időszakban derülnek ki (ha kiderülnek). Emellett biztonsági haszna is van, mint az a php.net-en is olvasható.

A programunk egy egyszerű "Hello World!" alkalmazás lesz parancssori stílusban. Két fajta bemenő paramétert fogad el. Az egyik a név, akinek köszönni fog, a másikra pedig megjeleníti a súgót, hogy hogyan is kell paraméterezni ezt a rettentő bonyolult programot.

A getopt

A legkézenfekvőbb módszer a paraméterek feldolgozására a getopt modul getopt() függvénye. Szükségünk lesz ezen kívül még a sys modulra, hogy a feldolgozandó lista is a birtokunkba kerüljön (mellesleg a getopt() függvény PHP-ban is létezik):

from getopt import getopt, GetoptError
import sys

A feldolgozás során a getopt() egy GetoptError kivételt dob, ha nem talál rendben valamit. A függvény első paramétere a bemenő adatok tömbje (az első indextől, mivel a nulladik index az a meghívott fájl neve), a második paraméter a rövid kapcsolók listája (kettőspont van a betűk mögött, amik paramétert várnak), a harmadik paraméter pedig a hosszú kapcsolók listája (egyenlőségjellel a név mögött, ha paramétert várnak). A visszatérési értéke két tömb, az első paraméternév-érték párokat tartalmaz, a második pedig a fel nem dolgozott parancssori argumentumokat.

try:
    opts, args = getopt(sys.argv[1:], 'hn:', ['help', 'name='])
except GetoptError:
    print 'Parameterezesi hiba'
    sys.exit(1)

Ha nem szállt el a program hibával, akkor megadjuk a változóinknak (jelen esetben csak a name-nek) az alapértelmezett értékeket és végigmegyünk az opts tömbön, hogy feltölthessük őket valós adatokkal.

name = False

for opt, arg in opts:
    if opt in ('-h', '--help'):
        print 'usage: %s --name=NAME' % sys.argv[0]
        sys.exit(0)
    elif opt in ('-n', '--name'):
        name = arg

Nem maradt más hátra, mint a name változó ellenőrzése és siker esetén a köszöntés kiiratása:

if not name:
    print 'Add meg a nevet!'
    sys.exit(2)

print 'Hello, ' + name + '!'

Ha a name változó kezdőértéke például 'World' lenne, akkor a feldolgozás utáni ellenőrzést el is hagyhatnánk és a programunk működése úgy módosulna, hogy a világot köszöntené, ha nem kap más paramétert.

Az optparse

A Python 2.3-as verziója óta rendelkezésre áll az optparse modul is, ami még egy pár gondot levesz a vállunkról méghozzá objektum-orientált módon. Ez esetben a sys modulra nem lesz szükségünk, a parancssori paraméterek begyűjtését az optparse végzi.

from optparse import OptionParser

Beállítjuk, hogy milyen paramétereket várunk és azt is, hogy mik lesznek ezeknek az alapértelmezett értékei. Ezek után feldolgozzuk a bejövő adatokat.

parser = OptionParser()
parser.add_option(
    '-n', '--name',
    dest = 'name',
    help = 'a koszontendo neve',
    metavar = 'NAME'
)
parser.set_defaults(name = False)
opts, args = parser.parse_args()

Ami azonnal feltűnhet, hogy a -h és --help kapcsolókat nem adtuk meg. Ezt az optparser automatikusan megteszi és még a segítség szövegét is legenerálja nekünk (az add_option() help és metavar paramétere alapján). A feldolgozás után kapott értékeket az opts tömbben érjük el az add_option()-nak megadott dest paraméter nevű kulcsként.

if not opts.name:
    parser.error('Add meg a nevet!')

print 'Hello ' + opts.name + '!'

Ezzel meg is lennénk. Nem tűnik sokkal rövidebbnek a kód, de több paraméter esetén szembetűnőbb lenne a getopt esetén a kód közepén az a hatalmas if-elif erdő. Ezen kívül ugye egy elég szép súgó kimenetet generál nekünk és bizonyos fokig kezeli a hibákat is (üres paraméter, nem numerikus paraméter - ha az van beállítva) egy kulturált hibakimenetet mutatva.

Példafájlok

• getopt példafájl
• optparse példafájl

A következő részben előreláthatólag különböző konfigurációs fájlok feldolgozásának módjáról lesz szó. Addig is kellemes paraméterezést.

Magáról a nyelvről azt lehet elmondani, hogy feltűnően szépnek mondható ahhoz képest, hogy a Pascal-stílusú nyelvek közé tartozik. És nem csak egyszerűen szép, hanem törekszik arra, hogy a benne írt kód is szép legyen (ahogy az a Python filozófiáinak listájában is szerepel: "Beautiful is better than ugly."). Persze ehhez az is kell, hogy ne csak Python nyelven, de Python stílusban is programozunk.
A kinézetet tekintve legszembetűnőbb különbség más nyelvekhez képest a kód kötelező indentálása. Nincsenek sorvégi pontok, pontosvesszők, if-eket és egyéb blokkszerkezeteket lezáró hullámos zárójelek vagy kulcsszavak. Minden az új sor karakterek és az indentálás alapján dől el. De mivel kódolás közben a nagy többség amúgy is szokott új sorokat és tabokat használni (és mivel a kötelező indentálás az esetek közel 100%-ában megegyezik azzal, amúgy is használnánk), ezért elég gyorsan hozzá lehet szokni ahhoz, hogy tulajdonképpen kevesebbet kell gépelni. Persze ez még kevés ahhoz, hogy használható is legyen valamire. Mivel napjaim nagy részét a webprogramozás teszi ki, ezért a szintaktikai ismerkedés után első dolgom az volt, hogy utánanézzek, mire is képes a kígyó a weben...

Itt már kezdődtek a gondok. Mutatkoztak annak a jelei, hogy a Python egy általános scriptnyelv, nem webre teremtették, mint a PHP-t. Ha mindenféle keretrendszer nélkül szeretnénk benne webprogramozni, csupán a megfelelő Apache beállítások elvégzésével és egy mod_python betöltésével... hát... nem lesz egy könnyű dolgunk (arról nem is beszélve, hogy a mod_python mellett van számos más alternatíva is és akkor még el sem jutottunk odáig, hogy keretrendszert válasszunk). Persze egy nagyon minimális keretrendszert össze lehet dobni pár tíz perc és 50-60 sor kód alatt (amit meg is tettem, just for fun), de végső soron arra jutottam, hogy ha webprogramozás, akkor egyelőre maradok a PHP-nél.

A gond ez után már csak az volt, hogy ha nem webprogramozásra, akkor mégis mi a fenére használjak egy scriptnyelvet? Mivel egy általános nyelvről van szó, elég sok dologra lehetne használni. Ennek okán úgy döntöttem, hogy ha valami nem webprogramozással kapcsolatos, de programozást igénylő problémába ütközöm, akkor azt Python-ban próbálom majd megoldani, ahelyett, hogy a jól bevált PHP-t használnám. Így ha épp egy random, 8 betűből álló stringre van szükségem, akkor nem azt írom, hogy:

$str = '';
for ($i = 0; $i < 8; ++$i) {
	$str .= chr(mt_rand(97, 122));
}
print $str;

Hanem inkább ezt:

from random import randint
print ''.join([chr(randint(97, 122)) for x in range(8)])

Valószínűleg így egyes problémákat tovább tart megoldani, mivel kénytelen vagyok utánanézni olyan dolgoknak, amiknek PHP-ban nem kellene, viszont ha sosem használom a nyelvet valós problémák megoldására, akkor egyrészt nem lesz benne gyakorlatom, másrészt pedig elfelejtem. Végeredményben tehát a Python egy szép nyelv (és nem csak külalakra, hanem működését és megoldásait tekintve is), amivel érdemes foglalkozni. Már csak azért is, hogy új szemléletmódokat szedjen magára az ember. Ezt pedig jól segíti ez az online is olvasható könyv.

Segítsetek Vuknak Firefoxnak a kis rókának! :)

Néha egész érdekes dolgokat lehet látni, ha az ember - szakmai ártalomból, vagy csak egyszerű kíváncsiságból - beleles egyes oldalak forrásába. Az ilyen oldalak közé tartozik a The World of Warcraft Armory is. Az első pillantásra elég bonyolultnak tűnő oldal mögött meglepően kicsi (5 soros) XML fájl van. Legalábbis látszólag. Természetesen az XSLT áll a dolog mögött, aminek a szerver oldali alkalmazásáról már réges-régen ejtettem pár szót. Nézzük akkor most meg, hogy kliens oldalon mit művelhetünk vele:

Az alapok

Amire szükségünk lesz az egy XML és egy XSL fájl. A rendszerben valószínűleg az XSL fájlok statikusak lesznek, az XML-ek pedig szerver oldalon fognak generálódni. Nézzünk egy egyszerű blog példát kezdésnek:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="index.xsl"?>
<page>
    <post url="http://example.com/">
        <name>A bejegyzés címe #1</name>
        <content>
            <p>A bejegyzés tartalma #1</p>
        </content>
        <author url="http://example.com/">író #1</author>
        <tags>
            <tag url="http://example.com/">tag #1</tag>
            <tag url="http://example.com/">tag #2</tag>
        </tags>
    </post>
    <post url="http://example.com/">
        <name>A bejegyzés címe #2</name>
        <content>
            <p>A bejegyzés tartalma #2</p>
        </content>
        <author url="http://example.com/">író #1</author>
        <tags>
            <tag url="http://example.com/">tag #3</tag>
            <tag url="http://example.com/">tag #4</tag>
            <tag url="http://example.com/">tag #5</tag>
        </tags>
    </post>
</page>

Gyakorlatilag bármilyen XML-t használhatunk, az oldal akár lehetne egy RSS feed is, amit a megfelelő XSL fájllal formálunk weboldal alakúvá. Esetünkben ez a fájl valahogyan így néz ki:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="html" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"/>
    <xsl:template match="page">
        <html xmlns="http://www.w3.org/1999/xhtml">
            <head>
                <title>XSL teszt</title>
            </head>
            <body>
                <div id="container">
                    <xsl:apply-templates/>
                </div>
            </body>
        </html>
    </xsl:template>
    <xsl:template match="post">
        <div class="post">
            <h2><a href="{@url}"><xsl:value-of select="name/text()"/></a></h2>
            <ul class="post-tags">
                <xsl:for-each select="tags/tag">
                    <li><a href="{@url}"><xsl:value-of select="text()"/></a></li>
                </xsl:for-each>
            </ul>
            <div class="post-content"><xsl:copy-of select="content"/></div>
        </div>
    </xsl:template>
</xsl:stylesheet>

A transzformáció az első illeszkedő <xsl:template> blokk végrehajtása után leáll (esetünkben ez az <xsl:template match="page"> kezdetű blokk). Ahhoz, hogy további template blokkokat hajthassunk végre a jelenlegi elemen (esetünkben ez az XML <page> tagje), vagy annak gyerekein, az <xsl:apply-templates/> taget kell használni (ennek van egy select="" tulajdonsága, amivel még szűkíthetjük a node-okat, amin szeretnénk végrehajtani transzformációt).

A <post> tagre illeszkedő template-ben látható példa arra, hogy hogyan tudunk egy tulajdonságnak értéket adni ({@url}), hogyan lehet sima szöveget kinyerni az eredeti XML-ből (<xsl:value-of select="name/text()"/>) valamint arra, hogyan lehet egy XML részt egy az egyben átmásolni az eredeti XML-ből (<xsl:copy-of select="content"/>). Hosszasan lehetne magyarázni, hogy akkor most ez hogy is van és egyébként is milyen eszközök állnak még a rendelkezésre, de mivel már születtek erről leírások erre és erre (meg még sok egyéb helyen is biztos), ezért ugorjuk át az unalmas részleteket, és nézzünk valami izgalmasabb dolgot, nevezetesen azt, hogy mire is lehet ezt az XSLT dolgot használni?

Többnyelvűsítés

Hogyan is többnyelvűsítünk olyan adatokat a weboldalon, amik statikusan bele vannak írva a sablonba? Például ez a dolog valahogy úgy történhet meg, hogy van egy (optimális esetben minél rövidebb nevű) függvényünk, ami megkapja paraméterként a szöveget és ha van hozzá az adott nyelven fordítás, akkor megjelenítni, ha nincs, akkor pedig kiírja az eredetileg kapott szöveget (vagy bármi más feltűnő szöveget, hogy szegény fordító lássa, hogy ott még hiány van). A függvény maga meg valószínűleg adatbázisból dolgozik, esetleg az adatbázisból generálódik egy PHP, XML vagy egyéb szöveges formátumú fájl cache-elési szándékkal.

Ha már mindenképpen generálunk mondjuk egy XML fájlt ezekből az adatokból, akkor miért ne lehetne azt csinálni, hogy az XSLT-t segítségül hívva rakjuk be a megfelelő helyre a megfelelő nyelvű szöveget? Nézzük is az új XML fájlunkat:

<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/xsl" href="multilang.xsl"?>
<page lang="hu"/>

A felesleget kiszórtam belőle, mivel valószínűleg az XML-be csak dinamikus adatok kerülnek már a megfelelő nyelven, úgyhogy az a része minket most nem érdekel. Emellett kapott egy extra tulajdonságot a <page> tag (lang="hu"). Szükségünk lesz még egy második XML fájlra, ami az oldal megjelenítéséhez szükséges statikus szövegeket tartalmazza:

<?xml version="1.0" encoding="utf-8"?>
<strings>
    <string id="text-1">Valami szöveg</string>
    <string id="text-2">Valami másik szöveg</string>
</strings>

...és természetesen egy XSL fájlra, a megfelelő kimenet érdekében:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="html" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"/>
    <xsl:variable name="lang" select="/page/@lang"/>
    <xsl:variable name="data" select="document(concat('data_',$lang,'.xml'))"/>
    <xsl:template match="page">
        <html xmlns="http://www.w3.org/1999/xhtml">
            <head>
                <title>XSL teszt</title>
            </head>
            <body>
                <h1><xsl:value-of select="$data/strings/string[@id='text-1']"/></h1>
                <p><xsl:value-of select="$data/strings/string[@id='text-2']"/></p>
            </body>
        </html>
    </xsl:template>
</xsl:stylesheet>

Az előző kódhoz képest lett pár új dolog. Az <xsl:variable> segítségével adhatunk változóknak értéket, amiket később a $változónév formában érhetünk el. Ezen kívül megjelent pár XSL függvény is, a document() és a concat(). A concat() egyszerű string összefűzés, a document() segítségével pedig egy külső XML-t tölthetünk be (így a változón keresztül elérhetjük a benne lévő adatokat).

És a SEO?

Persze, szép dolog szétválasztani a nyers adatokat, a statikus, többnyelvű szöveget a megjelenítéstől, és mintezt kliens oldalon össszerakni, de mit sem ér, ha a keresők nem tudnak vele mit kezdeni. Nem látok bele a keresőrobotok lelki világába, de abból kiindulva, hogy az "armory" szóra a bevezetőben említett oldal amerikai párja jön fel a Google-ben első találatként, arra lehet következtetni, hogy különösebben nem viseli meg őket a dolog. Ha az oldal tárolt változatát is megnézzük, észre lehet venni, hogy a forrásban már az XSL transzformáció utáni állapotot mutatja (és mellesleg a Yahoo!-val és a Live Search-el kapcsolatban is hasonló a helyzet), azaz szerintem az XML+XSLT oldalak (amiknek a kimenete HTML) ugyanúgy viselkednek kereső-optimalizációs szempontból nézve, mint a sima HTML oldalak.

Ennyit mára. Folyt. köv.

Az alábbiakban szeretném bemutatni, hogy hogyan is valósíthatjuk meg ezeket a dolgokat, valamint mit tehetünk, ha nem elégszünk meg az alap lehetőségekkel.

Blogroll készítése

1. A Reader felületén kattintsunk az egyik feedünkre és a "Feed settings..." alatt adjunk hozzá egy új könyvtárat (New folder...). Legyen a neve mondjuk "blogroll".
2. Kellő óvatossággal kattintsuk meg a jobb felső sarokban található "Settings" linket és azon belül is a "Subscriptions" fülecskét.
3. Jelöljük ki azokat az oldalakat, amiket meg szeretnénk jeleníteni a blogrollunkban és a "More options..." lenyitható űrlapelem segítségével adjuk hozzá a "blogroll" taget.
4. Menjünk át a "Tags" fülre. A "blogroll" neveztű tag sorában kattintsuk meg azt a kis feed ikonocskát, mire megjelenik egy csomó minden egyéb link is abban a sorban.
5. A minket érdeklő dolog az "add a blogroll to your site" link. A megkattintás után előjön egy popup, ahol be tudjuk állítani a blogroll dobozunk stílusát.
6. Most már csak az van hátra, hogy a személyre szabott kódunkat, amit alatta egy textarea-ban legenerált nekünk, kimásoljuk és beillesszük a blogunkra egy megfelelő helyre.

De tényleg csak ennyi lenne? Nem tudom, de nekem nem igazán sikerült olyan színsémát találnom, ami igazán passzolt volna a bloghoz, szóval ideje valami alternatív megoldást keresni. A popupban két <script> tag található. Az első egy olyan JavaScript fájl, ami a megjelenítésért felelős, ezért minket nem is érdekel különösebben. Ám a második egy aranyos JSON fájl, ami egy callback függvénynek átadja a nekünk szükséges adatokat. Ennek a linknek is csak az első fele érdekes számunkra a "callback" részig. A callback utáni részt pedig írjuk át nemes egyszerűséggel updateBlogroll-ra. Ezek után valahogy így fog kinézni:

http://www.google.com/reader/public/javascript-sub/user/AZONOSÍTÓ/label/blogroll?callback=updateBlogroll

Így egy olyan JavaScript kódot fog legenerálni nekünk a Google, ami meghívja az updateBlogroll függvényt és átadja neki a Reader-ünkből származó adatokat. Így már csak annyi a dolgunk, hogy ezt az updateBlogroll függvényt megírjuk, az őt tartalamzó JS fájt betöltsük a honlapunk <head> részében, a fent említett, Reader által generált JS-t pedig az után a tag után, ahova a blogrollt be szeretnénk szúrni. Egy példa az updateBlogroll függvényre (a kód prototype.js-t használ):

function updateBlogroll(data)
{
	var parent = $('blogroll-list');
	parent.innerHTML = '';
	var len = data.items.length;
	for (var i = 0; i < len; ++i)
	{
		parent.insert('<li><a href="'+data.items[i].alternate.href+'">'+data.items[i].title+'</a></li>');
	}
}

Ha ezt a függvényt mondjuk egy update.js fájlba mentjük el, akkor a HTML kódunk valahogy így nézhet ki:

...
<script language="JavaScript" type="text/javascript" src="update.js"></script>
</head>
...
<ul id="blogroll-list">Blogroll betöltése...</ul>
<script language="JavaScript" type="text/javascript" src="http://www.google.com/reader/public/javascript-sub/user/AZONOSÍTÓ/label/blogroll?callback=updateBlogroll"></script>
...

Feed elemek megosztása

Hasonló módon érhetjük el azt is, ha szeretnénk az általunk érdekesnek talált linkeket megosztani a blogunk látogatóival. A Reader beállításainál a "Tags" fülön található egy "Your shared items" (ide úgy kerülnek bele az elemek, ha "Expanded view"-ban Shift+S-t nyomunk egy bejegyzésen vagy megnyomjuk a "Share" linket az elem alján. "List view"-ban csak az utóbbira van lehetőségünk, ha már kinyitottunk egy elemet). Ennek a sorában kattintsuk meg az "add a clip to your site" linket. Egy hasonló popup ugrott fel, mint a blogroll esetében is. Ha nem szeretnénk saját formázást használni akkor a megfelelő beállítások elvégzése után a textarea-ban található kód beillesztésével végeztünk is. Ellenkező esetben ismét a második <script> tagben lévő linket kell kimásolnunk. A callback után most írjuk az updateLinks függvénynevet, valahogy így:

http://www.google.com/reader/public/javascript/user/AZONOSÍTÓ/state/com.google/broadcast?n=15&callback=updateLinks

Az n utáni szám átírásával tudjuk meghatározni, hogy hány darab elemet kapjunk vissza. Az updateLinks függvény is hasonlóan fog kinézni, mint az előző updateBlogroll:

function updateLinks(data)
{
	var parent = $('link-list');
	parent.innerHTML = '';
	var len = data.items.length;
	for (var i = 0; i < len; ++i)
	{
		parent.insert('<li><a href="'+data.items[i].alternate.href+'">'+data.items[i].title+'</a></li>');
	}
}

Természetesen nem csak ennyi adatot kapunk meg az elemekről. Nézzünk pár fontosabbat a teljesség igénye nélkül (a továbbiakért érdemes a kapott fájlba belenézni):

• data.items[i].published
  A bejegyzés publikálásának időpontja Unix timestamp formában.
• data.items[i].summarySnippet
  A bejegyzés rövid, összefoglaló szövege.
• data.items[i].origin.title
  Az oldal neve, ahol megjelent ez a bejegyzés.
• data.items[i].origin.htmlUrl
  Az oldal címe.

Körülbelül ennyi lenne a Google Reader pár hasznos felhasználási módjáról. A jobb oldali sáv "Linkek" és "Blogroll" részében látható a működő példa.

Nagyrészt így vagyok vele én is. Gyakorlatilag a szintaktikájának az alapjait leszámítva nem lenne szükségem semmire a Smarty-ból. Nem érdekel, hogy korlátozni lehet a sablon íróját, hogy a PHP eszköztár csak egy részét használhassa (minek is korlátoznám magam...). Nem érdekel, hogy könnyen és gyorsan lehet hozzá plugineket írni (ha az egész PHP használható lenne, erre nincs is túl nagy szükség). Nincs szükségem semmi ilyesmire.
Sokkal inkább vonz az, ha a nyelvet gyorsan lehet gépelni (pl. mert rövid, minimális speciális karaktert használ és logikus a szerkezete). Az se egy hátrány, ha az elkészült sablon valamilyen szinten olvasható lesz. Nem lenne rossz még, ha egy elfogadható minőségű PHP kódot generálna az én sablonomból, ami aztán elfogadható (a lehető leggyorsabb) sebességgel futna. Az első kettőt még csak-csak teljesíti, de az utolsóval eléggé hadilábon áll a Smarty. Így itt az idő valami más után nézni...

A legkézenfekvőbb dolog a PHP használata lenne erre a célra, ami az első két ponton totálisan megbukik. Kiindulási alapnak viszont jó lesz:

<h1>Valami sablon</h1>

<?php if (5 > 6): ?>
	<p><?php print('5 nagyobb mint 6'); ?></p>
<?php else: ?>
	<p><?php print('5 nem nagyobb, mint 6'); ?></p>
<?php endif; ?>

Mi lenne, ha első körbe a <?php és a ?> helyett a jól megszokott { és } lenne használva?

<h1>Valami sablon</h1>

{ if (5 > 6): }
	<p>{ print('5 nagyobb mint 6'); }</p>
{ else: }
	<p>{ print('5 nem nagyobb, mint 6'); }</p>
{ endif; }

Haladunk, esetleg még a print() helyett bevezethetnénk a PHP rövid tag <?= szerkezetéhez hasonlóan egy {= szerkezetet:

<h1>Valami sablon</h1>

{ if (5 > 6): }
	<p>{= '5 nagyobb mint 6' }</p>
{ else: }
	<p>{= '5 nem nagyobb, mint 6' }</p>
{ endif; }

Pár kényelmességet elősegítő lépés múlva (szóközök, kettőspontok, felesleges zárójelek, pontosvesszők eltűntetése) sikerült eljutnom a végleges formáig:

<h1>Valami sablon</h1>

{if 5 > 6}
	<p>{='5 nagyobb mint 6'}</p>
{else}
	<p>{='5 nem nagyobb, mint 6'}</p>
{if}

Rémisztően hasonlít a Smarty-ra (ez valamilyen szinten cél is volt :)), viszont az ebből fordított PHP kód gyakorlatilag egy az egyben megegyezik az általunk írt sablon kód szerkezetével. Most, hogy megvan az alapvető szintaxis, jöhet a sablonkezelő osztály, ami a fentebb említett több ezer sorhoz képest megvalósult úgy 170 sorból (milyen csodákra képes, ha kihagyunk minden "szemetet", amire nincs szükségünk :)), ami már tartalmaz pár extra funkciót is (mint például a lefordított sablonok újrafordítási szükségességének ellenőrzését). A bemenete egy ilyen template, amiből ezt a PHP kódot generálja, valami ilyesmi kóddal:

<?php
	include('lighty.php');
	
	$l = new Lighty();
	
	$l->assign('list', array('a', 'b', 'c', 'd'));
	$l->display('teszt.tpl');
?>

Amit érdemes ezzel kapcsolatban megemlíteni, hogy a lefordított forrás első sorának elején ott van egy kommentben a fordítás ideje, ami az újrafordítás-ellenőrző számára fontos. Valamint az egész fájl egyetlen egy PHP kódblokkot tartalmaz (ami emlékeim szerint optimálisabb, mint sok-sok kis PHP kódblokk egy sablonon belül). Emiatt vannak felesleges, csak whitespace karaktereket kiíró print() hívások, de ezek megszüntethetőek. És végül, de nem utolsó sorban, a Lighty névre keresztelt sablonrendszer első publikus verziója letölthető innen. A csomagban megtalálható egy teszt.php is, ami a fentebb felvázolt példakódot tartalmazza, valamint az általa használt template fájlok és szükséges könyvtárak is.

És hogy így a végén még a címben említett kérdést is megválaszoljam: szerintem szükség van a sablonnyelvekre, mert nagyban meg tudják könnyíteni az ember életét az által, hogy meggyorsítják a sablonírás folyamatát.

Az "Objektum-orientált JavaScript" című bejegyzésem utolsó példájával kapcsolatban felmerült, hogy kicsit jobban is kifejthettem volna az ott történteket. Mivel ott nem az eseményeken volt a hangsúly, ezért gondoltam egy külön bejegyzésben teszem ezt meg.
A prototype.js az események téren is képes a dolgunkat a végtelenségig leegyszerűsíteni. Egészen addig, amíg mi magunk nem akarjuk a dolgokat "bonyolítani", és bele nem fogunk az objektum-orientáltságban. Ilyenkor kezdődnek a problémák. Tegyük fel, hogy szeretnénk egy olyasmi dolgot megoldani, hogy két gomb segítségével egy harmadik gombra tudunk eseményt tenni, majd azt az eseményt levenni a gombról. Objektumok nélkül nem lenne különösebben nehéz dolgunk:

function add_event(event)
{
	Event.observe('myButton_1', 'click', alert_me);
}
function remove_event(event)
{
	Event.stopObserving('myButton_1', 'click', alert_me);
}

var text = 'Ez a \'text\' tartalma';
function alert_me(event) {
	if (text != null) {
		alert('A \'text\' tartalma: '+text);
	}
	else {
		alert('A \'text\' nincs definiálva!');
	}
}

Event.observe(window, 'load', function(event) {
	Event.observe('myButton_2', 'click', add_event);
	Event.observe('myButton_3', 'click', remove_event);
});

A dolog persze kezd bonyolódni, ha nem csak egy, hanem mondjuk n darab ilyen gomb trióra kell ráhúznunk ezeket az eseményeket, így joggal merül fel az OO-ra az igény. Hirtelen felindulásból a fenti mintájára összedobunk valami ilyet:

var Teszt = Class.create();
Teszt.prototype = {
	initialize : function(alert_button, event_add_button, event_remove_button, text)
	{
		this.alert_object = $(alert_button);
		this.add_object = $(event_add_button);
		this.remove_object = $(event_remove_button);

		this.text = text;

		Event.observe(this.add_object, 'click', this.add_event);
		Event.observe(this.remove_object, 'click', this.remove_event);
	},

	add_event : function(event)
	{
		Event.observe(this.alert_object, 'click', this.alert_me);
	},
	remove_event : function(event)
	{
		Event.stopObserving(this.alert_object, 'click', this.alert_me);
	},

	alert_me : function(event)
	{
		if (this.text != null) {
			alert('A \'text\' tartalma: '+this.text);
		}
		else {
			alert('A \'text\' nincs definiálva!');
		}
	}
};

Event.observe(window, 'load', function(event) {
	var gombok = new Teszt('myButton_1', 'myButton_2', 'myButton_3', 'Ez a \'text\' tartalma');
});

Kódunk több sebből vérzik, gyakorlatilag a halálán van, és a hirtelen támadt pánikban lövésünk sincs, hogy mi a franc baja lehet ennek a látszólag működőképes kódnak. Miközben a prototype.js összes fejlesztőjének rokonságát végigszidjuk, lelünk rá a dokumentációban pár érdekes részletre, valami bind() függvénnyel kapcsolatban.
A probléma az, hogy amikor megnyomjuk az "Esemény hozzáadása" gombot, és lefut az add_event() függvény, az abban a függvényben lévő "this" az nem éppen az lesz, mint amire mi gondolunk. Ahhoz, hogy ez a "this" ugyanaz legyen, mint ami az initialize() függvényben a "this", pár változtatást kell eszközölnünk:

Event.observe(this.add_object, 'click', this.add_event.bind(this));
Event.observe(this.remove_object, 'click', this.remove_event.bind(this));

Ami azt illeti, a dolog működik, csak éppen az alert_me() folyamatosan azt mondja nekünk, hogy a text nincs megadva, pedig de. Mielőtt ismét elővennénk a fejlesztők rokonságát, látjuk, hogy talán az add_event() részbe se ártana egy bind(), hátha ugyanaz a probléma:

Event.observe(this.alert_object, 'click', this.alert_me.bind(this));

És csodák csodájára működik... izé... öhm... majdnem. Hozzáadjuk az eseményt az egyik gombbal, megnyomjuk a gombot, kiírja a megfelelő szöveget, majd levesszük az eseményt, megnyomjuk a gombot, és látjuk, hogy az esemény még mindig rajta van. Ennek az oka az, hogy az Event.stopObserving() segítségével csak elnevezett függvényeket tudunk a megfigyelésből kivonni. De hát ez el van nevezve, az a neve, hogy this.alert_me. Azaz, hogy majdnem az a neve. Mert a mi alert_me() függvényünkön meghívtuk a bind()-et, ami egy névtelen függvénnyel tér vissza, így szivatva meg minket.
Még mielőtt rátérnénk a megoldásra, nézzük meg mi is az a névtelen függvény, hogy biztosan teljesen képben legyünk:

Event.observe(window, 'load', function(event) {
	alert('Névtelen függvény vagyok!');
});

var myFunction = function(event) {
	alert('Én nem vagyok névtelen függvény!');
};
Event.observe(window, 'load', myFunction);

Tehát, az Event.stopObserving() csak a második esetben használható, amikor tudjuk annak a függvénynek a nevét, amit le akarunk állítani. Nincs más dolgunk, mint az initialize() végére fűzni egy sort...

this.alert_event = this.alert_me.bind(this);

...valamint a következőképpen módosítani az add_event() és remove_event() függvényeket:

add_event : function(event)
{
	Event.observe(this.alert_object, 'click', this.alert_event);
},
remove_event : function(event)
{
	Event.stopObserving(this.alert_object, 'click', this.alert_event);
},

A megoldás már csak annyiban kifogásolható, hogy a bind() helyett a prototype.js nyújt számunkra egy másik függvényt is, amit kifejezetten eseménykezelőkre lett kitalálva. Ez a gyönyörű nevű bindAsEventListener(). Miután lecseréltük az összes bind()-ünket erre a függvényre, készen is vagyunk. Egy - remélhetőleg - működő példa megtekinthető itt.