Zend Framework

August 10th, 2009

Bij deze gooi ik het roer om en ga ik verder met Zend Framework. Hoewel ik het niet met de core van het mvc systeem eens ben en i het zelf anders zou bouwen, werkt het wel lekker snel. Zeker nu ze een commandline tool hebben.

Je hoort binnenkort van me!

Void functies in classes

July 6th, 2009

Void functies zijn de functies die niets returnen. Over het algemeen gaat het om setters en functies die de state van de classe veranderen.

Een voorbeeld

class Car
{
    protected $speed = 50;
    // Hieronder zie je een void functie (= geen return)
    public function setSpeed($speed)
    {
        $this->speed = $speed;
    }
    /* Meer code */
}

De code om dit aan te roepen ziet er dan bijvoorbeeld zo uit:

$c = new Car();
$c->setColor(Color::RED);
$c->setSpeed(0);
$c->openDoor(1);
$c->setSpeed(100);

Wanneer echter je variable naam ($c) een beetje groot wordt ($eenOfAnderMerkAutoNaam) is dit een typewerk waar je u tegen zegt. Daarnaast wordt het er ook een stuk minder leesbaar op.
Om dit tegen te gaan laat ik alle void functies $this returnen. Zo krijg je de volgende code:

class Car
{
    protected $speed = 50;
    // Hieronder zie je een void functie (= geen return)
    public function setSpeed($speed)
    {
        $this->speed = $speed;

        return $this;
    }
    /* Meer code */
}
$c = new Car();
$c->setColor(Color::RED)
  ->setSpeed(0)
  ->openDoor(1)
  ->setSpeed(100);

En kijk eens aan, je hoeft de variable maar 1 keer aan te roepen!

Check je!

Onzichtbare setters en getters part 2

June 30th, 2009

Hallo trouwe lezers.. Het leven is op ‘t moment te druk voor woorden, kom niet eens toe aan world of warcraft spelen. Duidelijk tijd tekort dus. Maar dan nu toch een artikel.

Vorige keer heb ik een artikel geschreven over Onzichtbare getters en setters, opzich een leuk concept, als je het van de andere kant bekijkt, zou je alleen altijd getters en setters moeten hebben voor het geval je valdatie toe wilt voegen. Natuurlijk kan je dat allemaal doen met een goede IDE. Aangezien ik op werk met vim zit te klooien, heb ik een leuk alternatief verzonnen.

/** Vergeet niet dat deze functie binnen een class thuishoort **/
public function __call($function, $args)
{
    // Set method, match en sla de variable-naam op in $matches
    if ( preg_match('/^set([A-Z])([0-9a-zA-Z]*)$/', $function, $matches) )
    {
        // Maak de eerste letter lowercase
        $key = strtolower($matches[1]).$matches[2];
        // Zet de variable
        $this->$key = array_shift($args);

        // Mijn gewoonte met void functies
        return $this;
    }

    // Set method, match en sla de variable-naam op in $matches
    if ( preg_match('/^get([A-Z])([0-9a-zA-Z]*)$/', $function, $matches) )
    {
        // Maak de eerste letter lowercase
        $key = strtolower($matches[1]).$matches[2];

        // Als de variable niet bestaat, return dan null
        if ( !isset($this->$key) )
        {
            return null;
        }

        // Return de waarde
        return $this->$key;
    }

    throw new Exception('Calling undefined function.');
} 

Werkt prima zo, alle variablen die gewoon met een letter beginnen hebben op deze manier een setter en een getter (maak ze wel protected of private). Wil je echt dat een bepaalde variable niet aangesproken kan worden buiten de classe, laat hem dan met een underscore “_” beginnen.

En zoals altijd, comments zijn welkom, scheld me alsjeblieft uit dat ik niet actief op mijn blog ben geweest…

Cheers!

Voorbeeld

Ga er vanuit dat de classe B de bovenstaande functie bevat.

class A extends B
{
    protected $var1;
    protected $test;
    protected $testVar2 = 'hallo';
}

$a = new A();
// Setters
$a->setVar1('test')
  ->setTest('Sup?');

// Getter
echo $a->getTestVar2();

// Nog een Setter
$a->setTestVar2('iets anders');

// Het resultaat
print_r($a);

Onzichtbare getters en setters

June 18th, 2009

In een poging de grenzen van php te verkennen, heb ik een methode gevonden om setters en getters “onzichtbaar” te implementeren. Het lijkt in je code net of je de attributen direct aanspreekt, maar in werkelijkheid, kun je er daadwerkelijk validatie aan hangen, iets waar je normaal gesproken een setter of een getter nodig hebt.

Voorbeeld

class Example
{
    // Attribuut
    public $attribute;
    // Setter
    public function setAttribute($value)
    {
        // Validation
        $this->attribute = $value;
    }
}

$example = new Example();

// Direct
$example->attribute = 1;

// Via setter
$example->setAttribute(1);

Waarom?

Goeie vraag, geen idee, zoals ik al zei, ik was de grenzen aan het verkennen, erg nuttig is het dus niet, maar wel interessant :) .

Doel?

Het doel is dus dat je achteraf je validatie / filters op een bepaald attribuut kan toevoegen, zonder dat je daar functies voor aan hoeft te roepen, natuurlijk moet je de setter of de getter wel aanmaken. Om dit te realiseren maak ik gebruik van de magische functies __set en __get, die alleen aangesproken worden wanneer php het betreffende attribuut kan bereiken omdat deze bijvoorbeeld private, protected is of zelfs niet bestaat.

Code!

Hieronder zie je hoe ik de classe geschreven heb.

class AutoGetSet
{
    public function __set($key, $value)
    {
        // De naam van de set methode
        $method = 'set'.ucfirst($key);
        try
        {
            // Roep de functie aan
            call_user_func(
                array($this, $method),
                $value
            );
        }
        catch ( InvalidFunctionException $ex )
        {
            throw new Exception('No setter defined for '.$key.'.');
        }
    }

    public function __get($key)
    {
        // De naam van de set
        $method = 'get'.ucfirst($key);
        try
        {
            // Roep de functie aan en return het resultaat
            return call_user_func(
                array($this, $method)
            );
        }
        catch ( InvalidFunctionException $ex )
        {
            throw new Exception('No setter defined for '.$key.'.');
        }
    }

    // Als er een functie aangeroepen wordt die niet bestaat, gooi dan een Exception.
    public function __call($function, $args)
    {
        throw new InvalidFunctionException('Function '.$function.' does not exist in '.__CLASS__.'.');
    }
}

Om te zorgen dat de set en getters aangesproken worden, moet je het attribuut protected maken.

Conclusie

Het is me dus uiteindelijk gelukt om de setters en getters “onzichtbaar” te maken. Hoewel ik het zelf niet gebruik vond ik het toch wel een geslaagde test.

Nog wat voorbeelden
Zonder setter en getter zal de code er zo uitzien en werkt hij gewoon zoals je van php gewend bent.

class Example
{
    public $attribute;
}

$example = new Example();
$example->attribute = 'Test';
echo $example->attribute;

Vervolgens kun je de setter en de getter toevoegen. Let op het attribuut is protected geworden.

class Example extends AutoGetSet
{
    // Let op protected!
    protected $attribute;

    // Setter
    public function setAttribute($value)
    {
        echo 'SET attribute to '.$value;
        $this->attribute = $value;
    }

    // Getter
    public function getAttribute()
    {
        echo 'GET attribute';
        return $this->attribute;
    }
}

$example = new Example();
$example->attribute = 'Test';
echo $example->attribute;

Als je nu de output bekijkt zul je zien dat de setter en de getter automatisch aangeroepen worden.

Ik ben benieuwd wat vindt jij ervan? Nog leuke ideeen voor situaties waarbij dit bruikbaar is?

Structuur

June 17th, 2009

Het eerste probleem waar ik tegenop loop met mijn framework is de structuur.

Regels

  • De superglobals (GET, POST, SERVER, SESSION), mogen niet direct vanuit de model/controller of view aangesproken worden;
  • De controller mag nooit een “view element” zoals bijvoorbeeld een formulier of een paginator aanmaken;
  • De controller moet maar 1 keer gemaakt hoeven worden, dat betekend dat 1 controller verschillende types views aan kan (hiermee is het mogelijk om een controller zowel JSON, XML als XHTML uitspuigt zonder dat je daarvoor iets in je controller moet veranderen).

Wat wil ik ondersteunen

  • Model die voor alle applicaties beschikbaar is;
  • Model voor de applicatie zelf;
  • Controllers;
  • Views;
  • Renders.

Wat vindt jij? Mis ik iets?

De mappen

Met de bovenstaande informatie, ben ik tot de conclusie gekomen dat er 3 grote elementen zijn, namelijk “public”, “application” en “general libraries”.

Public
Het gedeelte wat voor de gebruiker zichtbaar is, ook wel public-www, httpdocs, htdocs en www genoemd.

Application
Dingen die voor de applicatie specifiek zijn. Denk aan controllers, views, maar ook aan specifieke models.

General Libraries
De general libraries bestaan onder andere uit de core van het framework. Dit zijn de classes die voor elke web-applicatie bruikbaar kunnen zijn.

[root]
 |- application
 |   |- controller
 |   |   \- {CONTROLLER CLASSES}
 |   |
 |   |- view
 |   |   \- {VIEW CLASSES}
 |   |
 |   |- template
 |   |   |- html
 |   |   \- {OUTPUT FORMATS}
 |   |
 |   |- library
 |   |   \- {APPLICATION MODELS}
 |   |
 |   \- Boot.php
 |
 |- library
 |   \- {MODELS}
 |
 \- httpdocs
     \- index.php

View Classes?

Ja ik kies er in mijn framework voor om voor elke Action een aparte View classe te maken. In deze classe kunnen functies gemaakt worden die bijvoorbeeld voor de template nodig zijn.

Boot.php?

Dit is waar ik het meest mee in mijn maag zit. Ergens moet de applicatie opstarten, maar wat is de verantwoordelijkheid van deze boot? Sowieso wil ik dat hier het grootste deel van de superglobals afgehandeld wordt, zodat ik die in ieder geval niet direct vanuit de rest van mijn framework aan hoef te roepen.

Frontcontroller?

Waar en hoe implementeer ik de frontcontroller? Routers liggen mij niet zo, aangezien het onnodig complex wordt, soms heb je namelijk 20+ routers nodig voor iets wat je normaal kan programmeren in 3 regels. Misschien een extra file FrontController.php, waarin de frontcontroller class staat, die op basis van een Request Object bepaald welke controller/action er aangesproken moet worden? Spreekt Boot.php de frontcontroller aan?

Antwoorden

Voordat ik mijn oplossingen met jullie deel, hoor ik graag eerst wat jou mening is. Wat vindt jij van mijn oplossingen?

Getting started

June 16th, 2009

Hallo allemaal, welkom op mijn blog.

Wie ben ik?

Voor de mensen die mij nog niet kennen, mijn naam is Reen Lokum. Ik studeer momenteel informatica op de Hogeschool Rotterdam. Puzzelen is het leukste wat er is en dan heb ik het niet over de legpuzzel. Ik denk graag na over programmeer-concepten, zodat ik problemen op de beste manier kan oplossen.

Wat is het plan?

Een aantal weken geleden heb ik besloten om mijn eigen framework te bouwen in php. Je zou zeggen, daar zijn er toch genoeg van? Dat klopt, ik heb dan ook een tijdje met het Zend Framework gewerkt. Hoewel ik nog nooit van me leven zo snel een applicatie in elkaar gezet had, bleef het aan me vreten dat sommige dingen in mijn ogen gewoon niet op de beste manier opgelost waren. Daarom heb ik dus besloten mijn eigen framework te bouwen.

Doel

Het primaire doel van het framework is het toevoegen van MVC functionaliteit binnen php. Daarna zal het framework uitgebouwd worden met onder andere een ORM.

Kun je programmeren? Houd je ook van discussieren? Check dit blog dan regelmatig en wie weet leren we wat van elkaar!