Creating The Web…

Fra xkcd.com

Striben taler vidst for sig selv – sådan et virus er der vidst ikke mange der vil have meget imod?! I know I wouldn´t .

Jeg har tidligere haft skrevet om Hijax og for nyligt om Hijax i praksis, emner hvor prædiken går på hvor vigtigt det kan være ikke at udelukke “dem som ikke kan afvikle Javascript“… men der findes dog også de modsatte eksempler – hvor “de” bare skal blive væk!

Sidste gang jeg skiftede design m.m. her på bloggen tog jeg hijax-princippet til mig, hvilket f.eks. har gjort, at man nu kan søge “live” med Javascript og “almindeligt” uden Javascript. Jeg ville have brugt samme teknik til kommentering, men kom aldrig længere end til at man kunne kommentere via et “normalt” POST.

Blog spam helvede 

At have en ganske almindelig standard HTML-formular er, nu til dags, næsten det samme som at sige “Jeg vil gerne være offer for al jeres lorte-spam – bare fyr løs“. Det var i hvert hvad resultatet for mig…

More

Tilbage i april fandt jeg frem til hijax princippet, og i den forbindelse lovede jeg at der ville komme en mere praktisk gennemgang – det vil jeg så forsøge mig med nu.

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.

More

Wow, jeg kan ikke helt finde ud af om jeg skal elske eller hade Googles Webmaster Tools pt.?

Jeg troede faktisk at disse links for længst var “forsvundet” fra nettets overflade – but noooo!

Nettet er en elefant!

Det er vel også naivt at tro at links, som knap har eksisteret i et år skulle være væk! Godt nok har jeg tidligere haft .htaccess regler som skulle forhindre sådanne tilfælde. De har helt sikkert også virket hvis en besøgende/robot er kommet forbi, men det betyder jo ikke at folks bookmarks, linkbiblioteker mm. har opdateret sine links?!

More

Jeg sidder i skrivende stund og forsøger at forbedre mine evner med OOP i PHP5. Og har man første sagt OOP, kommer man vel ikke uden om at sige constructor og overloading af samme … eller hvad?!

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?