[PHP] MVC: Form checking taak van Controller?

Pagina: 1
Acties:
  • 121 views sinds 30-01-2008
  • Reageer

Onderwerpen


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik heb me sinds een week verdiept in het MVC pattern voor PHP en loop nu tegen een twijfel op. De meeste tutorials (aanrader) gaan niet verder dan een oppervlakkige uitleg (geen zinvolle toepassing) en de sources van andere MVC projecten doorgronden is vaak onbegonnen werk.

Dit is mijn op perceptie van de taken van de MVC lagen:
  • Model: Opslaan en ophalen van data in/uit een data object (database, cookie, etc.).
  • View: Genereren van (HTML) code afhankelijk van gekozen actie en/of data uit Model.
  • Controller: View bepalen a.d.h.v. request variabelen.
Nou ben ik een registratieproducedure aan het maken volgens MVC. De mogelijke actions zijn momenteel "new" (toont registratieformulier) en "done" (toont boodschap). Het formulier wordt getoond bij "new", maar ook verstuurd naar "new". In de Controller check ik namelijk de verstuurde velden, vul een error array en beeld het formulier opnieuw af mét errors indien er fouten zijn. Het ziet er ongeveer zo uit:

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?
    class RegisterControllerNew extends RegisterController {
        public function __construct() {
            parent::__construct();
            $errorMessage   = array();
            $errorName      = array();
            
            if(isset($_POST['submit'])) {
                // check velden en vul errorName en errorMessage.
            
                if(!count($errorMessage)) {
                    // geen errors: door met die hap...
                    header("location: /register/?action=done");
                }
            }
            
            $this->View = &new RegisterView($this->Model, $errorName, $errorMessage);
        }
    }
?>

Wat ik me dus afvraag is of het checken van formuliervelden wel een taak is voor de Controller? Ik zou namelijk geen andere oplossing weten, aangezien ik overal lees dat de Controller de $_REQUEST variabelen voor zijn rekening neemt.

Ik vraag dit omdat dit mijn grootste project tot dusver is en ik het zo goed mogelijk wil aanpakken. Je kent het wel ;)

Acties:
  • 0 Henk 'm!

  • Kwistnix
  • Registratie: Juni 2001
  • Laatst online: 02:50
Dat vind ik ook altijd lastig.
In het model zit de bedrijfslogica dus daar zou je eigenlijk de input semantisch moeten valideren, maar syntactische validatie hoort daar niet in thuis. Dus moet je daar nou een scheiding in aanbrengen, semantische validatie van input in het Model en syntactische validatie in de Controller (of misschien in de View zelf?), of valideer je beide facetten op één plaats en waar doe je dat dan?

[ Voor 10% gewijzigd door Kwistnix op 21-05-2005 21:27 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
FallenAngel666 schreef op zaterdag 21 mei 2005 @ 21:25:
Dat vind ik ook altijd lastig.
In het model zit de bedrijfslogica dus daar zou je eigenlijk de input semantisch moeten valideren, maar syntactische validatie hoort daar niet in thuis. Dus moet je daar nou een scheiding in aanbrengen, semantische validatie van input in het Model en syntactische validatie in de Controller (of misschien in de View zelf?), of valideer je beide facetten op één plaats en waar doe je dat dan?
Ik had nog niet eens gedacht aan het verschil tussen semantische en syntactische validatie. Hoe zie jij dat onderscheid precies?

Acties:
  • 0 Henk 'm!

  • Kwistnix
  • Registratie: Juni 2001
  • Laatst online: 02:50
Verwijderd schreef op zaterdag 21 mei 2005 @ 21:30:
[...]


Ik had nog niet eens gedacht aan het verschil tussen semantische en syntactische validatie. Hoe zie jij dat onderscheid precies?
Dat is soms ook nog een lastig punt :)
Stel dat je bijvoorbeeld met referentienummers werkt die alleen uit cijfers mogen bestaan (syntax).
Een ingevuld nummer kan dan syntactisch wel juist zijn, maar nog steeds een ongeldige waarde hebben binnen het systeem (referentienummer bestaat niet) en dus semantisch niet correct is.
Syntax is meestal eenvoudig te controleren en die controle kan je dan in de controler of view bouwen, zodat er geen bercihtverkeer heen en weer gestuurd moet worden tussen View - Controller en het Model. Semanatiek is meestal lastiger, omdat je dan in het onderliggende datamodel moet gaan wroeten en die mag eigenlijk alleen door de functies in het Model benaderd worden.

[ Voor 26% gewijzigd door Kwistnix op 21-05-2005 21:43 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Inderdaad. Maakt het er niet eenvoudiger op. Het wachten is op iemand met een zinnig antwoord :)

Ik heb in een oude uitgave van PHP|Architect overigens een MVC tutorial gevonden die volgens de Jakarta Struts methode werkt. Volgens velen de gouden standaard voor MVC, maar mij te ingewikkeld. Ik heb de PDF van het tijdschrift even geüpload: Download hier. Omdat de Struts manier nogal afwijkt van wat ik elders heb geleerd word ik hier ook niet veel wijzer uit |:(

[ Voor 70% gewijzigd door Verwijderd op 21-05-2005 21:54 . Reden: Editie PHP|Architect toegevoegd ]


Acties:
  • 0 Henk 'm!

Verwijderd

Neem eens een kijkje naar Mojavi. Het is een lichtgewicht MVC Framework voor PHP 5. Ik ben zeer, zeer te spreken over dit framework dat overigens onder de LGPL te gebruiken is. De concepten zijn bijzonder goed uitgewerkt. Het enige nadeel is de configuratie in ini bestanden, maar Sean Kerr is bezig dat om te zetten naar XML.

Acties:
  • 0 Henk 'm!

  • Sybr_E-N
  • Registratie: December 2001
  • Laatst online: 12:54
Waarom zet je al die logica in de desbetreffende controller? Je gaat er dus nu altijd vanuit dat er via een HTML formulier gegevens binnen komen. Wat wil je doen als je gegevens niet beschikbaar krijgt via de std. $_GET en $_POST, maar via een of andere socket-connectie of soap. (ik noem maar iets, je kunt er in je desig/ontwerp iig wel rekening mee houden.)

Kun je het valideren dan niet overlaten aan een soort Helper klasse. Op zich hoeft de controller alleen maar te weten of de data geldig, hij hoeft het niet zelf te doen. Dan houd je de code in je controller simpel, maar nog steeds doelstreffend en is je controller wat abstracter gedefinieerd. De controller hoeft dan alleen maar deze Helper klasse te instantieren, hoe het gevalideer allemaal precies is geimplementeerd hoeft ie niet te weten.

Enige tijd geleden heb ik me ook met dit onderwerp in PHP5 bezig gehouden en hier half Google doorgespit. Hieronder is een lijst met wat voor jouw misschien wat nuttige informatie.

Resources:
PHP pattersn
Sitepoint PHP Application Design forum
Zie ook dit topic daar, staat boordevol informatie over MVC in PHP.
php.MVC, ook een open source framework volgens het MVC principe.

Veel van die patters die je in PHP5 terug ziet op het web, komen voort uit de java hoek en dan vooral J2EE.
SUN Core J2EE Patterns
Core J2EE patterns (extentie van het boek met de zelfde naam.)

Boeken:
Er zijn inmiddels ook enkele boeken op de markt waarin je veel informatie uit kunt halen, het gaat misschien niet altijd speciek op MVC gericht, maar ook dingens als fatsoenlijk errorlogging, authentication komen waarschijnlijk ook allemaal in je applicatie terug.

Apress PHP 5 Objects, Patterns, and Practice isbn: 1-59059-380-4
Wrox: Professional PHP5 isbn: 0-7645-7282-2
Prentice Hall: PHP 5 Power Programming isbn: 013147149X

[ Voor 18% gewijzigd door Sybr_E-N op 21-05-2005 22:45 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Sybr_E-N schreef op zaterdag 21 mei 2005 @ 22:35:
Waarom zet je al die logica in de desbetreffende controller?
Koel, bedankt voor de links! De reden dat de logica in de controller staat is omdat het de Controller is die de errors weer moet doorgeven aan de View en ik niet zou weten hoe dat anders kan. Tenzij je die Helper de errors laat teruggeven, maar daar wordt je Controller niet abstracter van, toch?

Acties:
  • 0 Henk 'm!

  • Sybr_E-N
  • Registratie: December 2001
  • Laatst online: 12:54
Het controleren van bijvoorbeeld een formulier komt zo vaak voor dat het mij logisch lijkt om dit uit te besteden aan een ander object, anders ga je geheid onnodig vaak dezelfde dingen opnieuw (of nagenoeg hetzelfde) implementeren.

Het afhandelen van je error's hoeft de controller ook niet te doen, ik zou het overlaten aan een errorlogger. Die kan dan zelf aan de hand van het type error bepalen wat ie laat zien, maar ook bijvoorbeeld een email versturen of een alleen te loggen in een database.

Het hangt van je doel van de applicatie af natuurlijk tot hoe je door gaat met het opdelen.
Pagina: 1