[PHP] vragen rond OOP

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Naar aanleiding van het [alg] Slechtste programmeervoorbeelden deel 4 topic, heb ik dit topic geopend.

Ik zit namelijk nog met elke vragen rond OOP, ik wil voornamelijk weten of de manier van toepassen van OOP nog beter kan.
Ik ben bezig met een redelijk uitgebreid inlog script te maken, later komt er nog een rechten systeem bij.

In de class users heb ik om te beginnen enkele proporties aangemaakt.
code:
1
2
3
private $con;
private static $salt;
private $pepper;


Vervolgens heb ik een __construct die, van de property con een PDO verbinding maakt, die krijgt zijn gegevens ui de parameters bij de __construct, die doorgegeven worden bij het aanmaken van de nieuwe class. In de __construct wordt ook de functie start_session (zie later) aangeroepen, die gaat kijken of er een sessie is, zoja dan doet ie niks, als er geen sessie is dan maakt die er eentje aan.

Ik probeer in objecten te denken, en maak daarom ook voor alles wat meerdere keren wordt gebruik een functie aan. Ik heb momenteel de volgende functies:
  • register
  • login
  • authentification_required
  • logout
  • changeProfile
  • EmailInUse
  • UsernameInUse
  • crypt_password
  • start_session
Nu vraag ik mij af of ik van de gebruikrsnaam, paswoord, voornaam en dergelijke ook propertys moet maken? Ik ben hier enorm hard over aan het twijfelen. Maar ik denk dat dat het beste is?

Ik heb hier geen code gepost, omdat als ik het goed had GoT geen code nakijk dienst was.

Acties:
  • 0 Henk 'm!

  • Ventieldopje
  • Registratie: December 2005
  • Laatst online: 10:43

Ventieldopje

I'm not your pal, mate!

Ik denk dat je nog wat meer in moet lezen over OOP en dan met name in combinatie met databases dmv. Database Abstraction Layers (DBAL) en Object Relation Mapper (ORM) systemen. Doctrine is een hele bekende voor PHP.

http://www.doctrine-project.org/projects/orm.html

www.maartendeboer.net
1D X | 5Ds | Zeiss Milvus 25, 50, 85 f/1.4 | Zeiss Otus 55 f/1.4 | Canon 200 f/1.8 | Canon 200 f/2 | Canon 300 f/2.8


Acties:
  • 0 Henk 'm!

  • ID-College
  • Registratie: November 2003
  • Laatst online: 21:01
Heb je niet wat code? En waarom heeft een user class een property connectie? Een db connectie is toch geen eigenschap van een user? Kijk eens naar het singleton pattern voor PHP..

Overigens hebben heel je functies weinig met OOP te maken, maar zijn meer een verzameling functies met een class eromheen ;)

[ Voor 41% gewijzigd door ID-College op 08-07-2012 15:55 ]


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Ventieldpoje, ik vraag me af waarom ik een extensie in PHP nodig heb voor te verbinden met een database? Ik gebruik PDO. Ik heb ook alleen FTP toegang tot mijn server. (Shared hosting :p)

Users.php met de users class is meer dan 300 regels lang, dat is denk ik wat te lang om hier te posten. Ik begrijp nu ook beter wat een property doet, en denk dan ook dat ik beter van firstname enzo een property maak?
Om toch wat code te geven, dit is de login functie;
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
function login()
    {   
                                
        $error = array();
        if (empty($_POST['username']))
        {
            array_push($error, 'username');
        }
        if  (empty($_POST['password']))
        {
            array_push($error, 'password');
        }
        
        
        $sql = "SELECT username, password, pepper, firstname, email, lastname FROM users WHERE username=?";
        $q = $this->con->prepare($sql);
        $q->execute(array($_POST['username']));
        $row = $q->fetch();
        
        //Check password with password in database

        $password_crypt = $this->crypt($_POST['password'], $row['pepper']);
        if ($password_crypt == $row['password'])
        {
            $this->start_session();
            $_SESSION['username'] = $row['username'];
            $_SESSION['firstname'] = $row['firstname'];
            $_SESSION['lastname'] = $row['lastname'];
            $_SESSION['email'] = $row['email'];
                
            header("Location: safe.php"); 
        }
        else
        {   
            array_push($error, 'passwordWrong');
            $login_data[] = $_POST['username'];
            $login_data[] = $error;
            return $login_data;
        }
    }


Dit is de link waar ik mij op gebaseerd heb om de connectie te maken: http://stackoverflow.com/...264/use-of-pdo-in-classes

Alvast bedankt!

EDIT: de post hierboven is gewijzigd, dat is ook de reden waarom ik hier kom aankloppen.

Acties:
  • 0 Henk 'm!

  • ID-College
  • Registratie: November 2003
  • Laatst online: 21:01
Je bedoelt extends in PHP met je eerste zin? Weet je waar extends voor dient? Extends is een generalization in UML en gebruik je wanneer meerdere childs vrijwel hetzelfde zijn. Iedere child heeft zijn eigen karakteristieken maar zijn deels gelijk (en die staan in de parent).

Anyway, wat wil je nu precies? Want ik heb geen idee hoe je objectmodel eruit ziet en wat je nu precies verwacht. Heb je een UML gemaakt? Je weet toch zelf wat eigenschappen van een user zijn? Die staan als het goed is in je userclass? Waar heb je ze anders staan?

[ Voor 13% gewijzigd door ID-College op 08-07-2012 16:17 ]


Acties:
  • 0 Henk 'm!

  • Webgnome
  • Registratie: Maart 2001
  • Laatst online: 19:32
OOP vergt van je dat je in objecten leert denken. Een Object is een respresentatie van een real-life object ( een user, een auto , een fiets) of een samenvoeging van functionaliteiten die allemaal hetzelfde doel hebben.

Als het je lukt om in objecten te gaan denken dan kun je gaan denken over Single Responsiblity Principle. Dat betekend dat een class eigenlijk goed is in maximaal 1 ding en de zaken die met dat ene ding te maken hebben. Denk dus bij OOP goed na over wat elke class gaat doen.

Zo zou je voor een inlog script procedure niet maar 1 class mogen hebben. Je hebt een class die het formulier met daarin de user/password afhandelt. Deze class is dan de Controller (leesvoer: MVC ). Het form is de View. Het model is dan een user object waar de informatie van gecontroleerd wordt.

De controller zal niet zelf de controle gaan doen of een wachtwoord correct is etc maar zal dit overdragen aan een object dat daar goed in is. Noem het de SecurityManager bijvoorbeeld. Deze gaat aan de hand van een gebruikersnaam en een opgegeven wachtwoord controleren of dat wachtwoord hoort bij de gebruiker en geeft een melding terug. De stappen die daarbij nodig zijn weet alleen de security manager. De controller vraagt puur aan deze manager of dat het wachtwoord correct is. Hoe dat zou de controller niet hoeven te weten. Immers de controller is puur een doorgeef luikt naar de back-end.

Vervolgens worden door de controller de nodige dingen aangeroepen om de gebruiker een sessie te geven (dit is weer een eigen responsibility die door een sessionmanager afgehandeld wordt) etc etc..

Binnen het MVC framework is de controller de glue tussen de entiteiten ( user, fiets, auto .. ) de busineslogica ( security manager etc.. ) en de gebruiker ( inlog formuliertje, overzicht van iets etc. de pagina dus.

Wat belangrijk is binnen OOP is dus het scheiden van je functionaliteit over verschillende lagen / objecten. Het liefst zo generiek mogelijk dat je het ook nog eens kunt hergebruiken in een ander project zonder al te veel aanpassingen te doen. Ik zou zeggen ga eens een paar boeken lezen / tutorials volgen over wat OOP nou precies is en probeer aan de hand van een practicum eens uit of je dat lekker vind werken.


Natuurlijk is het bovenstaande maar een heel simpele weergave van OOP want er komt veel meer bij kijken. Maar het lijkt me slim als je dit eerst eens probeert te begrijpen.

[ Voor 16% gewijzigd door Webgnome op 08-07-2012 16:47 ]

Strava | AP | IP | AW


Acties:
  • 0 Henk 'm!

  • Caelorum
  • Registratie: April 2005
  • Laatst online: 20:41
ID-College schreef op zondag 08 juli 2012 @ 16:15:
[..] Anyway, wat wil je nu precies? Want ik heb geen idee hoe je objectmodel eruit ziet en wat je nu precies verwacht. Heb je een UML gemaakt?[...]
Ik vermoed niet dat die een Unified Modeling Language heeft gemaakt :P De vraag zou moeten zijn heb je nagedacht over de architectuur van je software en daarbij eventueel een class diagram en dergelijke.

@onder aangezien er een stuk of 15 UML diagrammen zijn was het niet geheel logisch. Vooral aangezien je architectuur op meerdere niveaus moet bekijken.

[ Voor 14% gewijzigd door Caelorum op 08-07-2012 16:21 ]


Acties:
  • 0 Henk 'm!

  • ID-College
  • Registratie: November 2003
  • Laatst online: 21:01
Bedoel een UML klassediagram maar dat lijkt me logisch :P

Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Bedankt voor de antwoorden, ik dacht écht dat je alles in één class moest steken. Ik ga even bedenken hoe ik het ga aanpakken, en kom dan terug.

Acties:
  • 0 Henk 'm!

  • Caelorum
  • Registratie: April 2005
  • Laatst online: 20:41
Misschien handig leesvoer is deze site: http://www.oodesign.com/design-principles.html
Hoewel wellicht niet geheel makkelijk te begrijpen in het begin zal het vanzelf wel dagen. Lees vooral goed de uitgebreide motivatie van elk van de principles. (de namen zijn klikbaar :P)
Waarvan vooral in het begin toch wel de belangrijkste de single responsibility principle is die al eerder is genoemd door Webgnome.

[ Voor 27% gewijzigd door Caelorum op 08-07-2012 16:32 ]


Acties:
  • 0 Henk 'm!

  • Ventieldopje
  • Registratie: December 2005
  • Laatst online: 10:43

Ventieldopje

I'm not your pal, mate!

LEDfan schreef op zondag 08 juli 2012 @ 16:05:
Ventieldpoje, ik vraag me af waarom ik een extensie in PHP nodig heb voor te verbinden met een database? Ik gebruik PDO. Ik heb ook alleen FTP toegang tot mijn server. (Shared hosting :p)

Users.php met de users class is meer dan 300 regels lang, dat is denk ik wat te lang om hier te posten. Ik begrijp nu ook beter wat een property doet, en denk dan ook dat ik beter van firstname enzo een property maak?
Om toch wat code te geven, dit is de login functie;
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
function login()
    {   
                                
        $error = array();
        if (empty($_POST['username']))
        {
            array_push($error, 'username');
        }
        if  (empty($_POST['password']))
        {
            array_push($error, 'password');
        }
        
        
        $sql = "SELECT username, password, pepper, firstname, email, lastname FROM users WHERE username=?";
        $q = $this->con->prepare($sql);
        $q->execute(array($_POST['username']));
        $row = $q->fetch();
        
        //Check password with password in database

        $password_crypt = $this->crypt($_POST['password'], $row['pepper']);
        if ($password_crypt == $row['password'])
        {
            $this->start_session();
            $_SESSION['username'] = $row['username'];
            $_SESSION['firstname'] = $row['firstname'];
            $_SESSION['lastname'] = $row['lastname'];
            $_SESSION['email'] = $row['email'];
                
            header("Location: safe.php"); 
        }
        else
        {   
            array_push($error, 'passwordWrong');
            $login_data[] = $_POST['username'];
            $login_data[] = $error;
            return $login_data;
        }
    }


Dit is de link waar ik mij op gebaseerd heb om de connectie te maken: http://stackoverflow.com/...264/use-of-pdo-in-classes

Alvast bedankt!

EDIT: de post hierboven is gewijzigd, dat is ook de reden waarom ik hier kom aankloppen.
Hoe kom je er bij dat Doctrine een php extensie is? Dat is het helemaal niet, het is een flexibele library (allemaal php bestanden ... alleen ftp toegang nodig dus!). Die library helpt je naast het opbouwen van een verbinding naar je database ook om met Entities/Models te werken en vooral dat laatste lijkt een beetje op de kant die je op wil.

Maar zoals ze hier boven ook al melden, lees eerst gewoon eens wat over de basis van OOP :)

www.maartendeboer.net
1D X | 5Ds | Zeiss Milvus 25, 50, 85 f/1.4 | Zeiss Otus 55 f/1.4 | Canon 200 f/1.8 | Canon 200 f/2 | Canon 300 f/2.8


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Bedankt voor de antwoorden. Ik ga het allemaal nalezen, en ook even het hoofdstuk over OOP in mijn PHP boek herbekijken. Maar het begint allemaal duidelijker te worden.

Ik heb eens uitgedacht welke functies en welke klassen ik nodig zou hebben. Ik ga dus verschillende klassen gebruiken, maar in de meeste klassen heb ik dezelfde functies nodig, kan ik deze klassen dan in één grote klass zetten? Of is dat niet de bedoeling.

EDIT: ik bedenk me dat ik ook een klas aan kan maken met de gemeenschappelijke functies, en dan uit die andere klassen die functies in de klas met de gemeenschappelijke functies aan te roepen.

[ Voor 18% gewijzigd door LEDfan op 08-07-2012 21:28 ]


Acties:
  • 0 Henk 'm!

  • X_lawl_X
  • Registratie: September 2009
  • Laatst online: 11-09 16:13
LEDfan schreef op zondag 08 juli 2012 @ 21:25:
EDIT: ik bedenk me dat ik ook een klas aan kan maken met de gemeenschappelijke functies, en dan uit die andere klassen die functies in de klas met de gemeenschappelijke functies aan te roepen.
Nee, als je een groep functies die toevallig bij elkaar passen in één classe gooit, ben je niet meteen bezig met OOP.

Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Ok dus, dan moet ik met childs/paretens werken? Dan ga ik maar eens een UML tekenen.

Acties:
  • 0 Henk 'm!

  • X_lawl_X
  • Registratie: September 2009
  • Laatst online: 11-09 16:13
LEDfan schreef op zondag 08 juli 2012 @ 21:43:
Ok dus, dan moet ik met childs/paretens werken? Dan ga ik maar eens een UML tekenen.
Alleen als een child-classe ook echt een relatie heeft met de parent. Zo kan een Auto een Voertuig extenden.

Wat je echter niet moet doen is klassen overerven om makkelijker gebruik te maken van de parent-methodes. (Geloof me, ik heb al een aantal keer een User-klasse een Database klasse zien overerven, zodat de getConnection() methodes eenvoudiger aangeroepen konden worden.)

Het is geen slecht idee om het eerst voor jezelf in UML te modelleren, dat maakt het ook veel makkelijker voor ons om te zien of je goed op weg bent. :)

[ Voor 11% gewijzigd door X_lawl_X op 08-07-2012 21:51 ]


Acties:
  • 0 Henk 'm!

  • ibmos2warp
  • Registratie: Januari 2007
  • Laatst online: 20-11-2023

ibmos2warp

Eval is Evil

LEDfan schreef op zondag 08 juli 2012 @ 21:43:
Ok dus, dan moet ik met childs/paretens werken? Dan ga ik maar eens een UML tekenen.
Childs/paretens? Wat had je daarbij in gedachte?

Soms kan je wel overerven, je moet goed kijken naar de rollen van de objecten. Bijvoorbeeld een manager is een persoon, een student is ook een persoon. Een manager en een student kunnen beide een persoon overerven vanwegen 'is een'.
Een auto kan een naam hebben, een student kan een naam hebben, maar het zijn hele andere dingen dus ze kunnen niet dezelfde klasse overerven.

Ik weet alles van niks
Vind Excel ongelovelijk irritant.


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Nogmaals bedankt voor de reacties. Eigenlijk heeft de parent niets met de childs te maken, dus dan zal ik dat ook niet zo doen. Dan mag er in verschillende klassen (bijna) dezelfde functies zijn?

Acties:
  • 0 Henk 'm!

  • ibmos2warp
  • Registratie: Januari 2007
  • Laatst online: 20-11-2023

ibmos2warp

Eval is Evil

LEDfan schreef op zondag 08 juli 2012 @ 21:52:
Nogmaals bedankt voor de reacties. Eigenlijk heeft de parent niets met de childs te maken, dus dan zal ik dat ook niet zo doen. Dan mag er in verschillende klassen (bijna) dezelfde functies zijn?
Waarom niet?
Kan juist heel goed.

Ik weet alles van niks
Vind Excel ongelovelijk irritant.


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Ik denk dat ik nog te veel denk dat OOP rechtstreeks minder code betekent. Ik ga aan de slag, en kom terug voor vragen, en hoe het is afgelopen.

Acties:
  • 0 Henk 'm!

  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11-09 05:38

Firesphere

Yoshis before Hoshis

Even afgezien van het hele OOP-verhaal, wel even een kleine kanttekening bij de code die je postte.

Je gooit de input van een veld rechtstreeks naar de database. Dit is vragen om SQL-injectie. Pak dat dus ook even een beetje mee, het beveiligen van je input naar SQL.

Verder heb ik weinig toe te voegen aan wat Webgnome al zei. En hij verwoordt het beter dan ik zou kunnen :P

I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Voor SQL injection ben ik al meermaals gewaarschuwd daarom ook overgestapt op prepared staments met behulp van PDO. Ik dacht dat je SQL injection dan automatisch tegenhield?

Acties:
  • 0 Henk 'm!

  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11-09 05:38

Firesphere

Yoshis before Hoshis

LEDfan schreef op zondag 08 juli 2012 @ 21:52:
Nogmaals bedankt voor de reacties. Eigenlijk heeft de parent niets met de childs te maken, dus dan zal ik dat ook niet zo doen. Dan mag er in verschillende klassen (bijna) dezelfde functies zijn?
Daarvoor heb je dus de parent:: operator.

Als je neemt "persoon"
PHP:
1
2
3
4
5
6
7
8
9
10
Class Student extends Persoon {
        static $db = array(
                'Studentnummer' => 'varchar',
        );

        public function storeData($data){
                parent::storeData();
                $this->Studentnummer = $data['Studentnummer'];
        }
}

($data is dus de post, die via de controller aan het model wordt meegegeven)
Eigenlijk is dit een slecht voorbeeld, maar het gaat om dat ik dus het "erven" even probeer versimpeld uit te leggen.
Want een persoon heeft natuurlijk altijd een huis (externe class en dus ook een ander model!), een naam en een sofinummer (bijvoorbeeld), maar dat heeft de docent niet.

Via de extended de parent aanroepen, hoef je alleen maar de class-specifieke data extra af te handelen, de rest kan de parent doen.

Excuses voor de pruts-code die waarschijnlijk alleen werkt in het framework waar ik meestal mee werk, maar dat terzijde, was ff het snelste uitleggen.
LEDfan schreef op zondag 08 juli 2012 @ 22:01:
Voor SQL injection ben ik al meermaals gewaarschuwd daarom ook overgestapt op prepared staments met behulp van PDO. Ik dacht dat je SQL injection dan automatisch tegenhield?
In theorie is dat een heel eind, maar better safe then sorry (wiki)
Although Prepared Statements helps in defending against SQL Injection, there are possibilities of SQL Injection attacks through inappropriate usage of Prepared Statements.
Het is in theorie ook mogelijk om via PS toch injectie uit te voeren dacht ik.

[ Voor 27% gewijzigd door Firesphere op 08-07-2012 22:07 ]

I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Zo begrijp ik OOP beter, maar met een login procedure vind ik dat wat moeilijker. (Zo staat het ook uitgelegd in men boek maar dan met werknemers)

Acties:
  • 0 Henk 'm!

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

LEDfan schreef op zondag 08 juli 2012 @ 22:01:
Voor SQL injection ben ik al meermaals gewaarschuwd daarom ook overgestapt op prepared staments met behulp van PDO. Ik dacht dat je SQL injection dan automatisch tegenhield?
Prepared statements helpen inderdaad, maar maken je script niet volledig beschermd tegen SQL-injection. Een mysql_real_escape_string() (of de PDO variant ervan) zal je allicht nóg verder helpen.

Acties:
  • 0 Henk 'm!

  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11-09 05:38

Firesphere

Yoshis before Hoshis

Wat snap je niet aan de login-procedure, tenminste, van wat je hier boven hebt neergezet als login-procedure?

I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Bedankt CptChaos, zal het eens bekijken, maar PDO wordt ook in men boek behandeld.
Firesphere, ik snap men login procedure wel (heb het zelf geschreven), ik bedoelde dat het moeilijk te vergelijken is met werknemers of studenten. Natuurlijk is het in OOP het zelfde.

Acties:
  • 0 Henk 'm!

  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11-09 05:38

Firesphere

Yoshis before Hoshis

De login-procedure verandert niet met OOP.

Wat wel verandert, is dat je via een dergelijke parent-child relatie, je dus studenten (of werknemers), naar een andere plek kan sturen na verificatie.

De verificatie gaat aan de hand van de parent, die username/password bevat, en een link naar wat voor soort persoon er inlogt (in je database/repository dus). (Als je't goed doet ;) ).

Mijn voorbeeld was puur de parent-child relatie inderdaad ;)

I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!


Acties:
  • 0 Henk 'm!

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

LEDfan schreef op zondag 08 juli 2012 @ 22:12:
Bedankt CptChaos, zal het eens bekijken, maar PDO wordt ook in men boek behandeld.
Firesphere, ik snap men login procedure wel (heb het zelf geschreven), ik bedoelde dat het moeilijk te vergelijken is met werknemers of studenten. Natuurlijk is het in OOP het zelfde.
Ik ben helaas niet zo heel bekend met OOP nog, maar kijk dus ook even naar escaping, dat is wat ik wilde aangeven. :)

Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Ah maar ik bedenk me nu dat ik voor het rechten systeem ook een klas kan maken, en daar child klassen in. Die child klassen stellen dan de verschillende soorten rechten voor. En dat kan je zeer gemakkelijke vergelijken met werknemers.

Ik ben blij dat ik dit topic heb geopend!

[ Voor 8% gewijzigd door LEDfan op 08-07-2012 22:26 ]


Acties:
  • 0 Henk 'm!

  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11-09 05:38

Firesphere

Yoshis before Hoshis

Dat is nog netter dan mijn rudimentaire idee!

Je hebt dan rechten, die je aan bepaalde classes koppeld. Dus een persoon van het "type" werknemer, zit dan in de "groep" werknemers rechten.
Waar managers dus in de managers rechten groep terecht komen.
Hoef je niet eens te childen trouwens, kun je ook koppelen.
De user heeft een rechtentype. Die types beheer je dan centraal. Niet childs aan rechten geven, maar rechten aan personen geven.
Een recht is namelijk 1 object. Meerdere rechten, hebben allemaal dezelfde basis-mogelijkheden die je aan of uit kan zetten dan.
(wordt wel abstract, sorry)


Je idee is wel heel erg OOP gedacht, verbetering t.o.v. topicstart is te zien :)

I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!


Acties:
  • 0 Henk 'm!

  • ibmos2warp
  • Registratie: Januari 2007
  • Laatst online: 20-11-2023

ibmos2warp

Eval is Evil

CptChaos schreef op zondag 08 juli 2012 @ 22:08:
[...]
Prepared statements helpen inderdaad, maar maken je script niet volledig beschermd tegen SQL-injection. Een mysql_real_escape_string() (of de PDO variant ervan) zal je allicht nóg verder helpen.
CptChaos schreef op zondag 08 juli 2012 @ 22:19:
[...]
Ik ben helaas niet zo heel bekend met OOP nog, maar kijk dus ook even naar escaping, dat is wat ik wilde aangeven. :)
Misschien moet je zelf ook eerst even de theorie bestuderen? Hij gebruikt namelijk al PDO en prepared statements helpen wel tegen sql injections.
Prepared statements is netter dan mysql_real_escape_string omdat de query gescheiden wordt van de data, de query wordt geprepared (van te voren gestuurd), de data wordt pas later gestuurd. Sql injections kunnen plaats vinden doordat de gebruiker de query kan aanpassen. Omdat de query bij prepared statements al verstuurd is kan de gebruiker de query niet aanpassen, daarom zijn prepared statements veilig. De scheiding van data en query maakt het ook nog eens mooi (net zoals je zoveel scheid).

Als je met prepared statemens niet veilig zit, dan zit je dat met mysql_real_escape_string ook niet en ben je waarschijnlijk best wel verkeerd bezig.

Ik weet alles van niks
Vind Excel ongelovelijk irritant.


Acties:
  • 0 Henk 'm!

  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11-09 05:38

Firesphere

Yoshis before Hoshis

Het is daarentegen geen "wrong practice" om de veilige methode te kiezen. Elke methode van een structured language uitvoeren, is gevoelig. Of dit nu prepared of direct is, of welke andere methode dan ook.

Effectief is het niet direct schadelijk om het niet te gebruiken.
Wel gebruiken, geeft net 1 stapje extra moeilijkheid.

I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!


Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 23:05
Caelorum schreef op zondag 08 juli 2012 @ 16:29:
Misschien handig leesvoer is deze site: http://www.oodesign.com/design-principles.html
Hoewel wellicht niet geheel makkelijk te begrijpen in het begin zal het vanzelf wel dagen. Lees vooral goed de uitgebreide motivatie van elk van de principles. (de namen zijn klikbaar :P)
Waarvan vooral in het begin toch wel de belangrijkste de single responsibility principle is die al eerder is genoemd door Webgnome.
Wat ik zelf een prettig boek vond om verschillende design patterns te leren kennen: Head First Design Patterns. Het legt aan allerlei simpele voorbeelden uit hoe de meest gebruikte patterns je (programmeer) leven makkelijker kunnen maken.

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • Zeebonk
  • Registratie: Augustus 2005
  • Laatst online: 30-07 20:50
Firesphere schreef op zondag 08 juli 2012 @ 22:46:
Effectief is het niet direct schadelijk om het niet te gebruiken.
Wel gebruiken, geeft net 1 stapje extra moeilijkheid.
Één stapje moeilijkheid extra voor jou zelf, alleen maar omdat je prepared statements niet vertrouwd omdat je blijkbaar niet snapt wat ze doen.

Gewoon voor alle database queries prepared statements gebruiken zoals ze zijn bedoeld en je bent beveiligd tegen SQL injection.

[ Voor 3% gewijzigd door Zeebonk op 08-07-2012 22:56 ]


Acties:
  • 0 Henk 'm!

  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11-09 05:38

Firesphere

Yoshis before Hoshis

Zeebonk schreef op zondag 08 juli 2012 @ 22:55:
[...]


Één stapje moeilijkheid extra voor jou zelf, alleen maar omdat je prepared statements niet vertrouwd omdat je blijkbaar niet snapt wat ze doen.

Gewoon voor alle database queries prepared statements gebruiken zoals ze zijn bedoeld en je bent beveiligd tegen SQL injection.
Niet vertrouwen != niet weten
Blindelings vertrouwen op een technologie, zorgt alleen maar voor problemen. Hoe meer je er voor zorgt dat de user-input NIET een injectie kan veroorzaken, hoe beter.

Wat jij zegt over "je snapt het niet" zie ik als "je snapt beveiliging niet". Sorry.

[ Voor 23% gewijzigd door Firesphere op 08-07-2012 23:16 ]

I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!


Acties:
  • 0 Henk 'm!

  • CH4OS
  • Registratie: April 2002
  • Niet online

CH4OS

It's a kind of magic

ibmos2warp schreef op zondag 08 juli 2012 @ 22:35:
Misschien moet je zelf ook eerst even de theorie bestuderen? Hij gebruikt namelijk al PDO en prepared statements helpen wel tegen sql injections.
Ik zeg ook niet dat prepared statements niet helpen tegen SQL injection, dat doen ze uiteraard wel, dat weet ik ook wel (las laatst hier op T.net: reviews: Sql-injectie en xss: de beste verdediging). Ik wil alleen zeggen, dat als je de input valideert en eventueel dus ook escaped je nog zekerder bent beveiligd tegen SQL injection.
Zeebonk schreef op zondag 08 juli 2012 @ 22:55:
Eén stapje moeilijkheid extra voor jou zelf, alleen maar omdat je prepared statements niet vertrouwd omdat je blijkbaar niet snapt wat ze doen.

Gewoon voor alle database queries prepared statements gebruiken zoals ze zijn bedoeld en je bent beveiligd tegen SQL injection.
Waarom je een prepared statement icm escaping betekend dat je de prepared statement niet zou vertrouwen begrijp ik niet helemaal. De prepared statement is immers in-house geschreven en dus beter te vertrouwen dan de input van de gebruiker. Naar mijn weten maken prepared statements de boel niet 100% SQL injection proof, dat is wat ik wil aangeven naast het niet vertrouwen van de user-input. ;)

[ Voor 30% gewijzigd door CH4OS op 08-07-2012 23:13 ]


Acties:
  • 0 Henk 'm!

  • Zeebonk
  • Registratie: Augustus 2005
  • Laatst online: 30-07 20:50
Data wat via prepared statements naar de database wordt gestuurd wordt niet door de SQL engine gehaald en zal dus nooit als SQL geinterpeteerd kunnen worden. SQL injection is daardoor uitgesloten. Als je ook nog eens real escape string gebruikt dan vertrouw je prepared statements dus niet, je zou het anders niet nodig achten.

Nogmaals, zolang je prepared statements gebruikt zoals ze bedoeld zijn. Ga je queries dynamisch opbouwen dan wordt het een ander verhaal.

Acties:
  • 0 Henk 'm!

  • Firesphere
  • Registratie: September 2010
  • Laatst online: 11-09 05:38

Firesphere

Yoshis before Hoshis

Mijn laatste offtopic reactie. Het gaat hier niet om sql-security.

Het is gewoon dom, om te vertrouwen op computers, dat ze ook echt doen wat ze zeggen.
Als je alleen prepared statements wil doen, prima, maar ik geloof er niet in. Ik schrijf liever 50 regels extra code, dan dat ik 1 injectie heb.
Dat heeft geen fluit te maken met of ik weet hoe het werkt (ja, weet ik echt wel hoor), heeft geen fluit te maken met of ik snap dat het prepared is (term says the word), en dus in theorie niet kan worden gebroken. Ik vertrouw een computer niet. Nooit. Programma's, welk programma dan ook, blijft een door mensen geschreven ding, kan dus door mensen gebroken worden. Blindelings vertrouwen op wat iets in theorie zou moeten doen is mij te gevaarlijk.

Dan laat ik het "dynamisch opbouwen" achterwege. Als je namelijk dynamisch opbouwd, is er alsnog het punt van execution, waar je prepared statements kan gebruiken.

Again, vertrouwen != kennis.

Back on topic if we can?

[ Voor 11% gewijzigd door Firesphere op 08-07-2012 23:46 ]

I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!


Acties:
  • 0 Henk 'm!

  • analog_
  • Registratie: Januari 2004
  • Niet online
Sessie beheer van usermanagement scheiden is al verstandig.

Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

Sorry, maar nee. Je kunt niet enorme onzin gaan lopen verkondigen in het laatste woord om vervolgens te vragen weer ontopic te gaan.
Het is gewoon dom, om te vertrouwen op computers, dat ze ook echt doen wat ze zeggen
Als je dit dom vindt, dan helpt geen enkele vorm van veiligheid en kun je net zo goed ander werk gaan zoeken, want blijkbaar doen "computers" gewoon wat ze willen ipv dat ze precies doen wat jij zegt 8)7

En van je originele opmerking:
Firesphere schreef op zondag 08 juli 2012 @ 21:58:
Je gooit de input van een veld rechtstreeks naar de database. Dit is vragen om SQL-injectie. Pak dat dus ook even een beetje mee, het beveiligen van je input naar SQL.
klopt gewoon niets.

Wellicht dat je af wil dwingen dat een username aan bepaalde eisen voldoet, maar dat heeft verder compleet niets te maken met SQL injectie (en het is bovendien irrelevant bij het inloggen). De code zoals de TS het gebruikt kan onmogelijk tot injectie leiden. En ja, integenstelling tot wat jij beweert kun je er best op vertrouwen dat het passen van input middels vraagtekens in prepared statements weldegelijk injectie voorkomt. Het zelf gaan zitten escapen is alleen maar vragen om moeilijkheden - het escapen en een of andere vorm van validatie is namelijk veel makkelijker te vergeten dan dat je ineens per ongeluk een waarde in je SQL statement concatenatet ipv bindt.

[ Voor 7% gewijzigd door .oisyn op 09-07-2012 02:00 ]

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • ibmos2warp
  • Registratie: Januari 2007
  • Laatst online: 20-11-2023

ibmos2warp

Eval is Evil

CptChaos schreef op zondag 08 juli 2012 @ 23:09:
[...]
Ik zeg ook niet dat prepared statements niet helpen tegen SQL injection, dat doen ze uiteraard wel, dat weet ik ook wel (las laatst hier op T.net: reviews: Sql-injectie en xss: de beste verdediging). Ik wil alleen zeggen, dat als je de input valideert en eventueel dus ook escaped je nog zekerder bent beveiligd tegen SQL injection.
[...]
Let goed op met 'nog eens' je data escapen, dit past dus je data aan:
PHP:
1
2
3
4
5
<?php $test = "test '";

var_dump($test, mysql_real_escape_string($test));
/*string 'test '' (length=6)
string 'test \'' (length=7)*/

Je moet dus niet zomaar gaan escapen, dat zorgt ervoor dat je data gewijzigd wordt en dus niet meer gebruikt kan worden voor checks (en weer dezelfde problemen kan veroorzaken zoals addslashes / magic quotes).
Firesphere schreef op zondag 08 juli 2012 @ 23:33:
[...]
Het is gewoon dom, om te vertrouwen op computers, dat ze ook echt doen wat ze zeggen.
Als je alleen prepared statements wil doen, prima, maar ik geloof er niet in. Ik schrijf liever 50 regels extra code, dan dat ik 1 injectie heb.
[...]
Als je je computer niet vertrouwd betekend dat waarschijnlijk dat jij problemen hebt ondervonden met software. Die problemen zijn meestal goed af te vangen tijdens de ontwikkeling door goed debuggen en uitgebreid te testen.
Als je '50 regels extra' schrijft moet je ook nog eens 50 regels extra testen om te kijken of het veilig is, of er geen fouten zijn, of er iets niet mis kan gaan. Het klinkt heel leuk '50 regels extra', maar het gaat over kwaliteit niet over kwantiteit. In '50 regels extra' kan je zoveel fouten introduceren, misschien introduceer je nu juist wel een sql injection omdat je erg vaag bezig bent (je code verhult misschien wat je doet).

Ja ik weet het, ik doe alleen mysql in het voorbeeld, ik neem aan dat je die gebruikt omdat die het meest gebruikt wordt en omdat als je postgresql zou gebruiken je waarschijnlijk al PDO gebruikt.

Ik weet alles van niks
Vind Excel ongelovelijk irritant.


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Ik heb een UML proberen te maken. Ik heb het nog nooit gemaakt, en heb dan eigenlijk een lijstje met klassen, functies, propertys en getters en setters in libre impress, omdat ik ook niet direct 'quickstart' informatie vond, maar wel tooltjes, die vooral voor Windows waren.

Ik heb het rechten systeem nog niet toegevoegd, omdat dat later komt.

De afbeelding

Is deze structuur OOP gedacht? Ik denk wel dat het duidelijk is wat wat is, anders vraag je het maar.

Even voor de duidelijkheid, ik gebruik MySQL in combinatie met PDO.

Ik ga nu uitzoeken, (met de links in dit topic) hoe ik het beste kan verbinden met de database.

Alvast bedankt!

EDIT: Nog even over de libary in het begin van het topic, waarom moet ik die gebruiken, en mag ik het niet doen zoals het hier staat: http://weebtutorials.com/...-using-singleton-pattern/ ? Enkel en alleen omdat con geen eigenschap van de class is?

[ Voor 15% gewijzigd door LEDfan op 09-07-2012 10:20 ]


Acties:
  • 0 Henk 'm!

  • Hydra
  • Registratie: September 2000
  • Laatst online: 21-08 17:09
IMHO niet, en dit komt ook een beetje denk ik door de information overload in de rest van dit topic. Je moet in 'objecten' denken, en bedenken wat een object kan en weet. Zo heb je een user object, en een user object heeft geen enkele weet van de wereld om zich heen. Een user weet alleen iets van zijn eigen kenmerken, dus zijn naam, mailadres, password, etc.

Een database object daarnaast doet database bewerkingen. Die update users in de database, creert nieuwe users, etc.

Als ik jou was zou ik, om te starten, gewoon met 2 classes beginnen. Een User class en een Database class. Doe in die database ook lekker het creeren en authenticaten van users. Normaal gebruik je daar andere classes voor maar dat valt onder het kopje design patterns en dat is nu nog ff wat te veel van het goede.

De User class heeft dus:
set/getName()
set/getEmail()
set/getPassword()

De Database class heeft dan
createUser(user)
getUser(id)
updateUser(user)
authenticateUser(user)

etc.
EDIT: Nog even over de libary in het begin van het topic, waarom moet ik die gebruiken, en mag ik het niet doen zoals het hier staat: http://weebtutorials.com/...-using-singleton-pattern/ ? Enkel en alleen omdat con geen eigenschap van de class is?
Het was m.i. gewoon een dom antwoord op een vraag die je niet gesteld hebt. Een ORM library maakt het voor jou makkelijk om classes (bijvoorbeeld users) op databasetabellen te mappen. Zo'n library handelt een hoop van de code voor je af, zodat je niet zelf al die insert/update statements aan het doen bent.

Alleen is het gebruik van zo'n library compleet een no-go als je OOP nog niet onder de knie hebt. Jij bent met de basiszaken bezig en dat is helemaal prima.

[ Voor 27% gewijzigd door Hydra op 09-07-2012 14:00 ]

https://niels.nu


Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 23:05
Hydra schreef op maandag 09 juli 2012 @ 13:49:
IMHO niet, en dit komt ook een beetje denk ik door de information overload in de rest van dit topic. Je moet in 'objecten' denken, en bedenken wat een object kan en weet. Zo heb je een user object, en een user object heeft geen enkele weet van de wereld om zich heen. Een user weet alleen iets van zijn eigen kenmerken, dus zijn naam, mailadres, password, etc.

Een database object daarnaast doet database bewerkingen. Die update users in de database, creert nieuwe users, etc.

Als ik jou was zou ik, om te starten, gewoon met 2 classes beginnen. Een User class en een Database class. Doe in die database ook lekker het creeren en authenticaten van users. Normaal gebruik je daar andere classes voor maar dat valt onder het kopje design patterns en dat is nu nog ff wat te veel van het goede.

De User class heeft dus:
set/getName()
set/getEmail()
set/getPassword()

De Database class heeft dan
createUser(user)
getUser(id)
updateUser(user)
authenticateUser(user)

etc.
Ik zou er toch voor kiezen om authenticatie desnoods als enige functie in een aparte class te zetten. Later zou je dan makkelijk via een adapter class (zie mijn boek suggestie) de authenticatie kunnen uitbreiden en/of vervangen door een andere (multi) functionele(re) class. Dan ben je toch van je afhankelijkheid van je database class af als het gaat om authenticatie.

Mijn user class wordt op een soort gelijke manier opgebouwd en zal daardoor al op zichzelf als authenticatie kunnen dienen. Hypothetisch voorbeeld:

PHP:
1
2
3
4
$user->setName('CurlyMo');
$user->setPassword('test');
if($user->retrieve())
     $id = $user->getUserId();

Op dit moment zal het user object zoeken naar een gebruiker die voldoet aan de naam 'CurlyMo' én het wachtwoord 'test'. Als deze user bestaat dan zal $user->retrieve() aangeven dat het ophalen van die gebruiker gelukt is en wordt het object gevuld met de data van die betreffende user. Als deze gebruikersnaam en wachtwoord combinatie niet bestaat dan zal het object ook geen gebruiker kunnen ophalen.

PHP:
1
2
3
$user->setName('CurlyMo');
if($user->retrieve())
     $id = $user->getUserId();

Nu zal het user object alleen kijken naar een gebruiker met de naam 'CurlyMo'. Als deze in de database voorkomt dan haalt die deze op zonder te rekening te houden met het wachtwoord.

PHP:
1
2
3
$user->setAge(27);
while($user->retrieve())
     $id = $user->getUserId();


Nu zal er alleen gekeken worden naar de leeftijd. Aangezien de kans bestaat dat er meer users zijn die 27 zijn, kan je door de resultaten heen lopen. Dat is wat geavanceerder qua scripting maar het idee is denk ik wel duidelijk.

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • Webgnome
  • Registratie: Maart 2001
  • Laatst online: 19:32
CurlyMo schreef op maandag 09 juli 2012 @ 14:11:
[...]

Ik zou er toch voor kiezen om..
en daar gaat het fout.. De TS is nameljik nog maar een beginner. IMHO snapt hij/zij nog niet zo veel van OOP om dan meteen al aan te komen zetten met een user class, een authenticatieclass een adapter class etc etc.. Is veel te veel informatie.

Strava | AP | IP | AW


Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 23:05
Webgnome schreef op maandag 09 juli 2012 @ 14:41:
[...]


en daar gaat het fout.. De TS is nameljik nog maar een beginner. IMHO snapt hij/zij nog niet zo veel van OOP om dan meteen al aan te komen zetten met een user class, een authenticatieclass een adapter class etc etc.. Is veel te veel informatie.http://gathering.tweakers.net/forum/quote_message/38554949/last
Dat snap ik, maar als je beginner bent moet je geen verkeerde dingen gaan aanleren. Die adapter class hoeft hij zich nu niet druk om te maken.

Om het voorbeeld te volgen, zou ik het zo doen:

De User class heeft dus:
set/getName()
set/getEmail()
set/getPassword()

De Database class heeft dan
createUser(user)
getUser(id)
updateUser(user)

De Authenticatie class heeft dan:
authenticateUser(user)

Later als hij de Authenticatie wilt vervangen kan hij terug denken aan dit topic en denken: owja adapter class :)

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Bedankt voor de antwoorden, ik had het deze middag druk, dus ik kan nu pas antwoorden.
Ik ben nu de pure basis van de code (functies, klassen en property's) aan het maken in eclipse. Ik heb nog wel een vraagje, het is toch de bedoeling dat ik de klassen aanstuur vanuit een controller, zoals hierboven staat. Dus als ik een gebruiker wil aanmaken, ik in de controller, een nieuwe user klas aanmaak, hier data in zet via setters, en dan ook een nieuwe database klass aanmaak die op zijn beurt date in de database zet.

Even denken: één object is goed voor één ding te doen en één object weet enkel en alleen dingen over zichzelf. Dus eigenlijk moet de database class, enkel informatie over de database (connectie) weten? Maar die moet natuurlijk ook weten wat ie in de database moet zetten, ik vermoed dat de andere informatie (zoals username) dan in bv. de creatUser functie wordt gezet door hier parameters aan mee te geven?

Ik hoop dat ik al in de goede richting begin te geraken?

Alvast bedankt!

Acties:
  • 0 Henk 'm!

  • ID-College
  • Registratie: November 2003
  • Laatst online: 21:01
Ik denk dat de users je hier veel te veel in-depth informatie hebben gegeven over OOP. Kijk eens naar wat simpele OOP voorbeelden en denk niet meteen in controllers en andere additionele klassen die het OOP concept beter maken. Het is handiger om eerst wat te oefenen met wat klassen die je kunt gebruiken om de basis wat door te krijgen. Daarna kun je gaan uitwerken hoe dit beter kan. Het is daarom beter om eerst heel je database klasse weg te houden en met simpele objectjes te beginnen.

Pak bijvoorbeeld je onderwijssysteem als je student bent. Je hebt een klasse school, klasse leerlingen, klasse leraren, misschien type leerlingen (een student kan b.v. ook een leraar zijn) en kijk of je dit kunt omzetten in objecten en attributen die bij het object horen. Breid dit uit en zo bouw je iets mooi op. Dit is een goede oefening voor jezelf..

Mocht je toch willen klooien met databases direct (wat ik je afraad) kijk dan eens - zoals ik al zei - naar het singleton pattern. Dit is een mooie uitleg en je kan de connectie zo opvragen met 1 regel code overal in je script ;) De allerlaatste reactie op de eerste pagina is daar een mooi voorbeeld van.. Ipv mysqli kun je b.v. PDO gebruiken..

[ Voor 4% gewijzigd door ID-College op 10-07-2012 00:22 ]


Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 23:05
LEDfan schreef op maandag 09 juli 2012 @ 22:31:
Bedankt voor de antwoorden, ik had het deze middag druk, dus ik kan nu pas antwoorden.
Ik ben nu de pure basis van de code (functies, klassen en property's) aan het maken in eclipse. Ik heb nog wel een vraagje, het is toch de bedoeling dat ik de klassen aanstuur vanuit een controller, zoals hierboven staat. Dus als ik een gebruiker wil aanmaken, ik in de controller, een nieuwe user klas aanmaak, hier data in zet via setters, en dan ook een nieuwe database klass aanmaak die op zijn beurt date in de database zet.

Even denken: één object is goed voor één ding te doen en één object weet enkel en alleen dingen over zichzelf. Dus eigenlijk moet de database class, enkel informatie over de database (connectie) weten? Maar die moet natuurlijk ook weten wat ie in de database moet zetten, ik vermoed dat de andere informatie (zoals username) dan in bv. de creatUser functie wordt gezet door hier parameters aan mee te geven?

Ik hoop dat ik al in de goede richting begin te geraken?

Alvast bedankt!
Met betrekking tot het ophalen van meerdere users kijk ik eerst hoeveel rijen mijn query oplevert. Vervolgens vraag ik van die query specifiek bepaalde rijen op. Dus stel er zijn 3 gebruikers van 27 jaar. Dan vraag ik eerst rij 1 op, dan rij 2 en als laatst rij 3. Zo wordt mijn user object achtereenvolgens gevuld met verschillende gebruikers. Hierdoor wordt er per gebruiker met de database gecommuniceerd. Dat kan je natuurlijk wel weer opvangen door caching en proxy's (wat nog weer een stap dieper is 8)). Dan zou er zo uit kunnen zien:

code:
1
2
3
while($user->retrieve()) {
    echo $user->getName();
}


In je classen kan je bijhouden op welke rij je zit en welke rijen er nog opgehaald kunnen worden.

En zoals eerder gezegd. Speel ermee. Wanneer je het gaat proberen te schrijven, loop je vanzelf tegen dingen aan die je weer tot nadenken zetten. Dus begin zoals iedereen je aanraadt met hele simpele OOP met desnoods een enkele class.

[ Voor 29% gewijzigd door CurlyMo op 10-07-2012 13:14 ]

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • Hydra
  • Registratie: September 2000
  • Laatst online: 21-08 17:09
CurlyMo schreef op maandag 09 juli 2012 @ 14:11:
Ik zou er toch voor kiezen om authenticatie desnoods als enige functie in een aparte class te zetten.
Nee, authenticatie in een class zetten klopt sowieso niet. Je zou het via een provider design pattern doen. Maar omdat hij een beginner is, kan het aangezien hij waarschijnlijk weinig meer doet dan kijken of een MD5 hash van een PW overeenkomt met dat in een DB, dat net zo goed in de database class doen.
CurlyMo schreef op dinsdag 10 juli 2012 @ 02:23:
De data van een user gaat in een user object. Dit object kan altijd maar één user per keer bevatten. Het user object communiceert met de database via een business object. Dit is een laag tussen de database class en je entiteiten (zoals user). In het business object worden je sql opgenomen die zorgt dat je data in de database komt te staan. Je database class zorgt puur en alleen voor de uitvoer van je sql.
SQL in je business layer? Ben je gek? Dat zit in je DAL. Sorry hoor maar je zit hem nu gewoon verkeerde informatie te voeren.
LEDfan schreef op maandag 09 juli 2012 @ 22:31:
Bedankt voor de antwoorden, ik had het deze middag druk, dus ik kan nu pas antwoorden.
Ik ben nu de pure basis van de code (functies, klassen en property's) aan het maken in eclipse. Ik heb nog wel een vraagje, het is toch de bedoeling dat ik de klassen aanstuur vanuit een controller, zoals hierboven staat. Dus als ik een gebruiker wil aanmaken, ik in de controller, een nieuwe user klas aanmaak, hier data in zet via setters, en dan ook een nieuwe database klass aanmaak die op zijn beurt date in de database zet.
Het is nergens voor nodig een aparte 'controller' te hebben waarin je nieuwe users aanmaakt. Maak gewoon een user object aan, en 'set' dan de waarden. Hou het gewoon lekker simpel, helemaal voor een hobby project waar je jezelf OO aan het leren bent.
Even denken: één object is goed voor één ding te doen en één object weet enkel en alleen dingen over zichzelf. Dus eigenlijk moet de database class, enkel informatie over de database (connectie) weten? Maar die moet natuurlijk ook weten wat ie in de database moet zetten, ik vermoed dat de andere informatie (zoals username) dan in bv. de creatUser functie wordt gezet door hier parameters aan mee te geven?
Een class weet en kent alleen de dingen waarvoor hij verantwoordelijk is. Als jouw Database class verantwoordelijk is voor het inserten en updaten van users moet 'ie natuurlijk weten hoe hij dat moet doen. In een dergelijk simpel project is het prima als je Database class gewoon je Data Access Layer is.
Ik hoop dat ik al in de goede richting begin te geraken?
Absoluut :) Maar hou je aan de basis van elk ((hobby)programmeer)project: KISS

[ Voor 81% gewijzigd door Hydra op 10-07-2012 10:54 ]

https://niels.nu


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Bedankt voor de reacties. Ik denk dat ik dat rond dat onderwijsvorm wel wat code kan maken, zonder database, en die database dan later toevoegen. Maar ik denk dat ik beter geen echte code kan maken maar eerder het principe.

EDIT: Dat heb ik nu gedaan, ik heb 3 classen, school, studente, onderwijzers, elk met hun propertys en hun getters en setters. Ik heb wel wat van opgestoken, en ik denk dat het beste is dat ik nu even bedenk hoe ik hier een database aan kan koppellen.

[ Voor 36% gewijzigd door LEDfan op 10-07-2012 12:39 ]


Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 23:05
Hydra schreef op dinsdag 10 juli 2012 @ 10:45:
SQL in je business layer? Ben je gek? Dat zit in je DAL. Sorry hoor maar je zit hem nu gewoon verkeerde informatie te voeren.
Yep, mijn fout :o Heb dat stuk even weggehaald. Idealiter heb je gelijk, maar in een versimpelde vorm zou je ervoor kunnen kiezen om je SQL statements in je business layer te zetten. En aangezien we hier te maken hebben met een TS die een simpele vorm van OOP probeert te implementeren...:

http://onlamp.com/pub/a/p...5/dataobjects.html?page=2

[ Voor 41% gewijzigd door CurlyMo op 10-07-2012 13:18 ]

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 10:03

Creepy

Tactical Espionage Splatterer

CurlyMo schreef op dinsdag 10 juli 2012 @ 13:03:
[...]

Yep, mijn fout :o Heb dat stuk even weggehaald. Idealiter heb je gelijk, maar in een versimpelde vorm zou je ervoor kunnen kiezen om je SQL statements in je business layer te zetten. En aangezien we hier te maken hebben met een TS die een simpele vorm van OOP probeert te implementeren...:

http://onlamp.com/pub/a/p...5/dataobjects.html?page=2
Je bent daar je eigen DAL aan het schrijven, er zit verder geen enkele business logica in. Om nu maar te adviseren dit samen te voegen is niet handig, ook niet voor een "simpele" vorm van OOP. Vroeg of laat wordt het project groter en zit de TS in de problemen omdat het niet goed gescheiden is.....

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


Acties:
  • 0 Henk 'm!

  • Hydra
  • Registratie: September 2000
  • Laatst online: 21-08 17:09
CurlyMo schreef op dinsdag 10 juli 2012 @ 13:03:
Yep, mijn fout :o Heb dat stuk even weggehaald. Idealiter heb je gelijk, maar in een versimpelde vorm zou je ervoor kunnen kiezen om je SQL statements in je business layer te zetten. En aangezien we hier te maken hebben met een TS die een simpele vorm van OOP probeert te implementeren...:

http://onlamp.com/pub/a/p...5/dataobjects.html?page=2
Oh leuk, weer een site met een PHP tutorial van iemand die de klok heeft horen luiden. Die tutorial is gewoon bizar slecht en leert mensen de verkeerde dingen aan. Zoals zoveel PHP sites/tutorials. Volgens die site gaat dus elk 'object' zijn eigen CRUD logica hebben, zonder zelfs maar de database te abstraheren? WTF? De schrijver hiervan snapt ook nog eens het "DatabObject" pattern niet.

Sowieso, ELKE tutorial die geen PDO gebruikt is of outdated of gewoon rotzooi.

En nee, je zet in een simpele vorm NOOIT je SQL statements in je business layer. Dan zit je in ELK object database access code te kloppen terwijl dat lijnrecht ingaat van de basisprinciepes van OO: een object kent alleen de dingen waarvoor hij verantwoordelijk is. Een "Fiets" of "Auto" object is verantwoordelijk voor "rijVooruit()", nooit voor "haalMijnGegevensOpBijHetRdw()".

In het meest simpele project waar persistentie noodzakelijk is, is er een presentatielaag, een business laag en een datalaag. Business objects als "User","Forum" en "Topic" hebben nooit zelf kennis van hoe ze opgeslagen zijn. Dat zit altijd in de datalaag. En in het geval van de TS is de datalaag gewoon een "Database" class die verantwoordelijk is voor zowel de database interface als voor de scaffolding tussen Business objects en de database tabellen.

https://niels.nu


Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 23:05
Hydra schreef op woensdag 11 juli 2012 @ 10:32:
Volgens die site gaat dus elk 'object' zijn eigen CRUD logica hebben, zonder zelfs maar de database te abstraheren? WTF?
Als je dat wilt, dan zul je gewoon een ORM moeten gaan gebruiken (zoals Doctrine, Redbean). Elke vorm van geschreven SQL loopt het risico op database afhankelijkheid.

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • Webgnome
  • Registratie: Maart 2001
  • Laatst online: 19:32
CurlyMo schreef op woensdag 11 juli 2012 @ 11:00:
[...]

Als je dat wilt, dan zul je gewoon een ORM moeten gaan gebruiken (zoals Doctrine, Redbean). Elke vorm van geschreven SQL loopt het risico op database afhankelijkheid.
Ik denk dat er eerder gewezen wordt dat elk object zijn eigen crud gaat zitten regelen. Wat IMHO niet nodig zou moeten zijn. Daar hebben we toch controllers oid voor?

Strava | AP | IP | AW


Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 23:05
Webgnome schreef op woensdag 11 juli 2012 @ 11:04:
[...]


Ik denk dat er eerder gewezen wordt dat elk object zijn eigen crud gaat zitten regelen. Wat IMHO niet nodig zou moeten zijn. Daar hebben we toch controllers oid voor?
Dan las ik het verkeerd.

Ik merk na het lezen en reageren op dit topic dat ik zelf dus blijkbaar ook nog wat vragen blijk te hebben over OOP. Naar mijn idee regelde de controller de communicatie tussen de presentatielaag en de datalaag. Zou iemand in een goed overzicht de volgende designs/principes kunnen toelichten en aanvullen, en in welke gedeelte we dan zitten qua presentatie-, business- en datalaag. Graag vanuit de meest ideale situatie :) en als voorbeeld kunnen we misschien de login van de TS gebruiken.

Business Object
Controller
View & Template
Model
DAL (en zijn componenten), ORM
enz.

[ Voor 48% gewijzigd door CurlyMo op 11-07-2012 11:51 ]

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • pedorus
  • Registratie: Januari 2008
  • Niet online
Hydra schreef op woensdag 11 juli 2012 @ 10:32:
Die tutorial is gewoon bizar slecht en leert mensen de verkeerde dingen aan. Zoals zoveel PHP sites/tutorials.
Doet me denken aan de rant PHP: a fractal of bad design. :p Goed om eens door te lezen, het gaat bijvoorbeeld over het vergelijken van een wachtwoordhash met "==" (regel 23).
ID-College schreef op zondag 08 juli 2012 @ 15:53:
Kijk eens naar het singleton pattern voor PHP..
Sommigen zouden dat niet aanraden, zie bijv. Singletons in PHP - Why they are bad and how you can eliminate them from your applications. ;)

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten


Acties:
  • 0 Henk 'm!

  • .oisyn
  • Registratie: September 2000
  • Laatst online: 15:22

.oisyn

Moderator Devschuur®

Demotivational Speaker

pedorus schreef op woensdag 11 juli 2012 @ 12:16:
Doet me denken aan de rant PHP: a fractal of bad design. :p Goed om eens door te lezen, het gaat bijvoorbeeld over het vergelijken van een wachtwoordhash met "==" (regel 23).
Wow nice one. Deze had ik mij zelf nog niet eens gerealiseerd (ik wist overigens ook niet dat PHP types ging coercen als beide operanden gewoon strings waren). What - the - fuck.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Acties:
  • 0 Henk 'm!

  • Hydra
  • Registratie: September 2000
  • Laatst online: 21-08 17:09
.oisyn schreef op woensdag 11 juli 2012 @ 12:31:
Wow nice one. Deze had ik mij zelf nog niet eens gerealiseerd (ik wist overigens ook niet dat PHP types ging coercen als beide operanden gewoon strings waren). What - the - fuck.
Ik heb die een tijdje terug al gelezen. Ik snap ook niet zo goed dat zoveel mensen nog met PHP beginnen. Je schiet er niks mee op en er zijn genoeg hosts die bijvoorbeeld .Net of Ruby ondersteunen. PHP zuigt harige ballen, klaar.

Die '==' fout heb ik ook ooit een keer gemaakt. Als je vanuit een Java achtergrond komt en dan PHP gaat doen loop je tegen enorm irritante fouten aan. En ja, dat is IMHO gewoon een grove fout in het platform.
Volgens mij was ik aardig duidelijk, maargoed. Bottomline: die tutorial zuigt.
Ik merk na het lezen en reageren op dit topic dat ik zelf dus blijkbaar ook nog wat vragen blijk te hebben over OOP. Naar mijn idee regelde de controller de communicatie tussen de presentatielaag en de datalaag. Zou iemand in een goed overzicht de volgende designs/principes kunnen toelichten en aanvullen, en in welke gedeelte we dan zitten qua presentatie-, business- en datalaag. Graag vanuit de meest ideale situatie :) en als voorbeeld kunnen we misschien de login van de TS gebruiken.

Business Object
Controller
View & Template
Model
DAL (en zijn componenten), ORM
enz.
Ik snap de vraag niet zo goed. MVC en applicatielagen hebben op zich weinig met elkaar te maken. Je kunt niet zomaar stellen dat het controller deel altijd in laag X zit, en het model altijd in laag Y. Het MVC model is vooral bedoeld om te voorkomen dat een GUI in spagetticode veranderd omdat iedere control zelf ergens iets zit aan te passen. Het hele MVC verhaal leeft over het algemeen 'bovenop' de businesslaag maar bepaalde aspecten zullen ook kennis moeten hebben van het persisten van objecten.

Dit zijn ook geen natuurwetten. Niet iedere applicatie werkt hetzelfde en voor een simpele webservice heb je geen MVC gebeuren.

[ Voor 50% gewijzigd door Hydra op 11-07-2012 12:55 ]

https://niels.nu


Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 23:05
Zover ik hetgeen had begrepen (en waarschijnlijk heb ik het dus verkeerd geleerd) zorgt een controller voor de communicatie tussen de objects zoals users en de views, maar blijkbaar zorgen controllers juist voor de CRUD. Mijn vraag is dus: welke naam gebruiken we voor welke functie in de gehele MVC structuur.

Een business object zorgt voor .... en communiceert doorgaans met ... en ....

Zoiets, en dat dan voor de verschillende belangrijke designs binnen de hier besproken OOP manier van werken.

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • TheNephilim
  • Registratie: September 2005
  • Laatst online: 14:37

TheNephilim

Wtfuzzle

Hydra schreef op woensdag 11 juli 2012 @ 12:48:
Ik heb die een tijdje terug al gelezen. Ik snap ook niet zo goed dat zoveel mensen nog met PHP beginnen. Je schiet er niks mee op en er zijn genoeg hosts die bijvoorbeeld .Net of Ruby ondersteunen. PHP zuigt harige ballen, klaar.
Ruby leek me erg leuk en ben daar ook eens mee bezig geweest. Alleen het opzetten van een simpel iets is gewoon te veel werk (in Windows). PHP is juist makkelijk instappen, dan wel met het gevaar dat je ook onderaan de ladder blijft werken (zoals ik).

Python leek me ook nog wel grappig, verder niet naar gekeken.

Ben nog naarstig op zoek naar een framework om dingen mee te gaan ontwikkelen. Wil eigenlijk beginnen met Symfony2, maar kom er niet helemaal uit.

Misschien is Ruby on Rails een leuk idee, maar zoals ik al aangaf, is het zo veel geklooi en bij elkaar rapen van dingen voor je wat kunt. Dan ben ik het overzicht kwijt en kan ik er met m'n simpele brein niet meer omheen.

Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Ik heb het onderwijssysteem wel een beedje uitgewerkt, en ook wat uitgeleerd, maar ik denk dat ik dit beter met mijn rechten systeem doe, omdat ik dan ook gelijk een inlog systeem heb, en dit zeer hard te vergelijken is met het onderwijssysteem (verschillende gebruikers met verschillende rechten).

Ik heb het inlog systeem zelf eens wat verder uitgewerkt, zonder een database koppeling daarvoor ga ik de link hierboven gebruiken.

Dit is het login formulier:
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
if (isset($_POST['submit']))
{
    require_once("classes/user.php");
    $user = new user;
    $user->setUserName($_POST['username']);
    $user->setPassword($_POST['password']);
    
    echo $user->getUsername();
    echo $user->getPassword();
    echo '<pre>';
    var_dump($user->getErrorData());
    echo '</pre>';
    $user->createUser();
}
?>
<form method="post" action="<?php echo $_SERVER["PHP_SELF"]; ?>">
    <input class="input" type="text" placeholder="username" name="username" value="" />
    <input class="input" type="password" placeholder="password" name="password"   /> 
     <input type="submit" name="submit" value="Login"><br>
</form>


Ik heb de html code wat gestript omdat je deze niet nodig hebt.

En dan de user class:
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
class user 
{
    private $firstname;
    private $lastname;
    private $email;
    private $username;
    private $password;
    private $error;
    
    function __construct()
    {
        $this->error = array();
    }
    
    public function setUserName($username)
    {
        if (empty($username))
        {
            array_push($this->error, 'userNameEmpty');
        }
        elseif (strpos($username, ' ') !== false)
        {
            array_push($this->error, 'userNameSpaces');
        }
        elseif (strlen($username) < 3 and strlen($username) > 10)
        {
            array_push($this->error, 'userNameLength');
        }
        else 
        {
            $this->username = $username;
        }
    }
    
    public function setPassword($password)
    {
        if (empty($password))
        {
            array_push($this->error, 'passwordEmpty');
        }
        elseif (strpos($password, ' ') !== false)
        {
            array_push($this->error, 'passwordSpaces');
        }
        elseif (strlen($password) < 8)
        {
            array_push($this->error, 'passwordLength');
        }
        else 
        {
            $this->password = $password;
        }
    }

    public function getUsername()
    {
        return $this->username;
    }

    public function getPassword()
    {
        return $this->password;
    }
    
    public function getErrorData()
    {
        return $this->error;
    }
}


Ik had voor elke property een geter en setter gemaakt, maar eclipse heeft de inhoud van dat bestand verwijderd.

Nu zou ik graag de verbinding met de database maken, ik denk dat ik gewoon een database class ga maken met ongeveer dezelfde property's. In de user class een functie creatuser maken, die dan via setters de property's in de database class zet. In de database class dan een functie maken, en die dan aanroepen via de user class, die niets anders doet dan inserten in de DB. Daarvoor gebruik ik dan de link van hierboven.

Zou dit degelijk gaan werken, én dan nog eens mooi OOP geschreven.

Ik ga nu aan de error afhandeling beginnen.

Acties:
  • 0 Henk 'm!

  • MueR
  • Registratie: Januari 2004
  • Laatst online: 23:04

MueR

Admin Tweakers Discord

is niet lief

Een getPassword functie zou je niet eens nodig moeten hebben. Die hoort namelijk, als hij er al in zit, alleen een hash terug te geven ;)

Anyone who gets in between me and my morning coffee should be insecure.


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Natuurlijk even niet aan gedacht. Maar als ik het zou verder zou uitwerken, is het dan goed gemaakt/OOP? (Natuurlijk ga ik nog verder gaan in OOP, en meer verschillende soorten classen werken)

Acties:
  • 0 Henk 'm!

  • Bv202
  • Registratie: Oktober 2006
  • Laatst online: 14-11-2021
Tip: Lees het boek "Head First Design Patterns". DIt boek zal je al een pak vooruit helpen met deze dingen :)

Overigens vind ik PHP niet de geschikte taal om OOP aan te leren. Maar goed, da's een discussie op zich :p

Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 23:05
Bv202 schreef op donderdag 12 juli 2012 @ 19:35:
Tip: Lees het boek "Head First Design Patterns". DIt boek zal je al een pak vooruit helpen met deze dingen :)

Overigens vind ik PHP niet de geschikte taal om OOP aan te leren. Maar goed, da's een discussie op zich :p
CurlyMo schreef op zondag 08 juli 2012 @ 22:50:
[...]

Wat ik zelf een prettig boek vond om verschillende design patterns te leren kennen: Head First Design Patterns. Het legt aan allerlei simpele voorbeelden uit hoe de meest gebruikte patterns je (programmeer) leven makkelijker kunnen maken.
:)

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Ik moet me eerst door een ander boek wurmen. Dit: http://www.bol.com/nl/p/b...nd-mysql/1001004010305030 . Maar kan ik met deze structuur beginnen en dan later verder uitwerken?

Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Hi hier ben ik weer, ik ga zo snel mogelijk het boek dat ik nu heb uitlezen, en dan het boek over OOP dat hier geadviseerd wordt lezen, en natuurlijk toepassen.

Ondertussen heb ik met mijn beperkte kennis van OOP al een deeltje van het script afgewerkt. Namelijk het deel om in te loggen.

Dit is de index.php, dit is het formulier en de verwerking van het formulier. ik heb de overige HTML tags er weer uit gestript.
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php 
if (isset($_POST['submit']))
{
    require_once("classes/user.php");
    $user = new user;
    $user->setUserName($_POST['username']);
    $user->setPassword($_POST['password']);
    if (count($user->getErrordata()) == 0)
    {
        $user->loginUser();
    }
    echo $user->getErrorData();
}
?>
<form method="post" action="<?php echo $_SERVER["PHP_SELF"]; ?>">
    <input class="input" type="text" placeholder="username" name="username" value="" />
    <input class="input" type="password" placeholder="password" name="password"   /> 
    <input type="submit" name="submit" value="Login"><br>
</form>
    


Dit is de user class: (Het is de bedoeling dat hier het login zelf gebeurt, en uit loggen, deze class is dus goed in het autentificeren van gebruikers).
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
<?php 
class user 
{
    private $firstname;
    private $lastname;
    private $email;
    private $username;
    private $password;
    private $passwordDatabase;
    private $passwordCrypt;
    private $pepperDatabase;
    private $error;
    private $salt;
    private $safe;
    
    function __construct()
    {
        $this->error = array();
        $this->salt = 'R4185u4488J388n';
        $this->safe = 'test.php';
        
    }
    
    public function setUserName($username)
    {
        if (empty($username))
        {
            array_push($this->error, 'userNameEmpty');
        }
        elseif (strpos($username, ' ') !== false)
        {
            array_push($this->error, 'userNameSpaces');
        }
        elseif (strlen($username) < 3 and strlen($username) > 10)
        {
            array_push($this->error, 'userNameLength');
        }
        else 
        {
            $this->username = $username;
        }
    }
    
    public function setPassword($password)
    {
        if (empty($password))
        {
            array_push($this->error, 'passwordEmpty');
        }
        elseif (strpos($password, ' ') !== false)
        {
            array_push($this->error, 'passwordSpaces');
        }
        elseif (strlen($password) < 8)
        {
            array_push($this->error, 'passwordLength');
        }
        else 
        {
            $this->password = $password;
        }
    }

    public function getUsername()
    {
        return $this->username;
    }

    
    public function getErrorData()
    {
        return $this->error;
    }
    
    public function loginUser()
    {
        require("database.php");
        $database = new database;
        $database->setUsername($this->username);
        $this->passwordDatabase =  $database->getPassworDatabase();
        $this->pepperDatabase =  $database->getPepperDatabase();
        if ($this->checkPassword())
        {
            $database->setUserDataDatabase();
            $this->firstname = $database->getFirstname();
            $this->lastname = $database->getLastname();
            $this->email = $database->getEmail();
            $this->startSession();
            $this->makeSession();
            header('location: ' . $this->safe. '');
        }
    }
    private function checkPassword()
    {
        $this->passwordCrypt =  crypt($this->password, '$5$' . $this->salt . $this->pepperDatabase);
        if (trim($this->passwordDatabase) == trim($this->passwordCrypt) )
        {
            // The passwor in the field is equal to the password in the database
            return true;
        }
        else 
        {
            array_push($error, 'passwordWrong');
        }
    }
    
    private function startSession()
    {
        if (!isset($_SESSION))
        {
            session_start();
        }
    }
    
    private function makeSession()
    {
        $_SESSION['username'] = $this->username;
        $_SESSION['firstname'] = $this->firstname;
        $_SESSION['lastname'] = $this->lastname;
        $_SESSION['email'] = $this->email;
    }
}
?>


De code in de contstruct ga ik nog vervangen door constanten die in een apart configuratie bestand zijn opgenomen.

En de database class:
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
<?php
class database
{
    private $passworDatabase;
    private $username;
    
    public function __construct()
    {
        require_once("config.php");
    }
    
    public function setUsername($username)
    {
        // No validatin need, this function will only be called if the username is valid.
        $this->username = $username;
    }
    
    public function getPassworDatabase()
    {
        $connection = DataBaseConnection::getInstance();//getting the instance forom of the class DataBaseConnection
        $sql = "SELECT password FROM users WHERE username=?";
        $q = $connection->getPDO()->prepare($sql);
        $q->execute(array($this->username));
        $row = $q->fetch();
        return $row['password'];
    }
    
    public function getPepperDatabase()
    {
        $connection = DataBaseConnection::getInstance();//getting the instance forom of the class DataBaseConnection
        $sql = "SELECT pepper FROM users WHERE username=?";
        $q = $connection->getPDO()->prepare($sql);
        $q->execute(array($this->username));
        $row = $q->fetch();
        return $row['pepper'];
    }
    
    public function setUserDataDatabase()
    {
        $connection = DataBaseConnection::getInstance();//getting the instance forom of the class DataBaseConnection
        $sql = "SELECT firstname, lastname, email FROM users WHERE username=?";
        $q = $connection->getPDO()->prepare($sql);
        $q->execute(array($this->username));
        $row = $q->fetch();
        echo '<pre>';
        var_dump($row);
        echo '</pre>';
        $this->firstname = $row['firstname'];
        $this->lastname = $row['lastname'];
        $this->email = $row['email'];
    }
    
    public function getFirstname()
    {
        return $this->firstname;
    }

    public function getLastname()
    {
        return $this->lastname;
    }
    
    public function getEmail()
    {
        return $this->email;
    }


}


Deze class doet dus alle afhandelingen met de database, en dat is ook alles.

Ik heb nog enkele vragen die mij verwarren, in de user class moet ik (tijdelijk) verschillende paswoorden opslaan. Per tijdelijk passwoord heb ik nu een property aangemaakt.

Ik heb de functies die van buitenaf benaderd worden een public scoop meegegeven, en de gene die ik enkel in de class zelf gebruikt private. Is dit de normale gang van zaken?

Ik ga nu de links over de database connecties lezen, want nu maak ik elke keer opnieuw een verbinding, maar ik wilde klein beginnen.

De error afhandeling ga ik ook nog maken, maar eclipse vond het leuk om de user class leeg te maken. :( , dus dan heb ik dat maar eerst opnieuw herschreven. (Ondertussen back-up ik de code regelmatig)

P.s. in de quickstart stond iets, dat GoT geen code nakijk forum was, maar omdat ik toch nog met enkele vragen zit, heb ik de code voor de duidelijkheid hier in dit topic gepost,

Ik hoop dat ik ondertussen in objecten begin te denken, maar ik ga zo snel mogelijk dat boek kopen en lezen.

EDIT: zoals gezegd heb ik naar Singleton pattern gekeken, en de code daarop aangepast.

En dan de config.php:
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
<?php
<?php
 class DataBaseConnection {
    static private $instance = NULL;
    private $PDO;
    private function __construct() {
        $this->PDO= new PDO('mysql:host=localhost;dbname=login', 'root', 'h4crUDru');
        
    }
    static public function getInstance() {
       if (self::$instance == NULL) self::$instance = new self;
       return self::$instance;
    }
    public function __clone()
    {
        trigger_error('Clone is not allowed.', E_USER_ERROR);
    }
    public function getPDO(){
        return $this->PDO;
    }
}


?>

[ Voor 27% gewijzigd door LEDfan op 17-07-2012 12:12 ]


Acties:
  • 0 Henk 'm!

  • Hydra
  • Registratie: September 2000
  • Laatst online: 21-08 17:09
[b]LEDfan schreef op maandag 16 juli 2012 @ 14:42:
Ik heb nog enkele vragen die mij verwarren, in de user class moet ik (tijdelijk) verschillende paswoorden opslaan. Per tijdelijk passwoord heb ik nu een property aangemaakt.
Ik heb eerder al gezegd dat ik dit soort zaken niet in een User class zou doen en het als een gewoon 'dom' object met getters/setters zou gebruiken. Maargoed, het maakt niet zo veel uit.
Ik heb de functies die van buitenaf benaderd worden een public scoop meegegeven, en de gene die ik enkel in de class zelf gebruikt private. Is dit de normale gang van zaken?
Ja, dat is precies het hele idee. Dat je van buiten niet bij de zaken kunt waar je niks mee te maken hebt :)

https://niels.nu


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Hydra, bedoel je dan eigenlijk een aparte class die niks anders doet dan gegevens opslaan?

Acties:
  • 0 Henk 'm!

  • Webgnome
  • Registratie: Maart 2001
  • Laatst online: 19:32
LEDfan schreef op maandag 16 juli 2012 @ 15:17:
Hydra, bedoel je dan eigenlijk een aparte class die niks anders doet dan gegevens opslaan?
Dat is correct. Je hebt een klasse die verantwoordelijk is voor de representatie van een gebruiker ( = user class) en je hebt een klasse die verantwoordelijk is voor het authenticeren van die gebruiker, een klasse die gegevens van een gebruiker uit de database haalt etc.. etc..

Strava | AP | IP | AW


Acties:
  • 0 Henk 'm!

  • pedorus
  • Registratie: Januari 2008
  • Niet online
Er zitten als ik snel kijk minimaal 2 security-problemen in die code:
  1. PHP_SELF kan XSS veroorzaken
  2. Je gebruikt crypt verkeerd, waardoor je maar 1 karakter van de 16 over hebt die verschillend kan zijn per user. crypt geeft de gebruikte salt ook terug, dus de geheime vaste salt voor het script wordt blijkbaar ook gewoon in de database opgeslagen. Misschien handig om gewoon bcrypt te gebruiken.
  3. Je gebruikt nog steeds == en die trim() kan ik ook niet plaatsen.
Die var_dump snap ik ook niet helemaal, aangezien je met Eclipse ook op een normale manier php kan debuggen. Dus een breakpoint zetten, en kijken wat de waardes zijn.

Wat mij betreft is deze totaaloplossing een beetje overgedesigned, en zou het mooi zijn als er niet per loginpoging 3 queries naar dezelfde databaserij gaan. In die zin was het initiële script eigenlijk overzichtelijker en efficiënter ;)

Overigens hoort een Location:-redirect altijd een volledige url te zijn, niet een relatieve. En getPassworDatabase is geen mooie naam (doet ook denken dat je een database terugkrijgt naast dat Eclipse aan spellingscontrole doet). :p

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten


Acties:
  • 0 Henk 'm!

  • Barryvdh
  • Registratie: Juni 2003
  • Laatst online: 14:10
In plaats van php_self kan je ook geen action meegeven, dan stuurt hij ook naar zichzelf.

Acties:
  • 0 Henk 'm!

  • CurlyMo
  • Registratie: Februari 2011
  • Laatst online: 23:05
Barryvdh schreef op dinsdag 17 juli 2012 @ 09:51:
In plaats van php_self kan je ook geen action meegeven, dan stuurt hij ook naar zichzelf.
Zover ik weet was het zo dat wanneer je geen action meegaf aan een form element, je het formulier niet kan versturen via de [enter] toets. Dat kon dan alleen via een submit knop.

Sinds de 2 dagen regel reageer ik hier niet meer


Acties:
  • 0 Henk 'm!

  • pedorus
  • Registratie: Januari 2008
  • Niet online
Pas sinds HTML5 is het action attribuut niet meer verplicht, daarvoor was het niet-conformant, dus oude ervaringen zijn wat lastig. Is er een browser waar het nu niet in zou werken? :p

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Bedankt voor de antwoorden.
pedorus schreef op maandag 16 juli 2012 @ 22:11:
• PHP_SELF kan XSS veroorzaken
Ik weet dat PHP_SELF niet zo veilig is, het wordt nog in men boek behandelt dus dan zal ik daar in kijken hoe ik het wel moet doen of het action attribuut weglaten.
• Je gebruikt crypt verkeerd, waardoor je maar 1 karakter van de 16 over hebt die verschillend kan zijn per user. crypt geeft de gebruikte salt ook terug, dus de geheime vaste salt voor het script wordt blijkbaar ook gewoon in de database opgeslagen. Misschien handig om gewoon bcrypt te gebruiken.
Ik had niet verwacht dat het niet veilig ging zijn, ik ga het aanpassen met de link die je gegeven hebt.
• Je gebruikt nog steeds == en die trim() kan ik ook niet plaatsen.
[/list]
Waarom mag ik == niet gebruiken? Ik zal de links hier in dit topic zo snel mogelijk lezen.
De trim functie heb ik gebruikt omdat anders de passwoorden niet gelijk waren, als ik dan de hexadecimaale waarden van de passwoorden dumpten dan zat er op het einde een klein verschilletje in. Als ik met trim() werk heb ik hier geen last van.
Die var_dump snap ik ook niet helemaal, aangezien je met Eclipse ook op een normale manier php kan debuggen. Dus een breakpoint zetten, en kijken wat de waardes zijn.
Debuggen doe ik nog altijd handmatig, ik zou eigenlijk de Zend debugger op men server moeten krijgen, maar dat werkt niet. Ik zal me wat inlezen over die breakpoints.
Wat mij betreft is deze totaaloplossing een beetje overgedesigned, en zou het mooi zijn als er niet per loginpoging 3 queries naar dezelfde databaserij gaan. In die zin was het initiële script eigenlijk overzichtelijker en efficiënter ;)
Dat vind ik spijtig, maar ik zie ook dat er van hier naar daar in het script wordt gesprongen. Die 3 queries kunnen inderdaad wel beter. Een setter, moet die zijn waarde altijd vanuit een controller of vanuit een ander class krijgen of mag dat ook van uit de database? Want dan kan ik van die 3 query's 1 query maken die dan de waardes in de class set, en dan met getters uitlezen.
Overigens hoort een Location:-redirect altijd een volledige url te zijn, niet een relatieve. En getPassworDatabase is geen mooie naam (doet ook denken dat je een database terugkrijgt naast dat Eclipse aan spellingscontrole doet). :p
Moet bij die volledige URL dan ook HTTP en de domeinnaam en dergelijke bij staan? Het is de bedoeling dat het script op enkele sites van mij werken, dus dan is dat lastig om dat elke keer aan te passen, ik denk ook niet dat dat de bedoeling is? Soms doet zo'n IDE wel wat te veel werk voor je, maar ik zou niet meer zonder kunnen.


Op diverse script sites en dergelijke vind je de fouten die ik gemaakt heb, wel redelijk veel terug. Dat is eigenlijk wel spijtig.

Ik zie dat ik de config file niet juist heb geplakt, ik zal dit nog aanpassen.

Acties:
  • 0 Henk 'm!

  • Manuel
  • Registratie: Maart 2008
  • Laatst online: 17:22
LEDfan schreef op dinsdag 17 juli 2012 @ 11:11:
Bedankt voor de antwoorden.

[...]
Waarom mag ik == niet gebruiken? Ik zal de links hier in dit topic zo snel mogelijk lezen.
De trim functie heb ik gebruikt omdat anders de passwoorden niet gelijk waren, als ik dan de hexadecimaale waarden van de passwoorden dumpten dan zat er op het einde een klein verschilletje in. Als ik met trim() werk heb ik hier geen last van.
Bron: http://me.veekun.com/blog...-a-fractal-of-bad-design/
== converts to numbers when possible (123 == "123foo"… although "123" != "123foo"), which means it converts to floats when possible. So large hex strings (like, say, password hashes) may occasionally compare true when they’re not. Even JavaScript doesn’t do this.

Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Bedankt! Maar dan moet je === gebruiken? Want dan gaat die alleen true zijn als het allebij een string, integer, floet ... is.

Acties:
  • 0 Henk 'm!

  • Raynman
  • Registratie: Augustus 2004
  • Laatst online: 21:29
LEDfan schreef op dinsdag 17 juli 2012 @ 11:11:
[...]

Moet bij die volledige URL dan ook HTTP en de domeinnaam en dergelijke bij staan?
Ja, anders is-ie niet volledig :? Iets duidelijker zou waarschijnlijk wel zijn om te zeggen dat het een absolute URL moet zijn.
Het is de bedoeling dat het script op enkele sites van mij werken, dus dan is dat lastig om dat elke keer aan te passen, ik denk ook niet dat dat de bedoeling is?
Zet de base URL in een config/define een constante/... en gebruik die in je header.
LEDfan schreef op dinsdag 17 juli 2012 @ 11:23:
Bedankt! Maar dan moet je === gebruiken? Want dan gaat die alleen true zijn als het allebij een string, integer, floet ... is.
Wat bedoel je daarmee? Zie je dat als een probleem? Meestal is dat precies wat je wilt (en wat talen met strictere typing altijd doen). In dit geval met passwords wil je twee strings vergelijken; je zit niet te wachten op allerlei vreemde conversies.

Acties:
  • 0 Henk 'm!

  • Hydra
  • Registratie: September 2000
  • Laatst online: 21-08 17:09
[b]LEDfan schreef op dinsdag 17 juli 2012 @ 11:11:
Dat vind ik spijtig, maar ik zie ook dat er van hier naar daar in het script wordt gesprongen. Die 3 queries kunnen inderdaad wel beter. Een setter, moet die zijn waarde altijd vanuit een controller of vanuit een ander class krijgen of mag dat ook van uit de database? Want dan kan ik van die 3 query's 1 query maken die dan de waardes in de class set, en dan met getters uitlezen.
Ik snap niet waarom je hier zo moeilijk over doet. Je maakt gewoon een authenticate functie in je database class, die voer je een User object waar je daarvoor de username en PW in gezet hebt (dat is gewoon de informatie vanuit je UI, al dan niet opgeschoond. Hoe je dat doet maakt geen klap uit. Die authenticate functie doet gewoon de volgende stappen:

- SELECT de user data uit de DB aan de hand van de unique ID (mailadres neem ik aan)
- Hash het password in het User object
- Vergelijk de nieuwe Hash met die opgeslagen in de DB. Klopt die? Hey presto, de gegevens kloppen dus de user krijgt status 'ingelogd'.

Ik snap niet waarom je zo'n godsgruwelijk omslachtig gebeuren ervan maakt. Het lijkt er ook op trouwens dat de username die mensen inputten als username voor je database gebruikt wordt. Dat is natuurlijk sowieso fout; je gebruikt in de meeste gevallen voor database access hele andere usernames dan voor je websitegebruikers. Bij veel hosters krijg je er sowieso maximaal maar 1.

Getters en setters van een simpel object doen niks anders dan een waarde in een object setten of teruggeven. Van waaruit die aangeroepen worden doet er helemaal niet toe. setPassword zal waarschijnlijk alleen vanuit je loginform aangeroepen worden, getPassword alleen vanuit de functie die de authenticatie doet, maar getUserName zal waarschijnlijk op veel punten aangeroepen worden. Dat boeit dus niet, het is maar net waar je dat nodig gaat hebben. Dat is dus het hele punt achter OO: dat je een user object hebt als pakketje van alle informatie die een user beschrijft.

Bedenk dus eerst wat je wil, want je bent nu iets compleet aan het overengineeren zonder enig doel. OO is een manier van werken, geen doel. Ga dus gewoon bouwen en dan kunnen wij je wel helpen met vragen over of het wel de beste manier van implementeren is. Als je doel puur het leren OO te programmeren is, is PHP sowieso absoluut niet de beste optie en kun je beter met Java of C# beginnen.

https://niels.nu


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Bedankt voor de reacties. Mijn doel is om PHP zo efficient mogelijk te gebruiken.

Ik gebruik voor de de database toegang, maar één gebruiker. Ik ben momenteel op een virtuele ubuntu server aan het testen. Dus dat is gewoon de root gebruiker.

Het wordt wel duidelijk dat ik dat boek te pakken moet krijgen.

Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Ik denk dat op het moment het beste is dat ik nu, eerst gewoon PHP zonder OOP leer. En dan later dat boek over OOP lezen. En dan OOP pas later in mijn appllicaties verwerk.

Acties:
  • 0 Henk 'm!

  • Caelorum
  • Registratie: April 2005
  • Laatst online: 20:41
LEDfan schreef op zondag 29 juli 2012 @ 10:03:
Ik denk dat op het moment het beste is dat ik nu, eerst gewoon PHP zonder OOP leer. En dan later dat boek over OOP lezen. En dan OOP pas later in mijn appllicaties verwerk.
Doe dat je jezelf niet aan joh! OOP is zeker geen heilige graal, maar IMO is het makkelijker eerst OOP te leren en dan procedureel dan andersom. Ook OOP later verwerken in een bestaand programma is vaak niet te doen. Dan ben je beter af dat meteen te doen (maar wellicht niet vanuit commercieel oogpunt).

Acties:
  • 0 Henk 'm!

  • Waster
  • Registratie: September 2006
  • Laatst online: 14-04 17:49
Caelorum schreef op zondag 29 juli 2012 @ 20:59:
[...]

Doe dat je jezelf niet aan joh! OOP is zeker geen heilige graal, maar IMO is het makkelijker eerst OOP te leren en dan procedureel dan andersom. Ook OOP later verwerken in een bestaand programma is vaak niet te doen. Dan ben je beter af dat meteen te doen (maar wellicht niet vanuit commercieel oogpunt).
Je slaat hier de plank toch wel mis. OOP is een abstractielaag bovenop procedureel programmeren. Als je grote projecten hebt, dan helpt het om het project/programma op te delen in objecten ipv dat je een heel grote bak met functies hebt.

Daarbij komt dat er hele boeken over refactoren zijn geschreven. Dus dat later verwerken niet te doen is klopt ook niet helemaal. Niemand zal in één keer een perfect programma schrijven en er zal hoe dan ook dingen aangepast moeten worden in de loop van een programma. Van daar dat ik mijn opleiding ook dood werd gegooid met agile.

Als je echt OOP wilt leren denk ik ook niet dat php de beste taal is om mee te beginnen. Php is van origine een procedurele taal en dat zie je ook terug in de library wat voor het grootste deel gewoon een bak met functies is. Zelf heb ik OOP geleerd in java en dat is een makkie, want alle voorbeelden, boeken, de Java API zelf is OOP. En anders kan ik je aanraden om een goed php framework te gebruiken. Ik vind codeigniter een mooi framework en ook OOP opgebouwd. Daar kun je ook veel van leren hoe die zijn classes heeft ingedeeld.

Acties:
  • 0 Henk 'm!

  • Caelorum
  • Registratie: April 2005
  • Laatst online: 20:41
Waster schreef op zondag 29 juli 2012 @ 21:48:
[...] Je slaat hier de plank toch wel mis. OOP is een abstractielaag bovenop procedureel programmeren. Als je grote projecten hebt, dan helpt het om het project/programma op te delen in objecten ipv dat je een heel grote bak met functies hebt.
Dat doe ik helemaal niet. Ik weet dondersgoed wat OOP is. Het is ook niet zo zeer dat OOP altijd handiger is bij grotere projecten (maar wel heel vaak). Het maakt het geheel waarschijnlijk wel modulairder en makkelijk te onderhouden (mits goed gedaan dan), maar zoals ik al zei is het niet de heilige graal.
Daarbij komt dat er hele boeken over refactoren zijn geschreven. Dus dat later verwerken niet te doen is klopt ook niet helemaal. [...]
Ik heb nergens gezegd dat het niet te doen is. Alleen vaak. Nu was dat wellicht kort door de bocht gezegd, maar ga jij maar eens een groot project refactoren naar een fatsoenlijk OO ontwerp. Dat is echt ondoenlijk en je bent zeer waarschijnlijk beter af door gewoon het van de grond af aan te ontwerpen en uit te bouwen. Structuur er later in proberen te stoppen is gewoon iets wat je IMO moet proberen te vermijden. Zoals ik al wel had gezegd kan ik me voorstellen dat die vanuit een zakelijk/commercieel oogpunt niet handig is (als je bijv. met deadlines zit), maar anders zou ik toch sterk overwegen wel eerst OO te leren programmeren en dan pas procedureel.
Ik zie zelf ook niet zo veel problemen met leren hoe OOP icm. met PHP werkt. Je kan hem wel mooi java gaan aanraden, maar als hij dan uiteindelijk het project alsnog in PHP gaat maken is die kennis ook niet altijd van toepassing. Juist omdat de implementatie van PHP zo zijn rarigheden heeft. Daarnaast hoeft het feit dat OOP binnen PHP nog alles behalve standaard is je er niet van te weerhouden het wel goed te leren. Het enige wat je dan moet doen is mensen zoeken die het wel kunnen. Iets dat de topicstarter volgens mij ook heeft gedaan door hier zijn vragen te stellen.

Acties:
  • 0 Henk 'm!

  • Waster
  • Registratie: September 2006
  • Laatst online: 14-04 17:49
Caelorum schreef op maandag 30 juli 2012 @ 09:55:
[...]
maar anders zou ik toch sterk overwegen wel eerst OO te leren programmeren en dan pas procedureel.
Als je OO kan, kun je per definitie procedureel programmeren. Deze opmerking plaats ik dus ook niet en vandaar mijn reactie :)

Verder denk ik om goed OO te programmeren moet je eerst heel veel OO voorbeelden gezien hebben. In php is dat lastig, omdat het van origine een procedurele taal is en OO niet zo mooi is geimplementeerd in php als in andere OO talen.

Structuur in een project stoppen is altijd beter om zo vroeg mogelijk te doen. Dat zeg ik toch ook :) Maar in realiteit lukt dat niet altijd, omdat je met oude code zit bijv. Het is altijd een kwestie van kosten/tijd opwegen tegen de baten.

Voor de OP weet ik niet wat de beste keus is. Als het over code gaat die je niet meer verder gaat ontwikkelen is OO overkill. Maar als je nog lang met de code bezig gaat zou het nuttig kunnen zijn om goed OO te begrijpen.

Acties:
  • 0 Henk 'm!

  • Caelorum
  • Registratie: April 2005
  • Laatst online: 20:41
Waster schreef op maandag 30 juli 2012 @ 11:14:
[...]
Als je OO kan, kun je per definitie procedureel programmeren. Deze opmerking plaats ik dus ook niet en vandaar mijn reactie :)
[...]
Ja en nee. Het klopt dat je iig het kan anders kan je ook geen functie schrijven, maar echt ervaring met het schrijven van langere stukken procedurele code is dan weer een andere. Ik heb iig in die paar jaar al genoeg mensen gezien die niet fatsoenlijk overzichtelijk (zover dat echt kan) procedureel kunnen programmeren. Je kent vast ook wel de voorbeelden van een functie die wat langer is die niet te lezen is of van een klasse met veel private functies die geheel onlogisch met elkaar samenwerken.
Waster schreef op maandag 30 juli 2012 @ 11:14:
[...] Voor de OP weet ik niet wat de beste keus is. Als het over code gaat die je niet meer verder gaat ontwikkelen is OO overkill. Maar als je nog lang met de code bezig gaat zou het nuttig kunnen zijn om goed OO te begrijpen.
Dat dus. :)

[ Voor 18% gewijzigd door Caelorum op 30-07-2012 17:39 ]


Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Ik ga denk ik toch eerst mijn project afmaken. En het gedeelte dat ik naar OOP heb omgezet even zo laten. Wetende dat het geen OOP is. De code is er toch al, dus het maakt niet veel meer uit of ik nu OOP integreer of dat later doe.

Acties:
  • 0 Henk 'm!

  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Ik wil nu verder gaan met OOP. Ik heb bij google docs naar het boek gezocht, in het boek zelf staat dat je java moet kennen om het boek te kunnen volgen. Kan ik dan niet beter dit boek nemen?

Een andere taal leren -waar ik nu niet zo veel mee ben- om OOP te leren vind ik wat teveel.

Acties:
  • 0 Henk 'm!

  • Grijze Vos
  • Registratie: December 2002
  • Laatst online: 28-02 22:17
Zou ik niet doen. Vertaal voor jezelf die java voorbeelden naar php en je hebt meteen de allerbelangrijkste skill van een programmeur onder de knie: abstractie.

Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info


Acties:
  • 0 Henk 'm!

  • ID-College
  • Registratie: November 2003
  • Laatst online: 21:01
Het ligt eraan in hoeverre je expert wilt worden. Voor nu zou ik bij PHP blijven aangezien je dit wilt leren. Hoewel PHP niet zo sterk is in OOP als Java, is dit ruimschoots voldoende om mee te starten.
Mocht je echt het serieuze werk willen gaan doen kun je altijd Java overwegen. Niet dat PHP niet geschikt is, het kan prima, maar het is niet zo sterk als Java. Mocht je puur aan het hobbyen zijn, dan is PHP (en dat boek) prima om de basis onder de knie te krijgen...

[ Voor 4% gewijzigd door ID-College op 05-09-2012 16:49 ]


  • LEDfan
  • Registratie: Juni 2012
  • Laatst online: 22:20
Ik denk dat ik beide boeken (als e-book) koop, en dan het java boek, als een PHP boek lees, en het PHP boek om meer over OOP in PHP te leren.
Pagina: 1