eigen framework / beheersysteem
Pagina: « vorige 1 2 3 ... 7 8 9 10 11 12 volgende »
Wat doet die validate functie hier?
$validator->validate($_POST['email'], 'email');
Is 'email' als 2e parameter het type waarop gevalideerd dient te worden?
Maar die eerste methode is niet zo moeilijk toch? Gewoon een validatieklasse maken die exceptions gooit bij fouten. Dan moet je nog even nadenken hoe je de foutmelding die weergegeven moet worden dan integreert, maar dat moet lukken. Je kan het beste een goed aangepaste Exception klasse maken.
De tweede methode is wel echt ingewikkeld ja...
Dat is het voordeel van exceptions boven errors.
Je kunt dus zowel Exceptions als Errors throwen? Begrijp ik dat goed?
En een Error voert een die() uit na het catch blok, maar de Exception gaat door? Begrijp ik het zo goed?
Hier geef je dan een foutmelding. Soms weet je dat een username al bestaat (bij een unique veld) of dat een bestand niet bestaat. Zo met uitzonderingen omgaan is veel handiger dan met error properties en heel veel 'false' werken.
Maar in jouw voorbeeld... stel het emailadres is fout...
Hoe handel je dit dan af? Als ik bijv. nu een formulier heb en mensen vullen bepaalde dingen niet goed in, dan verschijnt het formulier opnieuw en zijn de verkeerd ingevoerde velden rood gemarkeerd. Hoe zou dit dan werken met exceptions? Stel, e-mailadres klopt niet... het catch blok wordt getriggerd... oke je zou nu nogmaals het formulier kunnen tonen waarbij het verkeerd ingevoerde veld rood is gemarkeerd... maar eventueel andere verkeerd ingevulde velden worden nu niet gemarkeerd... of wel?
Die definities kan je uit een configuratiebestand halen.
Dit is ook een optie:
$validator->validate(array('name', 'address', 'mail'), $_POST);
(waarbij veld 1 wordt gevalideerd als naam, veld 2 als adres en veld 3 als mailadres)
...of iets dergelijks. Enige nadeel van bovengenoemde is dat je de exacte benamingen moet kennen om vergissingen te voorkomnen, bijv. e-mail ipv mail.
Wat dat betreft lijkt dit me ook handig:
$validator->validateName($_POST['name']);
$validator->validateAddress($_POST['address']);
$validator->validateMailAddress($_POST['mail']);
etc.
Toevoeging op 24/01/2011 17:03:55:
En foute waardes in de validator class opslaan of iets dergelijks...
is alleen mysql_real_escape_string voldoende bij het opslaan? of..? met uitlezen? addslashes, stripslashes, htmlent, htmlspec etc etc?
Gewijzigd op 24/01/2011 17:53:25 door Jaron T
Als je je afvraagt hoe je veilig user input in die queries stopt, is het gebruik van mysql_real_escape_string idd het goede antwoord.
Werkt super handig en niet al te moeilijk na te bouwen. Volg even dezetut en je komt al een heel eind.
Gewijzigd op 24/01/2011 19:41:48 door Mar cel
Edit: je kan trouwens eerst nog eens http://www.phpro.org/tutorials/Model-View-Controller-MVC.html proberen:)
Maar zeg nou eerlijk, het is nu al een topic met 9 pagina's waar vrijwel nog niets gebeurd is (corrent me if im wrong), er wordt door de gebruikers met de moeilijkste termen gegooid. Zou je niet eerst even met de basis beginnen van het programmeren in OO, voordat je begint aan geavanceerde MVC-frameworken?
Gewijzigd op 24/01/2011 21:35:32 door Mar cel
Wat mij overigens meteen brengt tot een andere leuke vraag...
Stel je wil een pagina tonen met daarop producten, laten we voor het gemak uitgaan van fietsen. De pagian is een overzichtspagina en toont van 50 fietsen de naan, de prijs en een plaatje. Hoe zou je deze fietsen dan tonen?
- van alle 50 fietsen een object maken? (waarin behalve de naam, prijs en plaatje ook een omschrijving en specificaties zijn opgenomen. Met andere woorden je laadt dus veel te veel informatie in)
- van alle 50 fietsen een object maken, maar niet alle gegevens inladen?
- gewoon de relevante gegevens uit de database ophalen en in een array zetten en dus niet met objecten werken?
Wanneer gebruik je OOP nou eigenlijk?
De dispatching - het oproepen van de juiste controller - gebeurt in een functie, niet in een klasse.
Ook wordt het 'model' gebruikt. Ik ken dat begrip als 'Domain Object', zeg User, of als 'Domain Model', het geheel van Domain Objects en dus de applicatie-specifieke code. Hier is het een Database Abstraction Layer... Raar...
Pagina: « vorige 1 2 3 ... 7 8 9 10 11 12 volgende »