[php] opzet validatie formulieren

[dossiewossie]

Ik ben na aan het denken over de validatie van formulieren voor een extranet wat ik ga bouwen.

Ik wil het een beetje automatiseren dat ik zonder veel problemen nieuwe formulieren kan aanmaken en de validatie kan opvangen.

Ik heb nu / denk nu na over de volgende opzet:


De aanroep van een validatiefunctie:

PHP:

validateIsEmpty('achternaam');

de functie validateIsEmpty:

PHP:

function validateIsEmpty ($name)
{
    
    if (trim(empty($_POST[$name])))
    {
    
    $_POST[$name.fout] = "<br> U heeft het vak ". $_POST[$name]  ." vergeten in te vullen.";
    
    }
}

vervolgens kijk ik met de functie validatiefouten() of er fouten zijn opgetreden:

PHP:

function validatiefouten()

{

$i = 0;

foreach ($_POST as $key => $value){
  
    if(isset($_POST[$key.fout]))
    {
    $i++;   
    }

}


if ($i > 0)
    {
        return true;    
    }
else
    {
        return false;   
    }

}

Dit lijkt allemaal ok te werken, en dit kan best flexibel werken denk ik. Ik weet echter nog niet zoveel van php, dus ik vroeg me af of dit schaalbaar genoeg is om overal toe te passen, of dit in bepaalde gevallen problemen zou kunnen opleveren (wil ik liever nu weten dan over een maand).

Dus als iemand opmerkingen heeft, heel graag!

[ Voor 3% gewijzigd door dossiewossie op 08-08-2005 10:55 ]

[rrrandy]

Wat je nu dus gaat doen is iemand een form laten posten, vervolgens server side het formulier parsen en eventueel een pagina tonen waarin je de gebruiker laat zien wat hij fout heeft ingevuld.

Dit is niet echt de gangbare manier.

Beter kun je het formulier client side controleren door middel van javascript en pas als alles correct is ingevuld het formulier posten naar de server. Zo belast je de server ook niet onnodig.

[Verwijderd]

Beter goed gejat dan slecht gemaakt.

Je kunt als je niet veel van php weet (of wel, maar het fijn vindt om gewoon als goed bestaand spul te nemen) in google eens zoeken op form validation, evt aangeveuld met: php

Overigens is Javascript veel beter als validatie omdat je dan kan valideren tijdens het intypen, du sbijvoorbeeld bij postcode de eerste 4 tekens alleen letters, enz.

[Rac-On]

valideren met javascript is nooit voldoende!!! veel gebruikers hebben het namelijk uit staan of manipuleren. Dus altijd valideren met javascript (snel, clientside) en daarnaast ook in php (hier wat grondiger doen, dus ook sql injection e.d.)

en verder mbt valideren in php: beetje zoeken op google zoals al aangegeven, is een boel over te vinden

[djluc]

Javascript is handig maar het is nog altijd vereist om dit OOK serverside te doen voor de veiligheid!

[Erkens]

rrrandy schreef op maandag 08 augustus 2005 @ 11:00:
Wat je nu dus gaat doen is iemand een form laten posten, vervolgens server side het formulier parsen en eventueel een pagina tonen waarin je de gebruiker laat zien wat hij fout heeft ingevuld.

Dit is niet echt de gangbare manier.

Beter kun je het formulier client side controleren door middel van javascript en pas als alles correct is ingevuld het formulier posten naar de server. Zo belast je de server ook niet onnodig.

Dan nog _moet_ je de gegevens ook op de server controleren, vertrouw _nooit_ op userinput
Stel bijvoorbeeld iemand heeft javascript uitstaan, dan moet je toch die gegevens checken op geldigheid, en zoveel belasting geeft dat nou ook weer niet.

[r0bert]

Maar clientside checken is juist ook weer niet slim. Want het is niet zo veilig als serverside.

//spuit 11

[ Voor 7% gewijzigd door r0bert op 08-08-2005 11:05 ]

[Genoil]

Wat een onzinopmerkingen over javascript zeg...jullie checken zeker ook de geldigheid van creditcardgegevens met javascript? Client-side validatie is puur en alleen voor gebruiksgemak, maar alles wat je client-side valideert moet je sowieso ook nog eens serverside controleren, want als er iets eenvoudig is te bypassen is het wel javascript validatie.

// spuit 11,1

Verder over je implementatie. Zo herbruikbaar en flexibel vind ik het er nog niet uitzien:

• Ik zie nergens een configuratie van dat "isEmpty" bij "achternaam" hoort qua validatie, behalve in de hardcoded aanroep. In m'n eigen projecten kan ik in een XML file aangeven welke soort validators er bij een databasekolom horen.
• Ik zie geen voorbeeld van een andere validator. zijn er overeenkomsten tussen alle validators, maak dan een (abstracte) basisvalidator klasse en leidt al je validators daar vanaf.
• Jouw validator is niet taal-onafhankelijk. Er komt een tijd dat iemand alles in het engels wil en dan heb jij ineens twee stukken code te beheren.
• Jouw validator werkt altijd met gePOSTe informatie. Waarom zou ik geen andere waarden mogen valideren, bijv uit GET of uit een textfile of SOAP message?
• Waarom gooi je je foutmeldingen weer bij POST in? En waarom heet die altijd $key.fout? Kunnen er geen 2 of meer fouten per veld zijn?

[ Voor 59% gewijzigd door Genoil op 08-08-2005 11:15 ]

[rrrandy]

Erkens schreef op maandag 08 augustus 2005 @ 11:04:
[...]

Dan nog _moet_ je de gegevens ook op de server controleren, vertrouw _nooit_ op userinput
Stel bijvoorbeeld iemand heeft javascript uitstaan, dan moet je toch die gegevens checken op geldigheid, en zoveel belasting geeft dat nou ook weer niet.

True...

Laten we het er maar op houden dat het maandagochtend is

[Bosmonster]

@TS

Ik zou in ieder geval je fouten niet opslaan in de $_POST/$_GET/etc arrays opslaan... Dat is onnodige vervuiling van je data. Pak dan een array $errors ofzo.

[Michali]

Ik zou de functie validateIsEmpty of validate() noemen, of isEmpty(). Beide staat een beetje vreemd imo. Verder zou ik van trim(empty($_POST[$key.fout])) empty(trim($_POST[$key.fout]))empty($_POST[$key.fout]) maken. empty retourneert namelijk een boolean en het trimmen daarvan is vrij zinloos.

Je 2de functie kan een stuk korter geschreven worden:

PHP:

function validatiefouten()
{
    foreach ( $_POST as $key => $value ) {
        if ( isset($_POST[$key.fout]) ) return true;
    }
    return false;
}

En waar haal je $fout variabel eigenlijk vandaan?

[ Voor 4% gewijzigd door Michali op 08-08-2005 11:34 ]

[Genoil]

Michali schreef op maandag 08 augustus 2005 @ 11:22:

En waar haal je $fout variabel eigenlijk vandaan?

Da's geen variabele, da's een (Notice:) undefined constant

[dossiewossie]

Bedankt voor de input, ik ben er over aan het nadenken.

Javascript kan ik nog wel gaan gebruiken, maar niet van het allergrootste belang, dus alleen als ik tijd over heb.

De aangeroepen functie had ik even snel gemaakt, die zal inderdaad wel niet helemaal sjofel in elkaar zitten.

En over de aanroep van de server, ag... Het gaat om een extranet, dus mensen zullen daar echt niets van merken. Zoveel mensen zullen het niet tegelijk gebruiken om de verhoogde serverload op te merken.

Over de vervuiling van de post data, ja, dat is eigenlijk wel waar. Ik vond het wel even makkelijk daar het dan automatisch een superglobal is.

Ik denk er nog even over na, bedankt voor alle input.

[PrisonerOfPain]

@Michali:

Note:
empty() only checks variables as anything else will result in a parse error. In other words, the following will not work: empty(trim($name)).

[ Voor 3% gewijzigd door PrisonerOfPain op 08-08-2005 11:30 ]

[dossiewossie]

• Waarom gooi je je foutmeldingen weer bij POST in? En waarom heet die altijd $key.fout? Kunnen er geen 2 of meer fouten per veld zijn?

ik zat er aan te denken om van $_POST[$name.fout] een array te maken, zodat wel de fouten per veld weergegeven kunnen worden

[Michali]

PrisonerOfPain schreef op maandag 08 augustus 2005 @ 11:29:
@Michali:
[...]

Je stom, natuurlijk

Die trim() is dan eigenlijk geheel overbodig.

[Genoil]

dossiewossie schreef op maandag 08 augustus 2005 @ 11:32:
[...]


ik zat er aan te denken om van $_POST[$name.fout] een array te maken, zodat wel de fouten per veld weergegeven kunnen worden

Ok dat is al een stuk beter, maar zoals je zelf al aangaf wil je dat niet in $_POST doen want het gaat helemaal niet om gePOSTe data, het gaat om fouten daarin. Als je niet echt bekend met OOP zou ik dan voor een array gaan in deze vorm:

PHP:

$errors = array($tableName => array($columnName => $message, ..), ..);

Wat overigens ook wel handig is, is een soort van automagische reparatie-optie voor niet-gevalideerde velden. Stel dat er een veld is dat een URL moet bevatten, maar het begint niet netjes met "http://". Dan is het heel vervelend om dat te melden aan de gebruiker als je dat ook gewoon voor hem kan doen. Je kunt dat soort code natuurlijk ook wel ergens anders neerzetten, maar ik denk dat het heel overzichtelijk bij je validatie-code in kan worden opgenomen.

[ Voor 30% gewijzigd door Genoil op 08-08-2005 11:45 ]

[Rac-On]

dossiewossie schreef op maandag 08 augustus 2005 @ 11:29:
Over de vervuiling van de post data, ja, dat is eigenlijk wel waar. Ik vond het wel even makkelijk daar het dan automatisch een superglobal is.

ik vind je eng

offtopic:
php kent een "globals" array...bron

[ Voor 4% gewijzigd door Rac-On op 08-08-2005 11:42 ]

[dossiewossie]

Genoil schreef op maandag 08 augustus 2005 @ 11:39:
[...]


Ok dat is al een stuk beter, maar zoals je zelf al aangaf wil je dat niet in $_POST doen want het gaat helemaal niet om gePOSTe data, het gaat om fouten daarin. Als je niet echt bekend met OOP zou ik dan voor een array gaan in deze vorm:

PHP:

$errors = array($tableName => array($columnName => $message, ..), ..);

Hmm, ok. Ik heb er nog niet op deze manier over nagedacht.

Ik ga uit van het ingevulde formulier, en jij waar het uiteindelijk terechtkomt in de database (..toch?).

Met oop ben ik inderdaad niet bekend, ik denk dat het verstandiger is dat ik dat maar niet ga gebruiken.

Misschien handiger, maar als ik het niet echt snap kan ik later daar nog wel mee in de problemen komen denk ik.

[dossiewossie]

rac-on schreef op maandag 08 augustus 2005 @ 11:42:
[...]

ik vind je eng

offtopic:
php kent een "globals" array...bron

Thanks, dat maakt inderdaad meer sense.

Jullie moeten begrijpen dat ik natuurlijk niet alles van php afweet. Ik probeer mijn problemen op te lossen met de kennis die ik heb van php, en soms kom ik dingen tegen die mijn problemen beter kunnen oplossen.
Dit is toch niet zon rare manier van werken/leren programeren?

Of moet je alles van php afweten om er mee te beginnen?

Maar bedankt voor je reactie

[Genoil]

dossiewossie schreef op maandag 08 augustus 2005 @ 11:44:
[...]
Ik ga uit van het ingevulde formulier, en jij waar het uiteindelijk terechtkomt in de database (..toch?).

Ja. Een gePOST formulier is per defintie 'geldig', het is immers gePOST. Waar het jouw waarschijnlijk om gaat, is dat je geen rommel in je database wilt hebben, toch? Overigens kan je gevalideerde data natuurlijk ook in andere dingen terecht komen dan een database, maar ik had het een beetje versimpeld .

[Rac-On]

dossiewossie schreef op maandag 08 augustus 2005 @ 11:47:
[...]


Thanks, dat maakt inderdaad meer sense.

Jullie moeten begrijpen dat ik natuurlijk niet alles van php afweet. Ik probeer mijn problemen op te lossen met de kennis die ik heb van php, en soms kom ik dingen tegen die mijn problemen beter kunnen oplossen.
Dit is toch niet zon rare manier van werken/leren programeren?

Of moet je alles van php afweten om er mee te beginnen?

Maar bedankt voor je reactie

het is geen rare manier van leren en onderdeel van je leerproces is dat iemand je verteld dat je nooit en te nimmer data in je $_POST of $_GET array terug stopt. Nooit als in absolute doodzonde dus.
Daarnaast maak ik uit je post op dat je hier bezig bent voor een bedrijf iets te maken en imho is het niet heel verstandig om een nieuwe taal te leren op die manier.

[dossiewossie]

rac-on schreef op maandag 08 augustus 2005 @ 11:53:
[...]


het is geen rare manier van leren en onderdeel van je leerproces is dat iemand je verteld dat je nooit en te nimmer data in je $_POST of $_GET array terug stopt. Nooit als in absolute doodzonde dus.
Daarnaast maak ik uit je post op dat je hier bezig bent voor een bedrijf iets te maken en imho is het niet heel verstandig om een nieuwe taal te leren op die manier.

Het is een afstudeeropdracht, dus ik mag leren

Ik heb trouwens wel moeite om erachter te komen hoe een bepaald probleem aangepakt dient te worden.

Ik heb meerdere boeken gekocht, het word altijd anders aangepakt, en er wordt bijna nooit uitgelegd waarom voor die methode gekozen is. Als ik dan recenties van die boeken bekijk op internet, vind altijd de helft het een goed boek, en de andere helft sabelt heb boek neer omdat er belachelijke code wordt gebruikt / gemaakt wordt.

Ik bekijk wel veel tutorials e.d. op internet, maar meestal vind je "maak een loginscript", maar nooit: "verschillende manieren om loginscripts te maken: de voor en nadelen".

Maar goed, ik blijf mijn best doen (ik ben overigens geen programmeur ofzo, dus het wordt hoogstwaarschijnlijk niet mijn toekomst)

[Rac-On]

dossiewossie schreef op maandag 08 augustus 2005 @ 11:58:
[...]
Het is een afstudeeropdracht, dus ik mag leren

* Rac-On eensch is en je succes wenst

Ik heb trouwens wel moeite om erachter te komen hoe een bepaald probleem aangepakt dient te worden.

Ik heb meerdere boeken gekocht, het word altijd anders aangepakt, en er wordt bijna nooit uitgelegd waarom voor die methode gekozen is. Als ik dan recenties van die boeken bekijk op internet, vind altijd de helft het een goed boek, en de andere helft sabelt heb boek neer omdat er belachelijke code wordt gebruikt / gemaakt wordt.

Ik bekijk wel veel tutorials e.d. op internet, maar meestal vind je "maak een loginscript", maar nooit: "verschillende manieren om loginscripts te maken: de voor en nadelen".

Maar goed, ik blijf mijn best doen (ik ben overigens geen programmeur ofzo, dus het wordt hoogstwaarschijnlijk niet mijn toekomst)

php.net is je vriend, daar staan veel user-comments. Daarnaast is het handig/prettig om met andere programmeurs van gedachten te wisselen, zoals je nu aan het doen bent

nog een leuke tip:
dit is natuurlijk onzin:

PHP:

if ($i > 0) 
    { 
        return true;     
    } 
else 
    { 
        return false;     
    }

maak daar gewoon van:

PHP:

return ($i > 0);

[dossiewossie]

@rac-on

Thanks, ik kijk er inderdaad wel eens op, maar zal dat vaker gaan doen.

En tsja, over de laatste code, je zal ongetwijfeld gelijk hebben, en ik zal hier erg vaak in de fout mee gaan. Ik kan namelijk wel een statement logisch in elkaar zitten, maar veel van deze 'shorthand weergaves' (zal wel niet zo heten, maar je snapt wel wat ik bedoel) Weet ik het bestaan niet af. Ik zal ook daar op blijven letten.

thnx b.t.w.

[NeOTheMaTriXM]

Wat ik zelf altijd gebruik is:
Smarty
icm SmartyValidate

Maar dan moet je eigenlijk wel vanaf het begin alles al in templates hebben gedaan.

[dossiewossie]

NeOTheMaTriXM schreef op maandag 08 augustus 2005 @ 12:16:
Wat ik zelf altijd gebruik is:
Smarty
icm SmartyValidate

Maar dan moet je eigenlijk wel vanaf het begin alles al in templates hebben gedaan.

Hier heb ik ook al naar gekeken, en misschien doe ik dat wel ja. Door gebruik te maken van templates wordt het voor mij in ieder geval ook een stuk overzichtelijker

[Genoil]

dossiewossie schreef op maandag 08 augustus 2005 @ 12:20:
[...]


Hier heb ik ook al naar gekeken, en misschien doe ik dat wel ja. Door gebruik te maken van templates wordt het voor mij in ieder geval ook een stuk overzichtelijker

Het is natuurlijk prima om een uitstekende template-engine als Smarty te gaan gebruiken, maar in deze fase van je php-leercurve is het best goed om lekker even zelf aan te modderen. Als je tenminste een php-programmeur wilt worden. Maar als je geen programmeur bent, waarom zit je dan nota bene voor je afstudeeropdracht te php-en?

[dossiewossie]

Het is natuurlijk prima om een uitstekende template-engine als Smarty te gaan gebruiken, maar in deze fase van je php-leercurve is het best goed om lekker even zelf aan te modderen. Als je tenminste een php-programmeur wilt worden. Maar als je geen programmeur bent, waarom zit je dan nota bene voor je afstudeeropdracht te php-en?

Dit is inderdaad precies mijn overweging. Aan de andere kant wil ik wel een template engine gebruiken zodat het extranet wat beter te onderhouden is, aan de andere kant wil ik het gewoon zo proggen dat ik het zelf snap.

Ik zit op een "wat van alles" opleiding in utrecht, n.l. digitale communicatie. Er wordt ook wat aan proggen gedaan op de opleiding.
Ik vind het wel fijn dat als ik de opdracht af is, er daadwerkelijk iets geproduceerd is, en niet een of ander kloote verslagje waar niemand naar omkijkt.
En proggen vind ik op zich wel leuk, als het tenminste lukt

[Cipri]

http://pear.php.net/package/HTML_QuickForm

Complete oplossing voor zowel forms maken als valideren

[orf]

Kijk ook eens naar http://www.formhandler.nl of schrijf zelf zoiets. Je maakt dan je formulier elementen met behulp van objecten. Deze objecten kunnen dan direct de validatie voor hun rekening nemen.

[Verwijderd]

dossiewossie schreef op maandag 08 augustus 2005 @ 10:54:
Dus als iemand opmerkingen heeft, heel graag!

Ik zou een functie maken die je aanroept en die een boolean teruggeeft als validatie.
In deze functie doe je dan de controles en zet je eventuele foutmeldingen in een (globale) variabele.
Let op dat het niet voldoende is om te controleren of velden niet zijn ingevuld.
- Check op maximum lengte van een veld.
- Check op verplichte velden.
- Check op geldige invoer. Bijvoorbeeld is het een geldig getal?
- Check op afhankelijkheden. Bijvoorbeeld einddatum moet groter zijn dan begindatum.
- etc.

[dossiewossie]

Ik heb net even smarty geinstalleerd, ben er nu aan het spelen.

Ik denk toch dat ik dit wel ga gebruiken, smarty lijkt me enorm uitgebreid, maar die functionaliteiten hoef je toch niet te gebruiken?

Voor mijzelf zal het een stuk duidelijker worden als ik de php en de weergave gescheiden kan houden.

[Skaah]

Ik gebruik zelf dit soort constructies. Voor elke soort validatie heb ik een rule-object.

PHP:

<?php

/**
 * Verwijder een gebruiker.
 *
 * @version 2005/04/06
 */

// Starten
require('libs/init.php');
require('libs/formController.class.inc.php');
require('libs/rules.class.inc.php');

class userDeleteController extends formController
{
        function defaultRules()
        {
                $this->addRule(new integerRule('id'));
                $this->addRule(new allowedRule(PRIV_EDIT_USERS));
        }

        function action()
        {
                $database =& getDB();
                $database->db_delete('users',sprintf('user_id = %d',$this->context['id']));

                errorHandler::handleErrors();
                headerLib::redirect('admin-users.php');
        }

        function error()
        {
                new Error('user','cannot_delete','Kan gebruiker niet verwijderen.');
                parent::error();
        }
}

new userDeleteController($_GET);

?>

[NeOTheMaTriXM]

dossiewossie schreef op maandag 08 augustus 2005 @ 14:32:
Ik heb net even smarty geinstalleerd, ben er nu aan het spelen.

Ik denk toch dat ik dit wel ga gebruiken, smarty lijkt me enorm uitgebreid, maar die functionaliteiten hoef je toch niet te gebruiken?

Voor mijzelf zal het een stuk duidelijker worden als ik de php en de weergave gescheiden kan houden.

Je moet het zeg maar zo zien:

[db // gegevens] <--> [PHP] <--> [Smarty(validate)]

Dus je haalt bv je gegevens op uit database.
Stopt deze in een array met nog wat mogenlijke functie's die je er overheen haalt.
Deze array doe je assignen aan je smarty object en in je template kan je de array uitlezen dan.

En in je template krijg je zoiets

code:

<div class="content">
<div class="menu">
{if !$woodtype}
{section name=outer loop=$page_array}
<a href="showserie.php?id={$page_id}&page={$page_array[outer]}" target="_self">{$page_array[outer]}</a>&nbsp;
{/section}
{else}
{section name=outer loop=$page_array}
<a href="showserie.php?woodtype={$page_id}&page={$page_array[outer]}" target="_self">{$page_array[outer]}</a>&nbsp;
{/section}
{/if}
</div>

Deze template bevat dus gewoon html met daar tussen simpele smarty syntax, die vrij erg afgeleid is van de php syntax. Maar net iets simpeler. Omdat het simpeler is ben je dus ook verplicht de gegevens al "bewerkt" te hebben in je php-gedeelte voordat je ze assign't aan je smarty-template, omdat je ze anders gewoon niet meer kan aanpassen.

Deze manier van werken zorgt ervaar dat je geen vreemde halve php code door je html krijgt. Je krijgt alleen nog maar gegevens in je template en die laat je zien.

Voordelen van smarty:
-Verplicht netjes je gegevens aanleveren.
-SmartyValidate
-Caching van output.
-Simpele mogenlijkheid van multi-language website te maken.

Nadelen:
-Alles moet je volgens de regels doen, dus geen wazige constructies.
-Langzamer (heb er zelf nog geen problemen me gehad, zeker niet met caching)

[dossiewossie]

Skaah schreef op maandag 08 augustus 2005 @ 18:31:
Ik gebruik zelf dit soort constructies. Voor elke soort validatie heb ik een rule-object.

PHP:

<?php

/**
 * Verwijder een gebruiker.
 *
 * @version 2005/04/06
 */

// Starten
require('libs/init.php');
require('libs/formController.class.inc.php');
require('libs/rules.class.inc.php');

class userDeleteController extends formController
{
        function defaultRules()
        {
                $this->addRule(new integerRule('id'));
                $this->addRule(new allowedRule(PRIV_EDIT_USERS));
        }

        function action()
        {
                $database =& getDB();
                $database->db_delete('users',sprintf('user_id = %d',$this->context['id']));

                errorHandler::handleErrors();
                headerLib::redirect('admin-users.php');
        }

        function error()
        {
                new Error('user','cannot_delete','Kan gebruiker niet verwijderen.');
                parent::error();
        }
}

new userDeleteController($_GET);

?>

Jah, dat ziet er allemaal erg bruikbaar uit, maar ik zie mijzelf nog niet in staat om zoiets te maken. Ik 'zie' dat oop niet helemaal goed voor me. Ik zal het denk ik eerder bij gewone procudurele code, of een framework smarty i.c.m. met wat pear extensies o.i.d.

[Gwaihir]

rac-on schreef op maandag 08 augustus 2005 @ 11:53:het is geen rare manier van leren en onderdeel van je leerproces is dat iemand je verteld dat je nooit en te nimmer data in je $_POST of $_GET array terug stopt. Nooit als in absolute doodzonde dus.

Tja; dan bega ik toch regelmatig een absolute doodzonde, geloof ik. Het verwerken van inhoudelijke formulieren (incl. de validatie) handel ik nl. graag via de HTML_QuickForm library af, maar daarbij zet ik toch regelmatig data uit een "container" die het van pagina tot pagina vasthoudt terug in het $_GET of $_POST array om QuickForm er weer op los te laten.


Kijk ook eens naar Savant in plaats van Smarty. Savant heeft alle voordelen van een goede template engine a-la Smarty, zonder het eigen taaltje. Dat taaltje is leuk als je de echte PHP af moet schermen omdat je de template schrijvers er niet mee kunt vertrouwen (bijvoorbeeld als je anonieme webgebruikers zelf templates op je site laat aanpassen), maar anders alleen verzwarende en leercurve vergrotende onzin IMHO.

[ Voor 25% gewijzigd door Gwaihir op 09-08-2005 02:12 ]

[Michali]

Het wijzigen van de input vars als $_GET en $_POST moet je imo zo veel mogelijk zien te voorkomen. Alleen als je er een goede reden voor hebt zou ik hier voor kiezen. Een goede reden zou zijn dat je op het punt staat een ander script te includen die ook direct requests kan ontvangen. In zo'n geval kun je dan de input vars voorbereiden op de include en net doen alsof het een normale request is. Dit ook een vrij normale manier van werken bij servlets in java/j2ee, waarbij je ook wel waarden aan het request object toevoegt voordat je de controle overgeeft aan een andere servlet. Wat imo wel een doodzonde is, dat is om waarden in die variabelen te gaan opslaan om de enkele regels later weer te gebruiken, iets waarvoor normale variabelen ook geschikt (lees: bedoelt) zijn.

[supakeen]

Ik zal vanavond mijn class.validation.php hier neerzetten daar kun je alles mee valideren (niet alles maar wel veel )

[dossiewossie]

zmn schreef op dinsdag 09 augustus 2005 @ 12:15:
Ik zal vanavond mijn class.validation.php hier neerzetten daar kun je alles mee valideren (niet alles maar wel veel )

Thnx dude! Ik zal er zeker aandachtig naar gaan kijken.

Net even naar smartyvalidate gekeken en geinstalleerd, maar dat vind ik toch ook niet overzichtelijk genoeg (in ieder geval de documentatie). En je kan het ook niet bepaald snel noemen.

[dingstje]

Ikzelf heb een klasse Validator, een klasse ValidatorRule (dat eigenlijk een Interface zou moeten zijn maar het is niet is wegens verplichte PHP4 compatibilteit) en een klasse ValidatorRuleset. Een voorbeeld van hoe validatie werkt is:

PHP:

$ruleset = new ValidatorRuleset();

$ruleset->Append(new RequiredFieldValidatorRule('email'));
$ruleset->Append(new EmailValidatorRule('email'));

// Voor een rule die meer gegevens nodig heeft
$rule = new PossibleValuesValidatorRule('type');
$rule->setPossibleValues(Array('Foo', 'Bar'));
$ruleset->Append($rule);

// Constructor: Validator($input, $ruleset)
$validator = new Validator($_POST, $ruleset);
$res = $validator->Validate();

if (is_array($res)) { // Validation errors
return Array('success' => false, 'errors' => $res);
}
else {
// Process input
return Array('success' => true);
}

Wat hier gereturned wordt gaat trouwens naar de Smarty template. De Validator loopt over alle ValidatorRules uit de ValidatorRuleset en roept daar de functie Validate() op aan. Deze geeft true terug (geldige gegevens) of een Array met de naam van het ongeldige veld en een errorstring (bvb. 'RequiredField' etc.). Validator gooit al die returned Arrays terug in een asociatieve array.

[dossiewossie]

Ik heb vandaag pear quickform geinstalleerd, maar ik denk dat dat toch te ingewikkeld voor me is.

Het gebruik is wel simpel, maar niet echt overzichtelijk genoeg voor mij om aan te passen.
Het gaat echt veel classes diep, en ik zie niet echt de reden daarvan.

Maar goed, ik speel nog even verder.

[crisp]

/personal rant

HTML_QuickForm zou gerenamed moeten worden naar XHTML_QuickForm, want alles is ver-XHTMLiseerd