[PHP]classes voor mij

[Dr_Frickin_Evil]

Ik heb een (voor mij doen) behoorlijk uitgebreid systeem geschreven waaromheen ik mn site heb opgebouwd. Hier kan ik, als admin, nieuwsberichten op plaatsen, waarop mensen die ingelogd zijn, kunnen reageren. Bovendien heb ik een onderdeel waar ik foto's kan toevoegen, kunnen links worden toegevoegd door mij maar ook door de (ingelogde) bezoekers, en is er een gastenboek waar ook reacties in geplaatst kunnen worden. Ruwweg bestaat de site dus uit:
- nieuwsberichten
- reacties
- gebruikers
- foto's
- links

Dit alles brengt een aardige lap tekst met zich mee. Ik heb het momenteel allemaal zo netjes mogelijk in functies proberen te verpakken, maar ik doe nog steeds een hoop 'dubbel' en het overzicht is ook een beetje zoek. Na het een en het ander over classes gelezen te hebben, leek me dat de goeie manier om dit op te schonen. Maar hoe ga ik in zo'n geval aan de gang? Waar kan ik het allemaal precies toepassen, en hoe moet ik beginnen?

Ik moet als (mede-)beheerder van de site onder andere de volgende acties uit kunnen voeren:
- nieuwsberichten plaatsen, updaten en verwijderen
- foto's plaatsen, eventueel invoegen bij de nieuwsberichten en verwijderen
- gebruikers moeten zich kunnen registeren, het account moet geactiveerd worden, en ik moet ze kunnen verwijderen (waarmee dus ook alle door deze gebruiker ingebrachte data verwijderd moet worden).
- links moeten worden toegevoegd, verwijderd en geactiveerd (gebruikers kunnen zelf ook links plaatsen, maar die moeten door mij worden goedgekeurd voordat ze getoond worden).
- dit alles wordt opgeslagen in een MySQL-database

Dit alles heb ik dus allemaal al werkend, dit is even als voorbeeld van de functionaliteit die ik wil implementeren mbv classes. Hoe kan ik dit het beste aanpakken?

[-Odysseus-]

Ik zou eerst eens gaan kijken welke entiteiten je in je systeem hebt zitten. Daarmee bedoel ik bijvoorbeeld: een gebruiker, een nieuwsbericht, een reactie, een foto, etc.

Daar moet je de eigenschappen/attributen van gaan bepalen.: een nieuwsbericht heeft een titel, een tekst, etc.

Zet dit eens rustig en netjes op papier.
Probeer de relaties tussen deze entiteiten ook op papier te zetten: een reactie heeft altijd een gebruiker; een nieuwsbericht heeft altijd reacties kan reacties hebben, enz.

Ik zou hier mee beginnen.

[ Voor 20% gewijzigd door -Odysseus- op 12-07-2004 20:47 ]

[Verwijderd]

probeer de 'herhalende' elementen te inventariseren, welke code gebruik je in welke files dubbel, schrijf deze uit en ga eens kijken wat je allemaal zou kunnen groeperen.

[Verwijderd]

een login-class, Database Abstractie Laag, class voor session-management en zo kan ik nog wel even doorgaan. Je moet als het ware een class zo globaal mogelijk zien, zodat je de code kan hergebruiken voor nieuwe projecten.
Niet verplicht; je kan net zo goed een class schrijven voor het afhandelen van de nieuwsberichten, maar algemene classes zijn het meest handig.

[creative8500]

PHP:

abstract class Entry
{
    public $title;
    public $reactions;
    // Etcetera.
    
    protected function __construct ()
    {
         $this -> title = (string) null;
         $this -> reactions = (array) null;
         // By the way: uit een mijner benchmarks blijkt dat dit sneller is:
         #$this -> reactions = array ();
    }
}

abstract class User
{
    public $username;
    public $password; // Gedecodeerd uiteraard, in een implementatie
}

[Dr_Frickin_Evil]

Verwijderd schreef op 12 juli 2004 @ 21:26:
een login-class, Database Abstractie Laag, class voor session-management en zo kan ik nog wel even doorgaan. Je moet als het ware een class zo globaal mogelijk zien, zodat je de code kan hergebruiken voor nieuwe projecten.
Niet verplicht; je kan net zo goed een class schrijven voor het afhandelen van de nieuwsberichten, maar algemene classes zijn het meest handig.

Ja, maar als ik het op die manier zou benaderen, dan zou ik net zo'n rommel krijgen als ik nu heb lijkt me, of niet? Zou je misschien een voorbeeld kunnen geven van wat je precies bedoelt?

creative8500 schreef op 12 juli 2004 @ 22:34:

PHP:

abstract class Entry
{
    public $title;
    public $reactions;
    // Etcetera.
    
    protected function __construct ()
    {
         $this -> title = (string) null;
         $this -> reactions = (array) null;
         // By the way: uit een mijner benchmarks blijkt dat dit sneller is:
         #$this -> reactions = array ();
    }
}

abstract class User
{
    public $username;
    public $password; // Gedecodeerd uiteraard, in een implementatie
}

Is dit PHP5? Het komt me niet echt bekend voor van wat ik gelezen heb.

[ Voor 35% gewijzigd door Dr_Frickin_Evil op 13-07-2004 01:01 ]

[alienfruit]

Ja, bij mijn weten ondersteund versie 4.0 geen abstracte classes, en de constructor __constructor functie zit standaard niet in PHP4.0. Dus ik denk dat we er wel vanuit kunnen gaan dat iemand hier op de toekomst is voorbereid en versie 5.0 gebruikt

Zelf gebruik ik versie 5.0 nog niet omdat het voorlopig toch nog niet beschikbaar is bij de hosting providers, dus waarom zou ik er al mee werken. De eerste boeken voor PHP5 verschijnen al bijv. bij A!Press en Sams Publishing.

[ Voor 32% gewijzigd door alienfruit op 13-07-2004 01:26 ]

[Dr_Frickin_Evil]

Misschien is het voor de overzichtelijkheid beter dat ik me even beperk tot users en nieuwsberichten (articles). Ik zal even een voorbeeldje geven van wat ik in gedachten had:

PHP:

class article {
    var $id;
    var $userid;
    var $date;
    var $title;
    var $summary;
    var $message;

    function article() {
//constructor functie
        }

    function delete() {
        
        }

    function register() {

        }

    function update () {
        
        }

    }

class user {
    var $id;
    var $name;
    var $password;
    var $email;
    var $city;
    var $homepage;
    var $date;
    var $activation_id;

    function user() {
//constructor functie
        }

    function delete() {
        
        }

    function register() {

        }

    function update () {
        
        }
    }

Het leek me handig om de classes in dat soort functies op te delen, waarin ik dan steeds weer een mysql-query maak die door een evt mysql-class wordt uitgevoerd. Zit ik zo een beetje op de goeie weg?

[creative8500]

alienfruit schreef op 13 juli 2004 @ 01:25:
Zelf gebruik ik versie 5.0 nog niet omdat het voorlopig toch nog niet beschikbaar is bij de hosting providers, dus waarom zou ik er al mee werken. De eerste boeken voor PHP5 verschijnen al bijv. bij A!Press en Sams Publishing.

Omdat ik zelf hoster ben gebruik ik het wel.

Maar over die boeken: Advanced PHP Programming by George Schlossnagle.

[-Odysseus-]

Dr_Frickin_Evil schreef op 13 juli 2004 @ 09:53:

PHP:

class article {
    var $id;
    var $userid;    // Kan beter class user worden
    var $date;
    var $title;
    var $summary;
    var $message;


    }

class user {
    var $id;
    var $name;
    var $password;  // Security issue
    var $email;
    var $city;
    var $homepage;
    var $date;
    var $activation_id;

Ik wil eerst even kort reageren op het attribuut $userid van de class article.
Het is logischer als je daar de class User van maakt ipv. enkel het userid. Dan kan je namelijk de class article aan de class user laten vragen wat zijn naam is.
Bijvoorbeeld:

PHP:

$ARTICLE->USER->name

Daarnaast heb je in de class User $password als attribuut. Dit is natuurlijk niet slim. Je kan deze beter in de database laten zitten, dan weet je iig. zeker dat dat niet zomaar kan worden opgevraagd.

Dit is even wat me zo snel opvalt hoor.

[ Voor 22% gewijzigd door -Odysseus- op 13-07-2004 10:07 ]

[Dr_Frickin_Evil]

-Odysseus- schreef op 13 juli 2004 @ 10:03:
[...]

Ik wil eerst even kort reageren op het attribuut $userid van de class article.
Het is logischer als je daar de class User van maakt ipv. enkel het userid. Dan kan je namelijk de class article aan de class user laten vragen wat zijn naam is.
Bijvoorbeeld:

PHP:

$ARTICLE->USER->name

Moet ik dan een pointer naar de class user als attribute gebruiken? &$user ofzo?

Daarnaast heb je in de class User $password als attribuut. Dit is natuurlijk niet slim. Je kan deze beter in de database laten zitten, dan weet je iig. zeker dat dat niet zomaar kan worden opgevraagd.

Dit is even wat me zo snel opvalt hoor.

Maar hoe zou dat dan opgevraagd kunnen worden? Bovendien staat het natuurlijk gecodeerd in de database. Maar wat zou jij dan voorstellen? Een aparte functie getPassword() ofzo, waarmee het wachtwoord van de user opgehaald wordt?

[-Odysseus-]

OO-technisch is het btw eigenlijk beter om het zo te doen:

PHP:

$article->GetUsersName();
// en article roept dan op zijn beurt weer
$user->GetName();

Dr_Frickin_Evil schreef op 13 juli 2004 @ 10:26:
[...]

Moet ik dan een pointer naar de class user als attribute gebruiken? &$user ofzo?

En je kan het beste dmv. een reference die class user in de class article zetten.

PHP:

$name= & new User();

Maar hoe zou dat dan opgevraagd kunnen worden? Bovendien staat het natuurlijk gecodeerd in de database. Maar wat zou jij dan voorstellen? Een aparte functie getPassword() ofzo, waarmee het wachtwoord van de user opgehaald wordt?

Ik zou eerder checkPassword() gebruiken en als je het nodig hebt: changePassword() maar nooit het wachtwoord direct aanroepbaar maken.

[ Voor 28% gewijzigd door -Odysseus- op 13-07-2004 10:36 ]

[Verwijderd]

Dr_Frickin_Evil schreef op 13 juli 2004 @ 01:00:
[...]

Ja, maar als ik het op die manier zou benaderen, dan zou ik net zo'n rommel krijgen als ik nu heb lijkt me, of niet? Zou je misschien een voorbeeld kunnen geven van wat je precies bedoelt?

Hij bedoelt dat je dus iets als een framework opzet.

Zelf ben ik ook bezig met een framework het voorbeeld: http://framework.rbdata.nl/ (hij is alleen nog niet af, en sommige dingen moeten veel beter)
Check daar ook even de documentatie, daarin staan alle functies de ik gebruik.

Met een framework kan je makkelijk alles wat je wilt beheren, users etc.

[ Voor 10% gewijzigd door Verwijderd op 13-07-2004 11:05 ]

[creative8500]

Een iets uitgebreider voorbeeld:

PHP:

<?php

/**
 * @author         Dr_Frickin_Evil
 * @package        Website van Dr_Frickin_Evil
 * @subpackage     Weblog
 */
abstract class Article
{
    /**
     * Title of the article
     * 
     * @access     public
     * @var        string
     */
    public $title;
    
    /**
     * Summary of the article (usually the first paragraph)
     * 
     * @access     public
     * @var        string
     */
    public $summary;
    
    /**
     * The article itself; the 'body'
     * 
     * @access     public
     * @var        string
     */
    public $body;
    
    /**
     * Reactions on the article
     * 
     * @access     public
     * @var        array An array of Reaction objects
     */
    public $reactions;
    
    /**
      * Date on which the article was published
      * 
      * @access    public
      * @var       int UNIX-timestamp of the date on which the article was published
      */
    public $publishingDate;
    
    /**
      * Date on which the article was updated last
      * 
      * @access    public
      * @var       int UNIX-timestamp of the date on which the article was updated last
      */
    public $lastUpdateDate;
    
    /**
     * User that published the article
     * 
     * @access     public
     * @var        User
     */
    public $User;
    
    protected function __construct ()
    {
        $this -> title     = (string) null;
        $this -> title     = (string) null;
        $this -> body      = (string) null;
        
        $this -> reactions = (array) null;
        // By the way: uit een mijner benchmarks blijkt dat dit sneller is:
        #$this -> reactions = array ();
        
        $this -> publishingDate = (int) null;
        $this -> lastUpdateDate = (int) null;
        
        $this -> userId = (int) null;
    }
}

// Nog een extra voorbeeldje:
class DatabaseArticle extends Article
{
    /**
     * User-ID of the user that published the article
     * 
     * @access     protected
     * @var        int
     */
    protected $userId;
    
    public function __construct ($userId)
    {
        parent::__construct ();
        
        unset ($this -> User); // Opdat we deze 'on-access' kunnen laden via __get
        
        if (isset ($userId))
            $this -> load ($userId);
    }
    public function __get ($keyword)
    {
        switch ($keyword)
        {
            case 'User':
                if (isset ($this -> userId))
                    $this -> User = UserFactoryWrapper::getUserById ($this -> userId);
                return $this -> User;
        }
    }
    /**
     * Saves the article in a database
     * 
     * @access     public
     */
    public function save ()
    {
        /*
         * Dus niet een aparte interface voor een nieuwe artikel zoals
         * Article::save() en voor een bestaand artikel, Article::update()!
         */
    }
}

?>

_{En "ja", ik zie dat je PHP4 gebruikt.}

[ Voor 21% gewijzigd door creative8500 op 13-07-2004 13:23 ]

[-Odysseus-]

creative8500 schreef op 13 juli 2004 @ 11:58:

PHP:

<?php
abstract class Article
{
    
    /**
     * User that published the article
     * 
     * @access     public
     * @var        User
     */
    public $User;
    
    /**
     * User-ID of the user that published the article
     * 
     * @access     protected
     * @var        int
     */
    protected $userId;
}

Nog steeds $userid als attribuut terwijl je de class User al gebruikt... Je moet je informatie niet dubbel opslaan.

[ Voor 14% gewijzigd door -Odysseus- op 13-07-2004 12:47 ]

[creative8500]

-Odysseus-: Nog steeds $userid als attribuut terwijl je de class User al gebruikt... Je moet je informatie niet dubbel opslaan.

Je hebt gelijk, het moest inderdaad niet Article::$userId zijn, maar DatabaseArticle::$userId. Dit i.v.m. de manier waarop ik het User-object pas op aanvraag laat instantiëeren.

Bovendien ben ik het grondig oneens met de stelling dat je de properties d.m.v. een methode moet aanvragen. Mijn simpele argumentatie: daar zijn properties nu juist voor uitgevonden. Methoden zijn voor bewerkingen.

[ Voor 24% gewijzigd door creative8500 op 13-07-2004 13:42 ]

[-Odysseus-]

creative8500 schreef op 13 juli 2004 @ 13:26:
[...]

Je hebt gelijk, het moest inderdaad niet Article::$userId zijn, maar DatabaseArticle::$userId. Dit i.v.m. de manier waarop ik het User-object pas op aanvraag laat instantiëeren.

Waarom kies je ervoor het op die manier te doen? Je kan toch net zo goed de hele class User er inzetten. Dan is die daar tenminste altijd.

$userid is een eigenschap van de class User en niet van een (Database)Article. Je moet deze onder de juiste noemer opslaan om het zo maar te zeggen.

[creative8500]

-Odysseus- schreef op 13 juli 2004 @ 13:30:
[...]


Waarom kies je ervoor het op die manier te doen? Je kan toch net zo goed de hele class User er inzetten. Dan is die daar tenminste altijd.

$userid is een eigenschap van de class User en niet van een (Database)Article. Je moet deze onder de juiste noemer opslaan om het zo maar te zeggen.

Het is dan ook slechts voor intern gebruik! Niemand die van de protected $userId afweet behalve developers van de implementatie en developers van inheriting classes.

[-Odysseus-]

creative8500 schreef op 13 juli 2004 @ 13:44:
[...]

Het is dan ook slechts voor intern gebruik! Niemand die van de protected $userId afweet behalve developers van de implementatie en developers van inheriting classes.

ja kijk het is jou script natuurlijk maar het is niet netjes . Het zou in principe niet hoeven.

[creative8500]

-Odysseus- schreef op 13 juli 2004 @ 13:46:
[...]


ja kijk het is jou script natuurlijk maar het is niet netjes . Het zou in principe niet hoeven.

Dan heb ik gráág dat je me zegt hoe jij het zou doen!

[Dr_Frickin_Evil]

creative8500 schreef op 13 juli 2004 @ 13:26:
Bovendien ben ik het grondig oneens met de stelling dat je de properties d.m.v. een methode moet aanvragen. Mijn simpele argumentatie: daar zijn properties nu juist voor uitgevonden. Methoden zijn voor bewerkingen.

Bedoel je daarmee de functies setVar en getVar die je vaak gebruikt ziet in classes? Ik snap namelijk niet goed wat daar de bedoeling altijd van is. Je kan ze toch direct opvragen met $class->var?

[-Odysseus-]

creative8500 schreef op 13 juli 2004 @ 13:48:
[...]

Dan heb ik gráág dat je me zegt hoe jij het zou doen!

Maak eens een (UML)-overzicht waarin de classes staan, samen met de attributen en eventueel een eerste indicatie van de functies. Geef daar de verschillende relaties onderling (tussen de classes) in aan door ze te verbinden.

Dat geeft iig. een overzicht dat wat duidelijker is, voordat je je in de code stort.

[-Odysseus-]

creative8500 schreef op 13 juli 2004 @ 13:26:
[...]
Bovendien ben ik het grondig oneens met de stelling dat je de properties d.m.v. een methode moet aanvragen. Mijn simpele argumentatie: daar zijn properties nu juist voor uitgevonden. Methoden zijn voor bewerkingen.

Het is een OO-gedachte. Een attribuut/eigenschap/property is een geheime eigenschap. Objecten weten niets van elkaar en communiceren dmv. methoden. Op die manier kan een object ook zelf bepalen wat hij vrijgeeft. Maar nu betrap ik mezelf er ook nog wel eens op dat ik me hier soms niet aan hou.

Tis jammer dat ik het nu niet uitgebreid kan uitleggen

[ Voor 48% gewijzigd door -Odysseus- op 13-07-2004 13:59 ]

[Dr_Frickin_Evil]

-Odysseus- schreef op 13 juli 2004 @ 13:56:
[...]


Het is een OO-gedachte. Een attribuut/eigenschap/property is een geheime eigenschap. Objecten weten niets van elkaar en communiceren dmv. methoden. Op die manier kan een object ook zelf bepalen wat hij vrijgeeft. Maar nu betrap ik mezelf er ook nog wel eens op dat ik me hier soms niet aan hou.

Tis jammer dat ik het nu niet uitgebreid kan uitleggen

Dat is misschien in andere talen zo, maar in PHP kan dat toch prima? Waarom daar geen gebruik van maken?

[Ritch]

-Odysseus- schreef op 13 juli 2004 @ 10:03:
Daarnaast heb je in de class User $password als attribuut. Dit is natuurlijk niet slim. Je kan deze beter in de database laten zitten, dan weet je iig. zeker dat dat niet zomaar kan worden opgevraagd.

Hoezo is dat niet slim? Je zult dat wachtwoord toch ergens in een variabele moeten hebben ooit? Waarom niet netjes in de class waar die bij hoort? Grote kans dat je die var nooit vult als je de user ophaalt uit de database, maar bij het aanmaken van een nieuwe moet je die wel hebben. Daarnaast is een wachtwoord in een variable absoluut geen security risk, tenzij je code hebt die door andere systemen rechtstreeks aangesproken kan worden, maar dat lijkt me niet vaak het geval.

-Odysseus- schreef op 13 juli 2004 @ 13:56:
[...]

Het is een OO-gedachte. Een attribuut/eigenschap/property is een geheime eigenschap. Objecten weten niets van elkaar en communiceren dmv. methoden. Op die manier kan een object ook zelf bepalen wat hij vrijgeeft. Maar nu betrap ik mezelf er ook nog wel eens op dat ik me hier soms niet aan hou.

Tis jammer dat ik het nu niet uitgebreid kan uitleggen

En waarom zou een object niet een ander object "vrij kunnen geven"? In een normale taal zou ik gewoon dit doen:

PHP:

echo $article->getUser()->getName();

Maarja, dat kan php(4) niet, dus moet je iets anders verzinnen. Class variabelen rechtstreeks aanspreken is niet echt netjes, maar

PHP:

$user =& $article->getUser();
echo $user->getName();

is ook veels te omslachtig imho...

[alienfruit]

Inderdaad ik heb net het boek aan een vriend meegegeven om te lezen tijdens zijn vakantie, hij wilde PHP leren Het boek zag er wel goed uti, ook bruikbaar voor mensen die PHP4 gebruiken.

Beginning PHP 5 and MySQL: From Novice to Professional
Vraag me nu niet of het een goed boek is, want die ligt al een tijdje ongeopend op mijn bureau

[-Odysseus-]

Ritch schreef op 13 juli 2004 @ 14:37:
[...]


Hoezo is dat niet slim? Je zult dat wachtwoord toch ergens in een variabele moeten hebben ooit? Waarom niet netjes in de class waar die bij hoort? Grote kans dat je die var nooit vult als je de user ophaalt uit de database, maar bij het aanmaken van een nieuwe moet je die wel hebben. Daarnaast is een wachtwoord in een variable absoluut geen security risk, tenzij je code hebt die door andere systemen rechtstreeks aangesproken kan worden, maar dat lijkt me niet vaak het geval.

Een wachtwoord zou je eigenlijk niet aanspreekbaar moeten maken ook al ben je nog zo zeker over de security van de rest van je systeem. Daarnaast is bij het aanmaken van een nieuwe account, het helemaal niet nodig om voor het wachtwoord een attribuut te hebben. Dit wachtwoord zal toch niet worden teruggegeven aan de gebruiker en is enkel nodig in bijvoorbeeld de query naar de database.* Dit vergroot alleen maar de security van je systeem.

*edit: er zou zich op 1 moment een situatie kunnen voordoen dat de gebruiker z'n wachtwoord terugkrijgt: wanneer een wachtwoord gegenereerd wordt, maar dan nog is het niet nodig om deze in een attribuut op te slaan.

En waarom zou een object niet een ander object "vrij kunnen geven"? In een normale taal zou ik gewoon dit doen:

PHP:

echo $article->getUser()->getName();

Maarja, dat kan php(4) niet, dus moet je iets anders verzinnen. Class variabelen rechtstreeks aanspreken is niet echt netjes, maar

PHP:

$user =& $article->getUser();
echo $user->getName();

is ook veels te omslachtig imho...

Ik vind het zelf ook makkelijker om het zo te doen maar perfect OO is het niet. Er wordt namelijk vanuit gegaan dat objecten niets van elkaar afweten. Maar je kan er natuurlijk ook minder strict mee omgaan. Dat is zeker geen ramp.

[ Voor 10% gewijzigd door -Odysseus- op 13-07-2004 15:34 ]

[creative8500]

-Odysseus- schreef op 13 juli 2004 @ 13:56:
Het is een OO-gedachte.

Ken je ook de naam van dit patroon? Dan hoef jij het niet uit te leggen, maar dan zoek ik zelf wel aanvullende referenties.

[-Odysseus-]

creative8500 schreef op 13 juli 2004 @ 16:03:
[...]

Ken je ook de naam van dit patroon? Dan hoef jij het niet uit te leggen, maar dan zoek ik zelf wel aanvullende referenties.

Zoek eens op OO principe / encapsulatie / etc.


werkdag zit er weer bijna op
http://www.serc.nl/people/florijn/papers/ooarchasi.html

[...]
De moderne kijk op objecten is sterk beïnvloed door de eerdere ontwikkelingen rond modularisatie [Parnas72] en abstracte data types [Liskov77]. Het eerste sleutelwoord is encapsulatie. Een object heeft nooit rechtstreeks toegang tot de interne variabelen van een ander object. Het heeft alleen toegang tot de methoden die voor het object zijn gedefinieerd. Als er iets in de toestand van een object moet worden veranderd, dan moet dat dus altijd via de aanroep van zo'n methode gaan, dus via het versturen van een bericht naar het object.
[...]

[ Voor 59% gewijzigd door -Odysseus- op 13-07-2004 16:18 ]

[alienfruit]

Tja, gezien PHP4 brakke OO ondersteuning, houd ik me daar echt niet aan

[-Odysseus-]

alienfruit schreef op 13 juli 2004 @ 17:16:
Tja, gezien PHP4 brakke OO ondersteuning, houd ik me daar echt niet aan

Als je het dan maar wel bij PHP5 doet

[alienfruit]

Mja, in PHP5 is het al wat minder brak

[Ritch]

-Odysseus- schreef op 13 juli 2004 @ 15:31:
[...]

Een wachtwoord zou je eigenlijk niet aanspreekbaar moeten maken ook al ben je nog zo zeker over de security van de rest van je systeem. Daarnaast is bij het aanmaken van een nieuwe account, het helemaal niet nodig om voor het wachtwoord een attribuut te hebben. Dit wachtwoord zal toch niet worden teruggegeven aan de gebruiker en is enkel nodig in bijvoorbeeld de query naar de database.* Dit vergroot alleen maar de security van je systeem.

Sorry maar klinkklare onzin, iemand zou de code rechtstreeks aan moeten kunnen spreken wil die achter de inhoud van die variable komen. Als iemand mijn code aan kan spreken kan die ook leuke drop table statements door m'n DB lib gooien, oftewel, op dat moment heeft security geen zin meer.

*edit: er zou zich op 1 moment een situatie kunnen voordoen dat de gebruiker z'n wachtwoord terugkrijgt: wanneer een wachtwoord gegenereerd wordt, maar dan nog is het niet nodig om deze in een attribuut op te slaan.

Hoezo niet nodig? Maakt het uit? Je slaat dat, al dan niet gegeneerde, password op in een variable, of die nou ergens global leeft, binnen een functie of dat het een class var is maak nix uit. Als je dan toch bezig bent, hou het wachtwoord dan lekker bij de rest van de user data...

[Verwijderd]

Dr_Frickin_Evil schreef op 13 juli 2004 @ 14:15:
[...]

Dat is misschien in andere talen zo, maar in PHP kan dat toch prima? Waarom daar geen gebruik van maken?

Dan zal ik een voorbeeld geven van waarom je niet gelijk variabelen in klassen aan moet spreken.

Stel je hebt een pizza bedrijf. Dus:

PHP:

class PizzaBestelling
{
     var $PizzaType; // quatre frommage etc.

Nu wil je weten welke type pizza is besteld. Dan zeggen jullie:

PHP:

PizzaBestelling::$PizzaType

Dan heb je de bestelde type pizza, niets aan de hand.
Alleen dan wil je dat pizza marguarita uit het assortiment gaat. Maar een klant heeft die pizza besteld en je vraagt hem op en je krijgt marguarita terug. Oh-ow verkeerde pizza, die mag niet, nu moet je al je andere klassen ombouwen om dit te regelen.

Als je dit via een functie had gedaan, hoefde je alleen de functie aan te passen.

Dus het is veel makkelijker om variabelen aan te roepen dmv. methoden. (ik heb alleen wel een raar voorbeeld gebruikt, kon niets beters verzinnen, maar ik hoop dat het duidelijk is.)

[-Odysseus-]

Ritch schreef op 13 juli 2004 @ 19:31:
[...]

Sorry maar klinkklare onzin, iemand zou de code rechtstreeks aan moeten kunnen spreken wil die achter de inhoud van die variable komen. Als iemand mijn code aan kan spreken kan die ook leuke drop table statements door m'n DB lib gooien, oftewel, op dat moment heeft security geen zin meer.

Het is geen onzin. Als het niet aan te roepen is, kan een devver ook geen foutje maken door per ongeluk het wachtwoord te echo'en bijv. Maar goed hier verschillen we van mening.

Hoezo niet nodig? Maakt het uit? Je slaat dat, al dan niet gegeneerde, password op in een variable, of die nou ergens global leeft, binnen een functie of dat het een class var is maak nix uit. Als je dan toch bezig bent, hou het wachtwoord dan lekker bij de rest van de user data...

Als je een variabele niet nodig hebt of niet wil aanspreekbaar wil maken voor de rest van je code dan moet je dat ook niet doen onder het mom van: ach, ik heb um toch al. Als je een variabele in een functie gebruikt is deze niet te benaderen door de rest van het script. Dus kan je um mooi onaanspreekbaar houden.

[creative8500]

Verwijderd schreef op 13 juli 2004 @ 20:30:
Dus het is veel makkelijker om variabelen aan te roepen dmv. methoden. (ik heb alleen wel een raar voorbeeld gebruikt, kon niets beters verzinnen, maar ik hoop dat het duidelijk is.)

Wat een onzin! Jij stelt dat wanneer je een product niet meer verkoopt alle orders uit het verleden van dat product aangepast moeten worden! Droom lekker verder, de administratie van die pizzeria raakt op een dergelijke manier hopeloos corrupt. _NOFI

Je hebt overigens nog niet verteld hoe het met methoden beter kan.

[creative8500]

-Odysseus- schreef op 13 juli 2004 @ 21:07:
Het is geen onzin. Als het niet aan te roepen is, kan een devver ook geen foutje maken door per ongeluk het wachtwoord te echo'en bijv. Maar goed hier verschillen we van mening.

Dat is écht een non-argument, IMHO. Van mij mag bijvoorbeeld iedereen mijn wachtwoord weten, maar niemand waar ik woon - ik zeg maar wat. Ik vraag me bovendien af of die methode checkPassword er wel een zou moeten zijn van de user. Deze lijkt mij zelfs niet eens in een klasse thuishoren, eerlijk gezegd. Elke developer moet gewoon voorzichtig zijn, simple as that. Wanneer jij een 'domme developer' bent of in je team hebt kun je zijn begrip van de situatie beter verbeteren dan jouw interfaces 'obfuscaten', voor het geval dát.

[Ritch]

-Odysseus- schreef op 13 juli 2004 @ 21:07:
[...]
Het is geen onzin. Als het niet aan te roepen is, kan een devver ook geen foutje maken door per ongeluk het wachtwoord te echo'en bijv. Maar goed hier verschillen we van mening.

Ik ga er van uit dat door de intilligentie van de ontwikkelaars waar ik mee samen werk, de code review die een andere ontwikkelaar doet en het test traject zulke dingen gewoon niet voor komen. Oftewel, ik hou in een ontwerp en in m'n code geen rekening met totale onnozelheid van andere mensen. Maar misschien heb ik dan het geluk dat ik niet met onnozele mensen hoef samen te werken (gelukkig!)

[...]
Als je een variabele niet nodig hebt of niet wil aanspreekbaar wil maken voor de rest van je code dan moet je dat ook niet doen onder het mom van: ach, ik heb um toch al. Als je een variabele in een functie gebruikt is deze niet te benaderen door de rest van het script. Dus kan je um mooi onaanspreekbaar houden.

Klein probleempje: $_POST['password'] of $PHP_AUTH_PW
Opzich begrijp ik redenering wel, maar de rest van het script kan precies hetzelfde als die ene functie waar die variabele in zit, dus het heeft weinig nut imho. Als je jou een webservice maakt ofzo die interactie heeft met allerlei verschillende clients dan geef ik je gelijk, in de code uit hetzelfde project vind ik het overbodig.

[alienfruit]

Blijkbaar niet meer beta

he PHP development team is proud to announce the official release of PHP 5.

Some of the key features of PHP 5 include:
- The Zend Engine II with a new object model and dozens of new features.
- XML support has been completely redone in PHP 5, all extensions are now focused around the excellent libxml2 library (http://www.xmlsoft.org/).
- A new SimpleXML extension for easily accessing and manipulating XML as PHP objects. It can also interface with the DOM extension and vice-versa.
- A brand new built-in SOAP extension for interoperability with Web Services.
- A new MySQL extension named MySQLi for developers using MySQL 4.1 and later. This new extension includes an object-oriented interface in addition to a traditional interface; as well as support for many of MySQL's new features, such as prepared statements.
- SQLite has been bundled with PHP. For more information on SQLite, please visit their website (http://www.sqlite.org/).
- Streams have been greatly improved, including the ability to access low-level socket operations on streams.
- And lots more...

[creative8500]

creative8500 schreef op 13 juli 2004 @ 21:17:
Dat is écht een non-argument, IMHO. Van mij mag bijvoorbeeld iedereen mijn wachtwoord weten, maar niemand waar ik woon - ik zeg maar wat. Ik vraag me bovendien af of die methode checkPassword er wel een zou moeten zijn van de user. Deze lijkt mij zelfs niet eens in een klasse thuishoren, eerlijk gezegd. Elke developer moet gewoon voorzichtig zijn, simple as that. Wanneer jij een 'domme developer' bent of in je team hebt kun je zijn begrip van de situatie beter verbeteren dan jouw interfaces 'obfuscaten', voor het geval dát.

Ik ben om, zij het om een geheel andere redenen dan die -Odysseus- aanvoerde.

PHP:

<?php

/**
 * Exception that is to be thrown when the given password doesn't match the actual
 * password, and therefore a procedure must stop.
 */
class IncorrectPasswordException extends Exception
{
    //
}

/**
 * Excerpt of the User class
 */
class User
{
    /**
     * Password
     * 
     * @access     private
     * @var        string
     */
    private $password;
    
    /**
     * @access     public
     * @throws     IncorrectPasswordException
     */
    public function checkPassword ($password)
    {
        if ($this -> password !== md5 ($password))
            throw new IncorrectPasswordException;
    }
    
    /**
     * @access     public
     * @param      string $oldPassword
     * @param      string $newPassword
     * @throws     IncorrectPasswordException
     */
    public function changePassword ($oldPassword, $newPassword = (string) null)
    {
        try
        {
            /*
             * Validate the old password; throws IncorrectPasswordException if
             * $oldPassword doesn't equal User::$password.
             */
            $this -> checkPassword ($oldPassword);
            $this -> password = md5 ($newPassword);
        }
        catch (IncorrectPasswordException $Exception)
        {
            throw $Exception;
        }
    }
}

?>

[ Voor 3% gewijzigd door creative8500 op 19-07-2004 01:12 ]

[Verwijderd]

Zou je die reden dan met ons kunnen delen? Want ik vind nog altijd dat die $password variabele er niet hoort.

a. Heb je er iets aan? Nee.
b. Zou het misschien mogelijk ooit ergens problemen jeweet'tniet kunnen veroorzaken? Ja.

Dus niet doen.

-Odysseus- schreef op 13 juli 2004 @ 10:33:
OO-technisch is het btw eigenlijk beter om het zo te doen:

PHP:

$article->GetUsersName();
// en article roept dan op zijn beurt weer
$user->GetName();

Uhhh... nee, dat is 't niet.

Waarom niet?

Omdat je dan alle methoden die je op User hebt en mogelijk zou willen kunnen aanroepen gegeven een Article instantie zult moeten kopiëren en doorlussen.

Niet echt elegant, wanne?

Van de andere kant, als je een User instantie aan het article hangt is het mooier, makkelijker aan te passen en te beheren, en minder typwerk .

Viz: $article->getAuthorJoinedDate() (??) tegen $article->author->getJoinedDate().

I rest my case.

[JayVee]

Voor mijn bedrijfje heb ik ook al een paar keer zo iets in elkaar gezet.

Classes vind ik alleen iets voor een database Handler of zo, maar om nou je hele project in OO te schrijven? Ik zie het nut niet in. Kwestie van smaak denk ik.

Wij doen het meestal zo: Je hebt een setup.php bestand en die doet wat de naam al zegt. Kijkt of je ingelogd bent, welke stylesheet je ingesteld hebt (uit db of cookie), dat soort zaken. Dit bestand include vervolgens een layout bestand waar de generieke layout (title, evtl. navigatie) in staat. Dat bestand wederom include modules.

Zo een module bevat de eigelijke content en kan dus zijn: foto upload, foto beheer, nieuwspost, user management. Elke module genereert alleen de echte content HTML, niet meer. Deze modules zijn ook allemaal php files uiteraard.

Zo heb je je code mooi in stukken en kan je deze zelfs in mappen groeperen (admin/ bezoeker, etc).

Vinden wij iig erg handig en overzichtelijk werken.

[creative8500]

OneOfBorg: Zou je die reden dan met ons kunnen delen?

Mijn redenatie is als volgt: wanneer jij je registreert bij een forum, dan maak jij in feite een kopie van jezelf op de server, in de vorm van een User-object. Uitgaande van dit model maak ik deze aannamen, die voor mij bepalen hoe het User-object eruit ziet:

1. Je wilt alleen dat jouw User een bericht kan plaatsen in een topic wanneer de websitebezoeker zichzelf kan identificeren als zijnde jij, door te zien of de bezoeker het het door jezelf ingestelde wachtwoord weet.
2. Wanneer iemand jouw haarkleur wil weten, vertel je gewoon je haarkleur. Vandaar dat een eventuele haarkleur-property public is.
3. Wanneer iemand jouw PIN-code wil weten, zeg je hem deze natuurlijk niet. Immers, je PIN-code is beschermde informatie. Vandaar dat het wachtwoord protected of private is. (Ik zit nog te twijfelen tussen deze twee.)
4. De enige openheid die wat jou betreft jouw afgevaardigde User mag bieden aangaande het wachtwoord is de meest basale bevestiging of een bepaalde string overeenkomt met het wachtwoord, of niet. Je geeft geen hints; je zegt niet hoe lang het wachtwoord is, of dat de ingevoerde string 'warm' of 'koud' is, niks van dit alles. Je zegt alleen of het wachtwoord klopt, want dat is de enige openheid die je nodig hebt om jezelf te identificeren.

Vandaar.

[Verwijderd]

Juh, maar je beslissing om het wachtwoord toch een instantievariabele te maken hangt er dus van af [of] dat je de variabele private/protected kunt maken (Ik zou private doen; subclasses hebben niks meer met dat wachtwoord te maken, imho).

Nou heb ik nog volledig geen ervaring met PHP5, en ik laat het nog ff links liggen tot het breed ondersteund wordt (Exceptions... yayy! ). Ik zat dus vanuit PHP4 oogpunt te denken en daar heb je die luxe niet.

Overigens begint PHP5 wel erg Java-ish te worden he

[JayVee]

Wow, ik heb een super artikel gevonden over OO PHP(5):
Zend in the clowns (lees vooral vanaf "i. The Backdrop").

Ik zie nu eindelijk het nut in van OO en classes in PHP (ben het gewoon eens met de auteur). En het nut ligt niet in het schrijven van scripts voor websites. Lees het artikel maar eens voor redenatie.

//edit:
Is misschien beetje offtopic. Maar lees het artikel en denk er nog eens over na waarom je OO zou gebruiken.

[ Voor 19% gewijzigd door JayVee op 22-07-2004 17:09 ]