Jeg ved snart ikke hvormange gange jeg er begyndt at indlæse en fil uden at tænkt over filens størrelse først – det varer som regel ikke længe inden ens computer begynder at “blæse” og et simpelt check af rammene viser at de hurtigt er ved at blive fyldt op .

Kan du nikke genkendende til dette scenarie, så vil du sikkert kunne bruge følgende metode til noget.

Step by step…

Løsningen virker meget logisk, men som med alt PHP-kodning, kræver det lige at du har fundet ud af hvilke funktioner der findes til at håndterer dette. Tricket er selvfølgelig kun at læse lidt ad gangen.

Her har jeg taget udgangspunkt i importering af en “;”-separeret CSV-fil, og jeg er interesseret i at læse én linie ad gangen. Om filen er 10, 50, eller 100 MB stor har kun betydning for tiden det vil tage at proceserer den.

En linie i CVS-filen kunne se ud som følgende: ID ; navn ;  email

"1234";"Simon Jensen";"min@email.xyz"

Læsning af CVS-filen

For at åbne en fil og begynde læsningen kan vi bruge PHP-funktionen fopen(<string> $file, <string> $mode). Jeg starter ud med at definerer nogle variable, som jeg vil bruge til at holde styr på hvorlangt jeg har læst i filen, samt hvormange linier jeg vil læse ad gangen.

$read_chars = ($_GET[read_chars] == "") ? 0 : $_GET[read_chars]; //Current position in file
$num_of_lines = 10; //Number of lines to read

$handle = fopen("my_csv_file.cvs");
if($handle) {
    $read_lines = 0;
    while(!feof($handle) && ($read_lines < $num_of_lines)) {
        fseek($handle, $read_chars);
        $line = fgets($handle);
        $read_chars += strlen($line);
        $user = explode(";", $line);
        $read_lines++;
    }
}
fclose($handle);

Ovenstående script er sat til at læse 10 linier per request til filen hvor scriptet kører. Hele humlen ligger i funktionen fseek(<resource> $handle, <int> $read_chars) samt variablen $read_chars. Hver gang while-løkken eksekveret sørger jeg for at hoppe direkte til positionen hvorfra jeg læste sidste, straks herefter læser jeg en enkelt linie vha. funktionen fgets(<resource> $handle), opdaterer min variabel $read_chars, så vi har en nu startpositionen til næste gang.

Ved at ændre variablen $num_of_lines kan vi ændre antallet af linier scriptet skal bearbejde ad gangen. Efter scriptet har bearbejdet $num_of_lines antal linier, vil vi sikkert gerne bearbejde de næste $num_of_lines antal linier – her har jeg taget understående redirect-metode til mig.

Loop til næste “runde” – header- vs. Meta-redirect

Mens overstående script virker fint ved håndtering af $num_of_lines antal linier, skal vi have en løsning til at håndterer de næste $num_of_lines antal linier – og her skal vi tænke på eksekverings tiden, for vi vil jo helst gerne undgå timeouts .

Den umiddelbare løsning kunne være at loop til selv samme fil vha. et header(“Location: …”) kald, men det komme vi detsvære ikke langt med. W3C-standarden har sørget for (og det er jo sådan set også fint nok), at browsere bør implementerer en advarsel hvis et script lopper til sig selv [w3.org].

A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.

En metode jeg er begyndt at bruge mere og mere, er et simpelt meta-redirect tag på en ganske almindelig HTML-side – meta-redirects lader til, uden problemer, at komme ud over ovenstående W3C restiktion.

<meta http-equiv="refresh" content="0; URL=http://redirect-url-goes-here.xyz">

Sammenfatning

For at få det hele til at spille sammen, skal vi ganske simpelt redirecte vores PHP-script med $read_char som parameter til HTML-siden, som efterfølgende redirecter tilbage til PHP-scriptet hvor vi kan starte læsningen hvor vi slap.

script.php:

$read_chars = ($_GET[read_chars] == "") ? 0 : $_GET[read_chars]; //Current position in file
$num_of_lines = 10; //Number of lines to read

$handle = fopen("my_csv_file.cvs");
if($handle) {
    $read_lines = 0;
    while(!feof($handle) && ($read_lines < $num_of_lines)) {
        fseek($handle, $read_chars);
        $line = fgets($handle);
        $read_chars += strlen($line);
        $user = explode(";", $line);
        $read_lines++;
    }
}
fclose($handle);

$redir = "redir.php?read_chars=".$read_chars;
header("Location: $redir");

redir.php (HTML-siden):

<?php
$read_chars = $_GET[read_chars];
$redir = "script.php?read_chars=".$read_chars;
?>
<html>
    <head>
        <meta http-equiv="refresh" content="0; URL=<?php echo $redir; ?>">
    </head>
<body>
</body>
</html>

Med ovenstående kan du nu håndterer dine relativt store filer uden at skulle sparke din computers ram i gulvet – der skal ikke meget fantasi til at kaste en “total antal linier”-variabel med, og med en smule procent-beregning udskrive en statusbar på HTML-siden, og så har du din helt egen “processerings maskine” med statusbar på .

Mens sidste post om hijax kort fortalte princippet bag hijax, og snakken mere gik på “hvorfor” man burde bruge det, har jeg nu haft mulighed for rent faktisk at lege lidt med hijax, og mener nu der skulle være basis for at skrive endnu en post herom.

Hijax super kort

Jeg har taget udgangspunkt i et simpelt eksempel, som jeg selv synes forklare det praktiske bag princippet. Super kort fortalt, så går hijax ud på at “hijacke” (overtage) funktionalitet på din hjemmeside og udføre denne via AJAX, men SAMTIDIG skal det være muligt at afvikle samme funktionalitet UDEN brug af Javascript – grundtanken i graceful degradation.

Hijax en formular

Hijax kan f.eks. bruges i forbindelse med en formular – I denne post har jeg taget udgangspunkt i en simpelt udgave af en tilmeldingsformular til et tænkt nyhedsbrev, men i princippet kan hijax bruges til en hvilken som helst formular.

HTML formularen:

Formularen er meget standard med to inputs og postering via POST-metoden. Vi kan bruge onsubmit-attributten til at hijacke formularen. onsubmit giver os nemlig mulighed for at udføre en stump Javascript før dataen vil blive postet til serveren. I eksemplet herunder tager jeg hele formularen med som parameter til Javascript funktionen hijax(form). For at være sikker på at det “almindelige” POST ikke bliver udført returnerer vi false efterfølgende… da dette faktisk er direkte Javascripting i formularen vil dennes postering kun stoppes hvis Javascript er understøttet.

<form method="post" action="signup.php" onsubmit="hijax(this); return false;">
    <label>Name:</label>
    <input type="text" name="name"   />
    <label>E-mail:</label>
    <input type="text" name="email"   />
    <input type="submit"   />
</form>

Javascriptet:

Selve Javascriptet behøver ikke være mere indviklet end vist herunder. Jeg har endnu engang taget udgangspunkt i et AJAX request med Prototype JS.

Her serializerer jeg hele formularen, og tilføjet en ekstra parameter hijax=true. Selve værdien er denne parameter bruger jeg faktisk ikke til noget, hvilket du vil kunne se i understående PHP-script. Vi poster det hele til PHP-filen signup.php, hvilken også var action-fil i HTML-formularen ovenfor.

hijax = function(formular) {
    var url = signup.php;
    var params = Form.serialize(formular) + &hijax=true;
    new Ajax.Request(url, {method:post, postBody:params});
}

PHP serveren:

Som programmør forsøger jeg at være doven!? Jeg vil gerne have et optimalt resultat af min kode, og jeg vil skrive så få linier som muligt. Og her er hijax fantastisk, for ligemeget om vi posterer formularen “almindeligt” eller via AJAX, kan vi bruge samme fil til at håndtere posteringen.

Da jeg også forsøger at være lidt af en sucker for brugervenlighed, vil jeg gerne have mulighed for at give brugeren et response ligemeget om denne har Javascript-understøttelse eller ej. Tricket er altså at kunne adskille de to posteringer fra hinanden. Jeg har brugt den ekstra parameter ved AJAX-posteringer, men du vil sikkert selv kunne komme på andre løsninger (tilføj dem gerne i kommentaren)?

<?php
session_start();
$name = mysql_real_escape_string($_POST[name]);
$email = mysql_real_escape_string($_POST[email]);
$isHijax = $_POST[hijax];
mysql_query("INSERT INTO signups (name, email) VALUES ($name, $email)");
if(isset($isHijax)) {
    echo Saved using AJAX...;
} else {
    $_SESSION[message] = Saved using normal post...;
    $redirect = $_SERVER[HTTP_REFERER];
    header("Location: $redirect");
}
?>

Med ovenstående metode vil du kunne “hijaxe” en formular, og med lidt få ændringer i formularens action-fil, vil du også have mulighed for at give brugerene et response, ligemeget om de bruger AJAX eller ej – Det er skudda smart .

Download

Hijax af en formular (.zip)

Da PHP5 udkom, var der en del hype om forbedringer i henhold til at kode objekt orienteret heri, der er bl.a. introduceret en ny måde at lave constructors på samt mulighed for at bestemme public/private/protected identifyers til funktioner.

Hvor man i PHP4 blot skulle defineret constructors som en funktion med samme navn som klassen, kan man nu bruge __construct() og evt. __destruct() – men hvad med overloading af constructors?

I sprog som f.eks. C# og Java overloader du constructors blot ved at tilføje endnu en funktion med klassens navn, og med et unikt antal parametre:

class Test {
    public Test() {
        //Default constructor
    }
    public Test(int foo) {
        //Constructor using 1 parameter
    }
    public Test(int foo, int bar) {
        //Constructor using 2 parameters
    }
}

Det skulle være forholdsvis let at komme til at tro, at man kunne udføre noget lignende i PHP5, nu det jo er kommet med på noderne  - men sådan forholder det sig ikke helt. Jeg forsøgte f.eks. til at starte med, at lave en overloading ved noget ligende:

public function __construct($foo) {
    //Constructor using 1 parameter
}

Men da jeg samtidig havde defineret en standard constructor, fik jeg en fejlmelding:

Fatal error: Cannot redeclare Test::__construct()

Underligt tænkte jeg, og begyndte at Google overloading af constructors lidt. Og det lader åbenbart til at være et generelt problem/irritationsmoment.

Constructor overloading work-around

Jeg fandt dog frem til følgende work-around, hvilket virker udemærket – men ærlig talt, hvorfor har man dog lader et så basal ting udeblive i et sprog nu man alligevel var igang med at forbedre dets muligheder for OOP?!

public function __construct() {
    $num = func_num_args();
    $args = func_get_args();
    switch($num) {
        case 1:
	    $this->__call(__construct1, $args);
	    break;
        case 2:
            $this->__call(__construct2, $args);
	default:
	    //Do default stuff
	}
}

Ved at "switche" på antallet af input parametre til constructoren (også selvom man ikke skal definere dem i selve constructoren – WTF?), og benytte en interne function __call, som meget simpelt kalder en anden funktion med de sendte input paramtre, kan man få sin kode til at "se ud til" man overloader constructoren.

I virkeligheden kalder vi bare nogle andre funktioner, her meget søgt kaldet __construct1/2/3, alt efter antallet af parametre.

public function __construct1($param) {
    //do stuff with your one parameter
}

public function __construct2($param1, $param2) {
    //do stuff with 2 parameters!
}

Funktionen til at kalde vores "overloadede constructors" ser ud således:

private function __call($name, $arg) {
    return call_user_func_array(array($this, $name), $arg);
}

Løsningen fungere udemærket, om ikke andet er det da rimelig transparent for den der efterfølgende skal bruger klassen… Ved ikke helt hvad jeg synes om det, men indtil andet er på plads (i PHP), så vil jeg tro dette er måden at gøre det på.

Er der nogen der er kommet frem til andre måder at overloade constructors på i PHP?

Lige siden min kæreste, for nu snart 3 år siden, købte sig en iBook, har jeg haft et misundeligt blik i øjnene hver gang den blev hevet frem. Lad mig bare sige det med det samme … jeg har svaghed for eye-candy, funky features og design

Nu kom dagen så, hvor jeg stod i en situation, hvor jeg (igen) skulle ud og erhverve mig en ny computer – og denne gang tog jeg springt til Mac!

Det er ikke fordi jeg, ligesom visse andre, nødvendigvis synes PC og Windows har været noget være lort! Faktisk har jeg været riigtig glad for den sidste PC jeg havde (Dell XPS M1330), og har ikke oplevet nogle bemærkelsesværdige problemer med Windows Vista – nu var jeg bare klar til at prøve en Mac.

Out of the box … and ready!

Når PC nu har fået et (sidste) klap på skulderen, må jeg jo nu nok også hellere gøre det samme med Mac!

Jeg valgte ovenstående video (ud af maaaaaange rigtig sjove) fra Apple, fordi noget af det første der slog mig var hvor hurtigt man faktisk var igang med at bruge maskinen! Nu ved jeg godt, at jeg nok selv ender med at komme til at lyde som en af de der “frelste nørder” som har fundet lykken i en Mac (har selv et par af de dem), men jeg kan ikke komme uden om det – en Mac kommer med det man skal bruge, og ikke andet!

Jeg er webprogrammør med en hæftig træng til PHP (hvilket jo er platformsuafhængig), så det skulle jo ikke blive noget problem at kode på en Mac! Det er det absolut heller ikke – men jeg havde ikke regnet med at det skulle være SÅ let at komme igang! Mac´s OS Leopard kommer nemlig præ-installeret med en Apache webserver samt PHP – alt alt jeg skulle gøre var at trykke på en knap for at aktivere det … næsten da.

Opsætning af PHP på Mac

Apache servere er helt standard, og kan startes og stoppes ved et tryk på en knap … for at aktivere PHP på Mac, skal der fjernes udkommenteringen af én linier i Apaches konfigurations fil.

Åben en konsol og åben konfigurationsfilen f.eks. med “pico”:

pico /etc/apache2/httpd.confg

Find følgende linie, og fjern #-tegnet foran linien, så den står som herunder:

LoadModule php5_module libexec/apache2/libphp5.so

Genstart, eller bare start, “Websharing” fra “System Preferences => Sharing” og du skulle være klar til at bruge PHP på Mac!

…

Og nååhhh ja – så er der kommet nyt design på bloggen (igen) – se hvordan det har set ud før på min Flickr.

Grunden til at du måske har siddet og mumlet lidt i skægget, skal findes hos webbrowseren, det er nemlig her restriktionen ligger. Jeg tror ikke jeg kan forklare det meget bedre end Yahoo!, som skriver følgende:

All modern web browsers impose a security restriction on network connections, which includes calls to XMLHttpRequest. This restriction prevents a script or application from making a connection to any web server other than the one the web page originally came from.

But fear not – der selvfølgelig en løsning …

No-go scenariet

Lad os starte med at forklare no-go scenariet visuelt (tak til Yahoo! for allerede at have lavet grafiken ).

Har du en webapplikation, som findes på en webserver, og afvikles i en browser hos den besøgende, kan det altså ikke lade sig gøre, at lave et request til en ekstern server/service som f.eks. Yahoo! via XMLHttpRequest (AJAX) – Dette sørger browseren for, vha. den omtalte restiktion ved denne type kald.

Et sådanne forsøg, vil se ud som herunder:

Do-go scenariet

Vi ved altså at restiktionen ligger hos browseren – Samtidig kan jeg så fortælle, at det godt kan lade sig gøre at lave et request fra domænets server til en anden ekstern server/service/domæne. Når det er sagt, så kan du vel næsten gætte dig til, hvordan vi kan overkomme at lave et AJAX-request til et andet domæne?!

Jeps – I stedet for at lave AJAX-requestet direkte til den eksterne server, kalder vi en proxy, på vores egen server. Med proxy, menes faktisk bare et script som sender kaldet videre til den eksterne server, samt leverer responset herfra tilbage til browseren.

Scenariet ser ud som herunder:

En sådanne proxy kan laves på flere måder. Hos Yahoo! kan du downloade en version som benytter CURL. Jeg har leget med en version som benytter sig af PEAR.

Proxy med PEAR HTTP/Request

PEAR er et stort framework som fungerer som et pakke-system. PEAR leverer pakker/klasser til mere eller mindre alt, hvad du kunne tænke dig – men for at lave vores omtalte proxy, skal vi faktisk ikke bruge andet, end en standard PEAR-error-klasse samt en Request-klasse til en HTTP pakke – det lyder indviklet?! Bare rolig, du kan downloade det hele i slutningen af denne post .

Server proxy

Et lidt simplificeret eksempel på en proxy med PEAR, ser ud som herunder:

<?php
require_once "HTTP/Request.php";

$url = $_REQUEST[url];
$req =& new HTTP_Request($url);

if (!PEAR::isError($req->sendRequest())) {
    print $req->getResponseBody();
}
?>

Klienten / Javascriptet

Proxy-scriptet skal altså modtage den URL som den skal hente. Der oprettes et objekt af typen HTTP_Request, som vi kan bruge til at sende requestet videre med, samt “print” responset. Responset skal herefter modtages på klient-siden, og endelig udskrives – dette kunne se ud som herunder:

proxy_request = function()
{
    $("loading").toggle();
    var info = function(t) {
        $("loading").toggle();
        $("status").innerHTML = t.responseText;
    };

    var url = proxy.php?reg_url=   encodeURIComponent("http://flickr.com/photos/simon_jensen/");
    new Ajax.Request(url, {method:get, onSuccess:info, onFailure:info});
}

Download

Cross Domain AJAX Request (.zip)

Jeg vil ikke gå meget i dybden med begrebet duplicate content – det er vidst beskrevet op til flere gange – jeg vil lige forklare lidt om hvordan det kan opstå, for herefter at give et foreslag til hvor let det egenligt er, at komme ud over!

Sådan kan duplicate content opstå

Mange dynamiske sider henter deres indhold fra en database ved direkte, at lave en query med f.eks. et ID. Forestil dig URLen:

/index.php?pageID=123

index.php kunne hente og udskrive indholdet fra databasen, hvor id er 123, ved følgende simple query:

$ID = mysql_real_escape_string($_GET["pageID"]); //secure string for DB
$query = mysql_query("SELECT content FROM content WHERE id=".$ID."");
$dbObj = mysql_fetch_object($query);
echo $dbObj->content;

Ovenstående vil ofte virke som man regner med, men “/index.php?pageID=123” er langt fra den eneste URL der giver det forventede resultat. Hvad med følgende:

/index.php?pageID=123&somevar=asdf

/index.php?pageID=123&somevar=asdf&someothervar=blabla

/index.php?pageID=123&yetanother=irrelevant

Da alle ovenstående URLer har sat variablen pageID til 123, hvilket er alt hvad vores database query skal bruge, vil samtlige URLer give samme resultat! De efterfølgende variabler (somevar, someother, yetanother) er altså irrelevante, men linket kan stadig figurerer og virker altså lige så godt som den oprindelige!

Sådan kan duplicate content undgåes

Jeg har tidligere haft skrevet om mod_rewrite modulet til Apache, hvilket lader dig omskrive en URL, for herefter at parse denne til specifik fil.

Idag laver jeg ikke en PHP-løsning uden at bruge mod_rewrite, og løsningen ligger så meget op til, at man skal verificerer den indkommende URL, at duplicate content nemt bliver elimineret i processen. Det skal dog nævnes, at denne løsning også sagtens kan lade sig gøre, hvis du benytter URLer som i eksemplet ovenfor!

Jeg har til hver af mine poster et felt i databasen som indeholder den fulde URL (uden domænenavn) til hver post. I tilfældet af denne post, er værdien som du nok har gættet:

/dynamiske-urler-uden-duplicate-content.html

Når du går ind på denne URL, skal jeg for at hente indholdet, lave en query til min databasen. Da jeg ikke har en pageID variabel eller lignende, benytter jeg den fulde URL som identifyer (læs: id). Queryen kunne se ud, nogenlunde, som følgende:

$url = mysql_real_escape_string($_SERVER[REQUEST_URI]); //secure string for DB
$query = mysql_query("SELECT content FROM content WHERE url=".$url."");
$dbObj = mysql_fetch_object($query);
echo $dbObj->content;

Prøver du at tilføje ekstra variabler til denne post, vil du se, at du får en 404 fejl. Dette gøres ganske simpelt, ved lige at checke om queryen også gav noget resultat, og hvis ikke, kaste en header med en fejlkode inden der forsøges at udskrive noget:

//query goes here...
...
if(empty($dbObj)) {
    header("HTTP/1.1 404 Not Found");
    header("Status: 404 Not Found");
    exit();
} else {
    echo $dbObj->content;
}

For at den besøgende ikke bare møder en kedelig standard 404-side, kan du designe en speciel side, som du vil bruge til dette formål – tilføj følgende linie i din  .htaccess, for at henvise 404-fejl til en speciel side:

ErrorDocument 404 /404.php

I forbindelse med det sidste nye redesign, har jeg oprettet en “Live search”. Nåhhh ja, den er måske ikke så live som en definition vil have det – men det er da en fed feature – og funktionaliteten bag den, vil jeg da gerne dele med jer.

Denne post består således af en gennemgang, af de vigtigste punkter i implementeringen, det være sig lidt XHTML, CSS, Javascript samt PHP.

I slutningen af posten, kan du desuden downloade en lille demo-version af funktionen.

For at benytte koden i denne post kræves det, at du har downloaded og inkluderet Javascript frameworket Prototype JS, samt effektbiblioteket script.aculo.us. Disse skal inkluderes i sidens <head>-sektion, som med et hvert andet Javascript.

XHTML

Jeg har gjort det til god skik, at oprette en “container”-div. Dette div er ikke nødvendig, men her er det taget med for at få bare en smule design med.

Inde i denne container findes et billede, som er stylet til at være skjuldt. Dette er hvad jeg bruger som loading animation – altså en animation der skal vise, at et script arbejder. Input feltet skulle gerne tale for sig selv. Straks herunder er der, i endnu et div, oprettet en ul/li-liste – det er denne vi vil fremvise resultater i. Resultaterne skal ligeledes fremkommet/tilføjes som li-elementer til listen.

<div id="container">
    <img src="loading.gif" id="lsloading" align="right" alt="" style="display:none;"  />
    <input type="text" value="Type and you´ll find..." id="lsquery"  />
    <br  />
    <div id="lsresults" style="display:none;">
        <ul id="lsResList">
            <li><i>Type and you´ll find...</i></li>
        </ul>
    </div>
</div>

CSS

CSS delen af dette script, taler også lidt for sig selv. Det er muligt, at designer kan laves en hel del nemmere (læs: med mind css), men her er indsat hvad du finder i demoen.

Det vigtigste her, vil nok være at påpege, at resultatlisten er sat til absolut positionering. Dvs. vi kan vise den ovenpå andre elementer, hvorfor den ikke skal til at “skubbe” rundt på designet. Du har måske bemærket at resultatlisten er en smule gennemsigtigt – Dette ER en CSS feature, men den bliver udført gennem Javascript-delen.

body {
    font-family: "Trebuchet MS";
    font-size: 1em;
    background: #333;
}

#container {
    background: #fff;
    width: 400px;
    padding: 20px;
    margin: 0 auto;
}

#container #lsloading {
    position: relative;
    top: 5px;
}

#container input {
    font-family: "Trebuchet MS";
    font-size: 1em;
    width: 350px;
    margin-left: 20px;
}

#container #lsresults {
    position: absolute;
    background: #fff;
    color: #333;
    width: 354px;
    margin-left: 20px;
}

#container #lsresults ul {
    list-style: none;
    margin: 0px;
    padding: 0px;
}

#container #lsresults ul li {
    list-style: none;
    margin: 10px;
    padding: 0px;
}

Javascript

Javascriptet er den største del af denne “applikation”. JS-delen består af et Live Search objekt (ls) med metoderne init(), search(), showResults() og hideResults(). Derudover bliver der, når en side er loaded,  initialiseret nogle observer eventhandlers på søgefelter.

Humlen ligger i init() og search() metoderne. init() bliver kaldt hver gang der tastes i søgefeltet, og denne kalder search() som udføre et AJAX-kald til serveren, som levere selve søgningen. For ikke at spamme serveren er der indbygget en timer i init() metoden som gør, at search() metoden kun bliver kaldt hvis der ikke er tastet noget i søgefeltet i 0.5 sekunder.

/**
 * Live search
 */
var ls = {
	queryField: "lsquery", //id name of queru input-field
	results: "lsresults", //id name of result-list
	loading: "lsloading", //id name for loading animation
	timer: null,

	/**
	 * Initialize a search:
	 * reset timer, and performe search
	 * if nothing has been typed in 0.5 sec.
	 */
	init: function(event) {
		var query = Event.element(event).value;
		ls.timer = clearTimeout(ls.timer);
		if(query != "" || query != "Type and you´ll find...") {
			ls.timer = setTimeout("ls.search(" query ");", 500);
		}
	},

	//start a search using AJAX
	search: function(query) {
		if(query != "") {
			$(ls.loading).show();
			var done = function(t) {
				$(ls.loading).hide();
			}
			var url = php-backend.php;
			var pars = action=search&query=   query;
			new Ajax.Updater(lsResList, url,
			{
				method: post,
				parameters: pars,
				onSuccess:done,
				onFailure:done,
				inserting:Insertion.Before
			});
		}
	},

	//show the result list
	showResults: function() {
		if($(ls.results).getStyle(opacity) != 0.9)
			new Effect.Appear(ls.results, {duration:0.2, from:0.0, to:0.9});
	},

	//hide the result list
	hideResults: function() {
		new Effect.Opacity(ls.results, {duration:0.2, from:0.9, to:0.0});
	}
}

/**
 * Initialize key-observers for search input field.
 */
Event.observe(window, load, function() {
	$(ls.queryField).observe(keyup, ls.init);
	$(ls.queryField).observe(keydown, ls.init);

	//remove input field value when first focused
  	$(ls.queryField).onfocus = function() {
  		if($(ls.queryField).value == "Type and you´ll find...")
			$(ls.queryField).value = "";
		ls.showResults();
	}

	//reset input field when not focused and value is ""
  	$(ls.queryField).onblur = function() {
  		if($(ls.queryField).value == "")
  			$(ls.queryField).value = "Type and you´ll find...";
  		ls.hideResults();
  	}
});

PHP

PHP delen, er hvad jeg ovenfor har kaldt “serveren”. Hvordan du vil udføre selve søgningen er mere eller mindre op til dig selv. Vælger du at benytte dette script, skal resultaterne dog returneres som én streng. Hvert resultat skal, for at designet holder stik, leveres som et <li>-element.

Bare for at give en ide, leveres scriptet med følgende PHP backend.

<?php
/************************************************************************
 * Here you would probably perform som DB-search.
 * In this example, you will only find a hit, when typing a string that -
 * is in the array $results.
 ************************************************************************/
if($_POST["action"] == "search") :
	$query = utf8_decode(urldecode($_POST["query"]));
	$results = array("","webprogrammering","blog","ajax","javascript","php","css");
	$key = array_search($query, $results);
	if($key) :
		echo "<li><a href="#">"".utf8_encode($results[$key])."" found with key: ".$key."</a></li>";
	else :
		echo "<li><i>Intet resultat</i></li>";
	endif;
endif;
?>

Som beskrevet i kommentaren, vil man selvfølgelig lave en reel database søgning eller lignende, hvilket lige nøjagtig er hvad jeg gør her på sitet.

Sååå – uden yderligere forklaringer skal du være velkommen til at downloade, modificere osv. følgende version af Live Search. Skulle der opstå problemer, eller mangler du yderligere forklaring, skal du endelig kommentere nedenfor.

Download

Live Search med Prototype JS og PHP (.zip)

Live Search med Prototype JS og PHP (Æ,Ø,Å understøttet) (.zip)

Dette må være et af de spørgsmål langt de fleste bloggere, online-shop-ejere, og andet online-folk, har spurgt sig selv om, fra tid til anden. Jeg siger ikke at hele svaret kommer i denne post, men af egne erfaringer vil jeg våge at påstå, at RSS kan have en hel del at sige. Måske du allerede vidste det, men en RSS feed giver dig ufatteligt mange muligheder for at distribuere din sides poster, produkter, nyheder eller hvad det ellers måtte være.

RSS Feeds

Snart alle blogs, og nu også de fleste public-service/offentlige-sites er ved at være med på vognen, når vi blot snakker om at have en RSS feed – hvad jeg detsvære ikke ved så meget om er, om disse sites også gør noget for at videre distribuere denne feed til andre services/medier.

En af de store forcer ved RSS feeds er, at de er formateret i XML. At en feed er formateret i XML betyder groft sagt bare, at alt det “designmæssige” bliver fjernet, hvorefter kun selve “indholdet” er tilbage og kan sendes videre. At en feed ikke indeholder noget design, og er i form af “ren tekst”, betyder at den efterfølgende er pændt nem at “transportere” og benytte i andre sammenhænge – som f.eks. kunne være på en mobiltelefon.

En RSS feed lader sig også forholdsvist nemt downloade, transportere og implementere fra site til site (også bare kaldet parsing), som jeg også beskrev i posten “RSS til alle” – Parsing er f.eks. hvad du har mulighed for at gøre på Google´s personlige side iGoogle, i din online feed reader og mange andre steder.

RSS/Ping Services

Netop til parsing og visning af RSS feed, findes der adskillige dedikerede sites rundt omkring på nettet, og det er faktisk disse sites denne post reelt handler om, og som jeg vil prøve at gøre lidt reklame for.

Langt de fleste af disse sites har en såkaldt ping service. En ping service er, som navnet antyder, en service til at håndtere et såkaldet ping! Et ping er kort sagt en forespørgsel fra en computer til en anden. I RSS sammenhænge lyder denne forespørgsel nogenlunde således:

Hej ping service … vil du ikke lige se om du kan finde noget nyt på min side. Adressen er www.simon-jensen.net – hilsen Simon Jensen.

Herefter, hvis ellers pinget er formateret korrekt, vil ping servicen gennemgå dit site (feed), og se om der ikke godt nok skulle være kommet noget nyt, siden sidst denne fik et ping. Servicen finder din nye post/produkt, og et link, samt en lille beskrivelse, vil blive tilføjet til ping servicens side.

Du har nok fået fat i ideen – Det at sende et ping kan automatiseres, så det bare sker hver gang du opretter en post. Du kan lige ledes sende et ping til flere ping services. For hver service der optager din forespørgsel, kan du glæder dig over at have fået et indgående link – og dem vil vi jo gerne have . Se evt. denne side:

http://overskrift.dk/feed/bb5eb40b82e08c314b232b690e8157ba69137ab5

Der findes sågar ping services, som sørger for at sende din forespørgsel videre til andre ping services – man kommer selvsagt hurtigt ud til at mange “medier”. Her er et par links til lidt mere læsning om ping services – et par af dem, lader dig faktisk pinge direkte fra deres side af:

http://blogbot.dk/info/xmlrpc.php

http://blogs.feedburner.com/feedburner/archives/000478.html

http://www.overskrift.dk/about/ping.php

http://pingomatic.com/

http://codex.wordpress.org/Update_Services

De fleste af de mest udbredte blogging tools, har allerede indbygget funktionalitet til at sende et ping – men sidder du, som jeg, og leger med din egen blog (i PHP vel og mærket), har jeg tastet følgende ping-klasse sammen (med hjælp fra en implementering hos Blogbot.dk), som du skal være velkommen til at benytte som du vil.

class.PING.php – PHP Ping klasse

Du kan downloade denne klasse, samt et eksempelt nederst på denne side.

<?php
/**
 * Filename: class.PING.php
 *
 * @author Simon Jensen @ http://www.simon-jensen.net
 */

class PING
{
	/**
	 * URLs to ping.
	 * @var array
	 */
	public $pingUrls = array(
		"http://www.overskrift.dk/ping/",
		"http://blogbot.dk/io/xml-rpc.php",
		"http://rpc.pingomatic.com/",
		"http://rpc.weblogs.com/RPC2",
		"http://rpc.technorati.com/rpc/ping",
		"http://ping.weblogs.se/",
		"http://ping.feedburner.com",
		"http://api.feedster.com/ping"
		);

	/**
	 * Your website title here.
	 * @var string
	 */
	public $weblogName = "Your title goes here...";

	/**
	 * URL for your website.
	 * @var string
	 */
	public $weblogUrl = "http://localhost/Testing/ping/";

	/**
	 * Turn debugging on/off
	 * @var bool
	 */
	public $debug = false;

	/**
   	 * Default constructor
   	 *
   	 * @return PING
   	 */
  	function __PING() {}

  	/**
	 * Send a XLM-RPC ping to a specific URL.
	 *
	 * @param string $pingUrl - url to ping.
	 * @return string error msg.
	 */
	private function sendPing($pingUrl)
	{
	    $postdata = <?xml version="1.0"?>
	       <methodCall>
	         <methodName>weblogUpdates.ping</methodName>
	         <params>
	           <param><value><string> .
	                preg_replace(|[x80-xFF]|e, "&#".ord("").";", $this->weblogName) .
	                </string></value></param>
	           <param><value><string> . htmlspecialchars($this->weblogUrl) . </string></value></param>
	         </params>
	       </methodCall>;

	    $timeout = 20;

	    $parts = parse_url($pingUrl);
	    if (!isset($parts[host])) :
	        return array(-1, "Malformed URL:
" . $pingUrl);
	    endif;

	    $host = $parts[host];
	    $port = isset($parts[port]) ? $parts[port] : 80;
	    $path = isset($parts[path]) ? $parts[path] : /;
	    if (isset($parts[query])) :
	        $path .= ? . $parts[query];
	    endif;

	    $fp = @fsockopen($host, $port, $errno, $errstr, $timeout);
	    if (!$fp) :
	        return array(-2, "Could not connect to $host:$port");
	    endif;

	    socket_set_timeout($fp, $timeout);

	    $request = "POST $path HTTP/1.0
" .
	        "Host: $host
" .
	        "Content-Type: text/xml
" .
	        "User-Agent: Aggemam XML-RPC client
" .
	        "Content-Length: " . strlen($postdata) . "
" .
	        "
" .
	        $postdata;
	    fputs($fp, $request);

	    if ($this->debug) :
	        print "<div style=color: blue; white-space: pre>";
	        print htmlspecialchars($request);
	        print "</div>";
	    endif;

	    $response = ;
	    while (!feof($fp)) :
	        $response .= fgets($fp, 1024);
	        $status = socket_get_status($fp);

	        if ($status[timed_out]) :
	            fclose($fp);
	            return array(-3, "Request timed out");
	        endif;
	    endwhile;

	    fclose($fp);

	    if ($this->debug) :
	        print "<div style=color: green; white-space: pre>";
	        print htmlspecialchars($response);
	        print "</div>";
	    endif;

	    if (preg_match(|<name>flerror</name>s*<value>s*<boolean>([^<])</boolean>s*</value>|, $response, $reg1) && preg_match(|<name>message</name>s*<value>(s*<string>)?([^<]*)(</string>s*)?</value>|, $response, $reg2)) :
	        return array($reg1[1], $reg2[2]);
	    else :
	        return array(-3, "Malformed reply:
" . $response);
	    endif;
	}

	/**
	 * Send a XLM-RPC pings to each URL in $this->pingURLs
	 *
	 * @return string error msg.
	 */
	public function sendPings()
	{
		foreach ($this->pingUrls as $pingUrl) :
		    print "<p>Pinging $pingUrl ... ";
		    flush();

		    list($error, $message) = $this->sendPing($pingUrl, $this->weblogName, $this->weblogUrl, $this->debug); 

		    if ($error == 0) :
		        print "Ping recieved!</p>";
		    else :
		        print "Something went wrong:</p>";
		        print "<p style=font-size: smaller; color: red; white-space: pre>" . htmlspecialchars($message) . "</p>";
		    endif;
		endforeach;
	}
}
?>

Eksempel

Følgende eksempel findes også i .zip-filen, som du kan downloade herunder.

require_once("class.PING.php");
$ping = new PING();

/**
 * Turn debuggin on/off
 */
$ping->debug = true;

/**
 * You can also just edit the variables in the class
 */
$ping->weblogName = "Your website title here";
$ping->weblogUrl = "http://your-site-here.com";

/**
 * Overwrite the URLs to ping if desired.
 */
//$ping->pingUrls = array("http://rpc.pingomatic.com/", http://www.overskrift.dk/ping/");

/**
 * Send a ping to all URLs in $ping->pingUrls.
 */
$ping->sendPings();

Download

class.PING.php

Jeg skal fra start af være ærlig og give massere af credit til Think Vitamin, for deres artikkel omkring internationalisering af websites, da denne post ikke var blevet til uden at jeg havde læst deres først (backtrack med ord ).

Først vil jeg starte ud med at fortælle lidt om den metode som jeg havde i tankerne i starten af forløbet, og forklare lidt om hvorfor det ikke blev denne vi anvendte i sidste ende. Hvis du blot vil læse om den “optimale måde”, kan du springe dette skridt over, og gå direkte til gettext-metoden.

En ikke helt optimal metode

En af de første metoder jeg var inde på, var associative arrays metoden. En metode hvor du, for hvert sprog i din applikation, opretter et array. Arrayet får som index den streng der skal oversættes, og som værdi den oversatte streng.

Følgende eksempel viser hvordan du ville kunne bruge associative arrays, til at implementerer strenge på dansk og engelsk. For at udvide med flere sprog, skal du blot oprette endnu et array, og tilføje cases til switch-funktionen:

Det lader jo til at virker meget fint – og det gør det da også langt hen ad vejen. Men hvad nu hvis ud kommer til at lave en stavefejl? Hvis du f.eks. glemmer et “t” i “fortsætte”, når du vil udskrive den oversatte tekst. Tja – Alt efter hvilket programmeringssprog du benytter, vil der opstå problemer af en eller anden art. Den mildeste heraf vil blot undlade at vise nogen tekst overhovedet, da der jo er angivet et ikke-eksisterende index = ingen værdi/tekst. I værste fald vil hele din applikation kaste en fejl, og siden vil ikke være brugbar. Dine brugere vil højst sansynligt blive efterladt i total forviring, og sitet synes pludseligt at forekomme rimelig uprof!

En anden ting, som kan være besværlig, ved brugen af associative arrays, er vedligeholdelse. Det kan hurtigt blive uoverskueligt at skulle finde/opdaterer/slette eller oprette en enkelt streng i alle “sprogene” – og det kommer man jo nok ikke udenom! Forestil dig at du har bare 100 strenge, af forskellige længder, som du skal have i flere forskellige sprog. Du kan selv lave den danske, muligvis andre, men hvordan vil du præsenterer dette for din oversætter? Det er ikke sikkert at denne har et pind forstand på programmering, og bare synet af et array vil skræmme personen og få opgaven til at virke liiiidt for kompliceret! Du kunne så selvfølgelig vælge at skrive hvert streng på en linie i et andet dokument, men så skal du til at kopiere/indsætte alle strengene på den rigtige plads i arrayet – for hvert eneste sprog! Naahhh…

Okay – jeg tror jeg har gjort det klart nok. Associative arrays er ikke den mest optimale løsning – men hvad er det så? Som den PHP-nørd jeg nu en gang er endt ud med at blive, søgte jeg selvfølgelig svaret i dette sprog – Og hvad jeg kom frem til var det dedikerede GNU Projekt gettext (som vidst også kan findes til andet end PHP).

Oversættelse med gettext

Nu har jeg jo været inde på nogle af de problematikker der kan ligge i f.eks. at bruge associative arrays, så for at gøre en lang historie kort, så kommer du selvfølgelig ud over disse ved at benytte gettext. Gettext introducerer samtidig en fantastisk måde at adskille kode fra indhold (læs: tekst), og når det endelig er sat op, er det enormt nemt at vedligeholde.

Ved at gennemfører følgende 6 trin, kan du for alvor nyde effekten af gettext:

1. Den tekst du skal have oversat skal parses gennem PHP-funktionen gettext().
2. Efter at alt tekst der skal oversættes er blevet parset bruges kommandoen xgettext som opretter et PO (Portable Object), hvilket i bund og grund er et rent tekst dokument.
3. Du sendt PO filen til din oversætter, som kan oversætte teksten med en PO-editor.
4. Din oversætter sender PO filen tilbage, nu indeholdende din tekst plus den oversatte tekst.
5. Du compiler PO filen til en MO fil (Machine Object) som kan læses af gettext() funktionen.
6. Du opsætter din locale (sprog opsætning for din applikation) og kan nu nyde din side i alle de oversatte sprog.

Gettext step by step

1). Benyt gettext() funktionen:

Det første punkt er nok det mest bøvlede, om ikke andet så det der vil tage mest tid. Ikke desto mindre er det ganske simpelt, men blot kedeligt. En streng som følgende:

Skal blive til:

Dette skal som sagt gøres for alle strenge du vil have sendt med til din oversætter.

2). Oprettelse af PO filen:

I dette skridt skal du have gang i programmet xgettext, hvilket skal bruges til at løbe alle dine PHP-filer igennem, for at udtrække de strenge du har benyttet gettext()-funktionen på. Alle de fundne strenge vil blive samlet i en PO fil, som du kan sende afsted til oversættelse. En PO fil er i bund og grund blot en tekstfil tilføjet lidt ekstra informationer.

Benytter du Linux er det sandsynligt at du allerede har xgettext installeret, alternativt vil det ikke være svært at få fat i. Du kan evt. installerer gettext-modulet ved følgende kommando (eller benyt din egen packagemanager):

Alternativt findes PO-editoren poedit til både Windows, Mac og Linux. Til Windows kommer denne editor med alle de nødvendige hjælpeprogrammer til at kompleterer oversættelsen. Mens selve oversættelsen ikke er afhængig af poedit, kan programmet være meget anvendeligt alligevel, da det giver en nem og overskuelig måde for både at oversætte, kompilerer og vedligeholde.

Tager vi udgangspunkt i opretelsen af PO filen fra selve editoren poedit, er det nødvendigt at definerer et par indstillinger. Ved opretelse af et nyt “katalog” (som det kaldes på dansk) skal du under “stier” definerer kataloget som udgør roden i din applikation. Dersuden skal du udfylde nogle standardfelter (Projektinformation) som bruges rent informativt i PO filen. Når disse indstillinger er sat, vil du blive bedt om at gemme din PO fil. Første gang du gemmer denne vil poedit automatisk hente de strenge du har valgt skal med til oversættelse – herefter kan du til hver en tid opdaterer din PO fil ved blot at trykke på “Opdaterings katalog”-knappen.

Alternativt skal du have gang i kosollen, hvilket dog heller ikke er svært. For at oprette en PO fil, som samler strenge fra alle PHP-filer i flere kataloger, skal du blot bruge følgende kommando:

Herefter vil du, i det katalog hvod du udfører kommandoen, få oprettet din PO fil.

3 & 4). Send PO filen til din oversætter

Som jeg nævnte tidligere virker det ikke særlig fordelagtigt at skulle oversætte direkte i en tekstfil, og da slet ikke hvis man skal sidde og passe sine strenge ind i et array. PO filer er heller ikke specielt pæne at skulle redigerer direkte i, selvom det kan lade sig gøre – men hvilken fil er det? Din oversætter bør derfor få fat i en PO editor, som f.eks. poedit som er ganske gratis. Herefter er oversættelsen let som en leg – Hvad din oversætter vil se, er hvad du ser på billedet herunder:

Oversætteren oversætter samtlige strenge, og sender den oversatte PO fil tilbage til dig.

5). Compiling af PO til MO

For at compile PO filen til en MO fil, som er den fil PHP bruger for at oversætte strenge der er benyttet gettext()-funktionen på, skal vi have gang i msgfmt programmet. msgfmt komme ligeledes med poedit til Windows, og til Linux ved at installerer hele gettext modulet. Igen er det meget nemmere ved brugen af poedit, og faktisk bliver dette skridt automatisk udført allerede hos din oversætter, men for en god ordens skyld tager vi det lige med her.

Når du har modtaget din PO fil fra oversætteren skal du blot åbne denne i poedit og trykke “gem”! Jeps, det var det, så har du oprettet en MO fil. vil du benytte kommandoprompten, skal du blot udfører følgende:

6). Sprog opsætning i din applikation:

Foruden at skulle finde alle de mange strenge og pakke dem ind i gettext()-funktionen, så var dette sidste skridt faktisk det eneste der gav mig en smule problemer. Problemerne grunder i at dette skridt kan være afhængig af din webserver – så frygt ikke hvis ikke du får det til at virke i første omgang (spørg evt. din udbyder til råds).

Først og fremmest skal du have opbygget en filstruktur, som vist på billedet til højre. Jeg har valgt at ligge alle mine sprog i en overordnet mappe kaldet “languages” – navnet på denne mappe kan du selv bestemme, men navnet skal bruges som et “domæne”, som vist lige om lidt.

I dette eksempel har jeg kun taget to sprog med, skal du have flere sprog i din applikation, skal du oprette en mappe for hver af disse, hver mappe navngives med sprogets locale-code (F.eks. “en_US” for engelsk, “da_DK” for dansk osv.). Inde i hvert af disse mapper opretter du endnu en mappe som altid hedder “LC_MESSAGES”. Som det også er vidst på billedet, skal du placerer MO-filerne i LM_MESSAGES mapperne, jeg har min tilsvarende PO filer liggende i samme mappe, dette er ikke nødvendigt, men blot overskueligt.

Den allersidste del der skal til, er et par linier kode, og så er du faktisk kørende. Tilføj følgende linier i evt. i en fil du du altid kan inkludere:

I eksemplet ovenfor, kan vi skifte sprog vha. en query streng. Personligt har jeg brugt cookies, men dette valg er jo op til dig. En af de rigtig fede ting ved denne metode er, at din applikation altid vil udskrive noget. Bilver $local variablen i ovenstående eksempel ikke sat, eller bliver den sat til noget der ikke giver mening, vil gettext altid udskrive dit originale sprog – i mit tilfælde dansk.

Puhaa – det var en lang smøre, men skulle du af en eller anden grund ikke have fået nok, kan du evt. læse mere om gettext på følgende URLer:

http://dk.php.net/gettext

http://www.gnu.org/software/gettext/

Problemet

Jeg havde en applikation, som virkede fint lige før jeg formaterede computeren, men efter at have geninstalleret PHP og MySQL, kunne jeg ikke få forbindelse til databasen mere. Jeg havde ligeledes installeret MySQL GUI Tools, hvilke jeg brugte til at oprette brugere til databasen. Det skal nævnes at jeg denne gang installerede PHP v. 4.4.4 og MySQL v. 5.0.27, hvorefter jeg fik følgende fejl:

Hvorfor?

Problemet ligger i en ny måde at verificerer passwords på i MySQL 5.0 databasen – her snakker vi passwords til bruger af selve MySQL databasen, ikke af et CMS eller anden web applikation. Før formateringen brugte jeg MySQL 4.x.x samt PHP v. 4, hvilke arbejder meget  godt sammen. Men PHP 4 benytter “en gammel MySQL klient”, som ikke umiddelbart kan arbejde sammen med MySQL 5.0 pga. den nye måde at verificerer passwords på.

Løsningen

Løsningen er heldigvis til at komme over – du skal blot opdaterer dine passwords til dine MySQL brugere!

Når du har installeret MySQL databasen og oprettet dine brugere, kan du logge ind gennem MySQL kommandoprompten, og opdaterere dine brugere. Du finder kommandoprompten ved at kører mysql.exe fra “bin” kateloget, hvor du har installeret serveren.

Start mysql.exe med root brugeren:

Benyt databasen med brugere af serveren (denne er standard):

Opdater dine brugeres passwords til at være kompatible med ældre klienter:

Du kan læse mere om problemet på MySQL developer zone.