[MVC] Verantwoordelijkheid Controller vs View

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Full stack developer Node.js

Functie Als fullstack JavaScript developer vind jij het uitdagend om op basis van concrete klantvragen nieuwe functionaliteiten te ontwikkelen. Bij voorkeur worden deze functionaliteiten op een bepaalde manier geprogrammeerd, zodat ze door meerdere klanten te gebruiken zijn. Je hebt dus vaak te maken met abstracte vraagstukken. Om dit te kunnen realiseren sta je nauw in contact met de product owner en/of klant. Je bent niet alleen onderdeel van het development team, maar hebt ook vaak contact met de product-owner en/of klanten om daardoor inzichten te verzamelen die leiden tot productverbeteringen. • Inzichten verzamelen bij de klant en/of product owner •

Bekijk vacature »

C# .NET developer voor innovatieve applicaties gez

Bedrijfsomschrijving Deze werkgever houdt zich al ruim 20 jaar bezig met het ontwikkelen van innovatieve software en dat willen ze graag nog lang doorzetten. En dat merk je ook als je als .NET developer hier aan de slag gaat. De applicaties worden continu doorontwikkeld met altijd als uitgangspunt dat zowel de kwaliteit als het gebruikersgemak van hoog niveau is. Het bedrijf telt inmiddels ruim 25 medewerkers waarvan meer dan de helft op de development afdeling werken. Meer weten over deze werkgever? Mail naar [email protected] of bel 0657578548 Functieomschrijving Je komt te werken in een Scrum team met andere .NET developers

Bekijk vacature »

Software Ontwikkelaar C# .NET

Functie omschrijving Startende Software Ontwikkelaar gezocht met kennis van C# .NET! Ben jij net klaar met je opleiding en ben je op zoek naar je eerste echte werkervaring? Of heb jij al enige werkervaring maar ben toe aan iets nieuws? Dan is dit de perfecte kans voor jou! Wij zoeken namelijk een Junior Software Ontwikkelaar die klaar is voor een nieuwe uitdaging bij een leuke werkgeven in de regio Zeist. In deze functie werk jij vaak aan verschillende projecten en ga je bij klanten op bezoek. Ben jij op zoek naar een functie met uitdaging, diversiteit en verantwoordelijkheid? Dan is

Bekijk vacature »

Software Developer C# - Deventer

Software Developer C# – Deventer Bijdragen aan de toekomst van het onderwijs! Ben jij op zoek naar een dynamische omgeving waar vol enthousiasme wordt gewerkt aan software voor interactieve dashboard- en analysetoepassingen ter verbetering van het onderwijs? Dan zijn wij het bedrijf voor jou! TIG is een bedrijf met een informele en ondernemende werksfeer, waarbij goede ideeën snel leiden tot concrete acties. Wij zijn een software ontwikkelorganisatie en focussen ons op het ontwikkelen en implementeren van oplossingen voor het leveren van managementinformatie, datavisualisatie en analyses voor het onderwijs. Met onze dashboard- en analyseoplossingen zetten scholen gegevens om naar betekenisvolle informatie.

Bekijk vacature »

Informeel bureau zoekt Senior PHP developer

Functie Als senior PHP developer neem je het voortouw in ontwikkeltrajecten en ben je in staat werk uit te leggen aan collega’s om zo je kennis met hen te delen. Je deinst niet terug voor ingewikkelde projecten. Deze zie jij alleen maar als uit uitdaging. Je werkt doorlopend aan klantcases (en hierdoor je klant echt leert kennen), maar toch ben je afwisselend bezig. Dit alles in een vrije en ontspannen werksfeer, met een team van gelijkgestemde. Binnen de development teams werken ze met o.a. PHP, Laravel, React, Node, Elastic, Amazon AWS, JIRA, Solid, Domain-driven-design, Doctrine, Redis, docker, Kubernetes, CI, PHP

Bekijk vacature »

Embedded Developer C++

Functie omschrijving Ben jij op zoek naar een leuke uitdaging als Embedded Developer, zoek dan niet verder! Voor een leuke opdrachtgever in omgeving Rotterdam zijn wij op zoek naar een Embedded Developer die graag met Embedded Devices werkt. Je zult verantwoordelijk worden voor het ontwikkelen en onderhouden van diverse producten. Jouw specialisatie ligt op het vlak van software, hardware en back-end. Dit bedrijf is gespecialiseerd in het ontwerpen van software voor een unieke industrie. Wil jij betrokken worden bij een proces dat loopt van ontwikkeling tot installatie? Waarbij je bezig zult zijn met perfecte systemen die geleverd worden aan binnen

Bekijk vacature »

Senior PHP developer met ambities tot Software Arc

Functie Momenteel zijn ze op zoek naar een ervaren PHP developer die zichzelf graag bezighoudt met zaken als architectuur en de algehele verbetering van structuren en standaarden. Het is eigenlijk meer operationeel als uitvoerend omdat je bezig gaat met zaken als het verder uitrollen en verbeteren van testautomatisering, codereviews, tickets en de doorloop hiervan en architectuurkeuzes. Mocht je hiernaast ook wat DevOps kennis meenemen is dit mooi meegenomen! Vanwege het kleine team maar de wereldwijde impact die zij leveren is er veel focus op kwaliteit. In deze functie werk je aan één van hun belangrijkste applicaties. Hierin werk je nauw

Bekijk vacature »

Embedded Software Developer Games

Functie omschrijving Heb jij affiniteit met hardware en wil jij kleuren binnen een Qt framework? Spreek jij de talen C en of C ++? Dan ben ik wellicht opzoek naar jou! Voor een super gave opdrachtgever in omgeving Delft is er namelijk plek voor een nieuwe kracht! Dit bedrijf is gespecialiseerd in het ontwerpen van software voor een unieke game industrie. Wil jij betrokken worden bij een proces dat loopt van ontwikkeling tot installatie? Waarbij je bezig zult zijn met perfecte systemen die geleverd worden aan binnen en buitenland? Je zult in een team, samen met vier ontwikkelaars, de mooiste

Bekijk vacature »

Frontend Developer

Functieomschrijving Voor de NIPV zijn wij opzoek naar een Frontend Developer. Als Frontend Developer ga jij aan de slag om dashboards te bouwen vanuit het datawarehouse. Dit stelt NIPV in staat om snel en eenvoudig bij correcte bedrijfsvoeringsinformatie te kunnen. Je ontwikkelt dashboards in PowerBI, publiceert en onderhoud die, verzameld en verwerkt feedback in overleg met het ontwikkelteam. Naast dashboards ontwikkel en onderhoud je een datamodel in Excel waarmee adviseurs, controllers en analisten in staat worden gesteld om de gegevens uit de dashboards te raadplegen en anders te filteren of bepaalde gegevens nader te verfijnen, zodat verdiepende vragen kunnen worden

Bekijk vacature »

Functioneel applicatiebeheerder - SOP-SYS-SAM

TenneT is hard groeiend om de onze ambities waar te kunnen maken. Zo nemen wij een leidende rol in het aanjagen van de energietransitie. Het werven van nieuw talent speelt daarin een cruciale rol. Wij zijn op zoek naar een gedreven Functioneel Applicatiebeheerder voor het financiele domein op onze locatie Arnhem die hieraan wil bijdragen en misschien ben jij dat wel? Jouw bijdrage aan TenneT Je gaat samenwerken in een team van circa 15 functioneel applicatiebeheerders en gaat onderdeel uitmaken van een DevOps team. Met dit team ga je applicaties (laten) ontwikkelen en beheren. Hierbij concentreer je je vooral op

Bekijk vacature »

Full Stack .NET Developer C# ASP.NET

Samengevat: Deze werkgever is gespecialiseerd in het op afstand bewaken en besturen van machines en processen. Ben jij een ervaren Full Stack .NET Developer? Heb je ervaring met C# en ASP.NET? Vaste baan: .Net Developer C# ASP.NET HBO €3.300 - €4.500 Deze werkgever is een snel groeiende onderneming gespecialiseerd in het op afstand bewaken en besturen van machines en processen, IoT (Internet of Things). Deze werkgever is een veelzijdige organisatie. Je werkt voor de eigen IT organisatie. Zij werken met moderne technologie en staan open voor innovatie. Wil jij bij de top specialisten horen? Ben jij op zoek naar een

Bekijk vacature »

Software developer

Werkzaamheden voor jou als software developer Voor een goede relatie in de regio Zwolle (meerdere locaties) zoeken wij een software developer die betrokken is bij de ontwikkelcyclus en verantwoordelijk is voor het testen en keuren van nieuwe en geoptimaliseerde software. In deze functie ben je in de implementatiefase de persoon die risico's beoordeelt en intern oplossingen aanbrengt om risico's te verkleinen. Binnen het ontwikkelteam van de software ben je een belangrijke schakel waar je intensief meewerkt met scrum. Het voorkomen van bugs in de programma's en het bevorderen van gebruiksvriendelijkheid voor eindklanten zijn voor jou een uitdaging en geeft voldoening

Bekijk vacature »

Back-End Developer in Laravel / PHP

Functie omschrijving Wij zijn op zoek naar een Medior PHP Laravel Developer voor een gaaf bedrijf in de omgeving van Amsterdam! Voor een enthousiast team die zich graag bezig houdt met softwareontwikkeling zijn wij op zoek naar versterking. Je werkt in een klein ontwikkelteam en bent zeer betrokken bij alle aspecten van de softwareoplossingen. Van het ontwerpen tot de oplevering. Binnen deze functie ga je aan de slag met het aanpassen, verbeteren en vernieuwen van de logistieke oplossingen. Je krijgt veel te maken met koppelingen naar systemen en de verzoeken van de klant. Je komt terecht in een team, waarbij

Bekijk vacature »

Medior/senior Front-end developer (Vue.js)

Functie Als Front-end developer ben je uiteindelijk overkoepelend aan de slag voor de 3 ontwikkelteams die ieder aan een specifiek product werken. In samenwerking met de UX-designer en de huidige Front-end developer zorg je voor gebruiksvriendelijke software. Lijkt het jou interessant om complexe problemen op te lossen en feautures naar een hoger niveau te tillen? En vind je het niet erg om oudere delen van de applicaties te refactoren i.c.m. het toevoegen van nieuwe functionaliteiten? Dan komen wij graag met je in contact. Eisen • HBO werk- en denkniveau (ze kijken niet naar papieren, maar naar denkniveau, motivatie en zelfredzaamheid)

Bekijk vacature »

Java Ontwikkelaar

Java/Kotlin Developer Ben jij een ervaren Java/Kotlin developer met een passie voor het automatiseren van bedrijfsprocessen? Wil je graag deelnemen aan uitdagende projecten bij aansprekende klanten? En ben je op zoek naar een professioneel, ambitieus en dynamisch bedrijf om je carrière verder te ontwikkelen? Kom dan ons team bij Ritense in Amsterdam versterken! Zo ziet de functie eruit: Als Java/Kotlin developer bij Ritense ben je verantwoordelijk voor de ontwikkeling en implementatie van applicaties die bedrijfsprocessen automatiseren, zodat onze klanten slimmer, efficiënter en klantgerichter kunnen werken. Als developer ben je in de lead en zorg je voor de correcte oplevering van

Bekijk vacature »
Citroen Anoniem Graag

Citroen Anoniem Graag

06/06/2009 21:58:00
Quote Anchor link
Goedenavond allen,

Al langere tijd vind ik het leuk om wat met OOP programmeren te proberen (en vooral het idee van OO). Om die reden heb ik recent een MVC-Framework geschreven.
Dit heb ik nu in gebruik in een andere applicatie en ik loop tegen wat problemen aan.
Ik vind het moeilijk/onduidelijk de verantwoordelijkheden van de View en de controller te scheiden.

Voorbeeldcase:
Er wordt een request gedaan, deze wordt door de froncontroller opgevangen en de router/dispatcher zorgt ervoor dat de goede controller wordt aangeroepen en de bijbehorende method. In dit voorbeeld betreft het een method om een gastenboek bericht toe te voegen.
Je begint met het controleren van de meegegeven POST-waardes. Deze zijn echter niet correct omdat de gebruiker vergeten is zijn naam in te vullen.
Het bericht wordt dus niet toegevoegd en er moet worden verteld dat je de naam in moet vullen omdat het een verplicht formulierveld is en daar onder het formulier laat zien.
De schematische code
Code (php)
PHP script in nieuw venster Selecteer het PHP script
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
<?php
//voorbeeld code, de naam message is natuurlijk niet heel veel zeggend

public function addMessage()
{


    try
    {
        $oForm = new Form('index.php?c=Gastenboek&amp;m=addMessage', 'nameofform');
        $oNameField = new Text('name', new Label('Name:', 'class_no_error', 'class_error'));
        $oNameField->addValidator(new Required, new NotEmpty);
        $oMessageField = new Textarea('message', new Label('Your message:', 20, 10 'class_no_error', 'class_error_textarea'));
        $oMessageField->addValidator(new Required, new NotEmpty, new MinLength(3));
        $oForm->addElement($oNameField, $oMessageField);
    }

    catch(Exception $oException)
    {

        if(Framework::$DEBUG == true)
        {

            echo $oException->getMessage();
        }

        else
        {
            $this->setView(new Error('Formulier kon niet geladen worden'), abstractView::$Notoverridable);
        }
    }

    
    if($oForm->isSubmitted() && $oForm->isValid())
    {

        $oMessage = new Message($oNameField->getValue(), $oMessageField->getValue());
        $this->saveMessage($oMessage);
        header('Location: index.php?c=Gastenboek&m=Done');
    }

    elseif($oForm->isSubmitted() && !$oForm->isValid())
    {

        $oView = new addMessageView($oForm);
        $oErrorLog = $oForm->getErrorLog();
        foreach($oErrorLog as $oError)
        {

            if($oError->getValidator instanceof NotEmpty)
            {

                $oView->addError('Je ziet toch wel dat je een naam in moet vullen eikel!');
            }

            // etc elseif($oError->getValidator instanceof MinLength){ }
            
        }      
 
    }

    else
    {
        $oView = new addMessageView($oForm);
    }

    
    $this->setView($oView);
}
[
/code]

Alleen zoals deze voorbeeldcode nu is ben ik niet blij met de scheiding output/logica(/data):
Je zou willen dat als je iets aan de output van je applicatie wil veranderen dat je dan alleen de view in moet duiken, maar zoals het nu is geeft de controller de hardcoded data aan de view wanneer er wat fout gaat en moet je dus toch op meerdere plaatsen zoeken als je de output wilt veranderen.

Hoe lossen jullie dat op? Voor elke mogelijke foutmelding een view maken en die dan aan een andere view meegeven met een [i]setError(Errorview $oView) functie[/i]? Dat lijkt me redelijk omslachtig omdat je 10000e foutmeldingen kunt hebben.

De kern van mijn probleem is dus hoe je hardcode data opslaat: in de view?(bijvoorbeeld een array met errornummers en errormeldingen en dan een setErrorNumber() functie?), in de controller?, in een Model?

Alvast bedankt,
Freek

[quote]
[
b]Edit[/b]
Veel typo's, leestekens
[quote]
Gewijzigd op 01/01/1970 01:00:00 door Citroen Anoniem Graag
 
PHP hulp

PHP hulp

28/03/2024 11:40:02
 
Citroen Anoniem Graag

Citroen Anoniem Graag

08/06/2009 17:58:00
Quote Anchor link
bumpje
 
Midas

Midas

08/06/2009 18:14:00
Quote Anchor link
Hmm.. je kan het natuurlijk gewoon in je template zetten.. ik weet niet wat voor/of je een template engine gebruikt, maar je kan bijvoorbeeld bij Smarty ook gewoon if/else gebruiken. Ook is het een optie om met errornummers in combinatie met een bestand met talen erin te werken.
 
Tim

Tim

08/06/2009 21:13:00
Quote Anchor link
Iedere error gooit bij mij uiteraard een exception als dat nodig is. De tekst in deze exception is hardcoded gezet in de controller / model. Vervolgens wordt er één 'exception'-view geladen die overzichtelijk laat zien wat er is gebeurt.

Naar mijn idee horen deze errors op zichzelf niet thuis in een view, vandaar dat ze in de controller / model zelf gezet zijn. Vervolgens is er uiteraard wel een view nodig (HTML, PDF, etc.) om werkelijk te laten zien dat er wat mis is gegaan.
 
Jelmer -

Jelmer -

08/06/2009 21:19:00
Quote Anchor link
Je kan bij exceptions ook een foutcode opgeven (als 2e argument) Je zou aan je view nog een soort vertaal-class kunnen hangen die op basis van die errorcode dan de juiste melding geeft. Je kan dat in de view rechtvaardigen.


... of het praktisch handig is vraag ik me af. Net als exceptions. Ik gebruik ze zelf erg graag, maar alleen voor de gevallen waar ik in de normale loop van de applicatie geen fouten verwacht. Dat iemand fout een formuliertje invult verwacht ik eigenlijk wel, en ik wil meerdere van deze fouten tegelijkertijd kunnen weergeven, en al dan niet hints geven over hoe het wel moet, welke tekens wel toegestaan zijn. (iets wat niet noodzakelijk in een exception zelf zit)
 
Citroen Anoniem Graag

Citroen Anoniem Graag

08/06/2009 21:35:00
Quote Anchor link
Midas schreef op 08.06.2009 18:14:
Hmm.. je kan het natuurlijk gewoon in je template zetten.. ik weet niet wat voor/of je een template engine gebruikt, maar je kan bijvoorbeeld bij Smarty ook gewoon if/else gebruiken. Ook is het een optie om met errornummers in combinatie met een bestand met talen erin te werken.

Een view is in mijn ogen niet bedoelt als data opslag, dus ook niet voor errorcodes, daar gebruiken we de models voor. (Models = data, Views = presentatie)

Tim schreef op 08.06.2009 21:13:
Iedere error gooit bij mij uiteraard een exception als dat nodig is. De tekst in deze exception is hardcoded gezet in de controller / model. Vervolgens wordt er één 'exception'-view geladen die overzichtelijk laat zien wat er is gebeurt.

Naar mijn idee horen deze errors op zichzelf niet thuis in een view, vandaar dat ze in de controller / model zelf gezet zijn. Vervolgens is er uiteraard wel een view nodig (HTML, PDF, etc.) om werkelijk te laten zien dat er wat mis is gegaan.

Dat de tekst in de exception hardcoded in de controller/het model gezet is lijkt mij logisch. Maar vaak is deze boodschap niet bedoel om de bezoeker te tonen. Daarom moet de foutmelding die de bezoeker voor zijn neus krijgt ergens vandaan komen. En waar die van daan moet komen was juist mijn vraag ;).
'Vervolgens is er uiteraard wel een view nodig om werkelijk te laten zien dat er wat mis is gegaan.' I Agree


Jelmer schreef op 08.06.2009 21:19:
Je kan bij exceptions ook een foutcode opgeven (als 2e argument) Je zou aan je view nog een soort vertaal-class kunnen hangen die op basis van die errorcode dan de juiste melding geeft. Je kan dat in de view rechtvaardigen.

Dat zou ik inderdaad kunnen doen, ik heb er vannacht even over na gedacht en ik heb besloten de error codes hardcoded in een model te plaatsen (het is tenslotte data van de applicatie).
Door de data in een model te plaatsen is het mogelijk om later vrij makkelijk een meertalig systeem in te bouwen (aanpassing model zodat hij het uit een db op haalt). En je hoeft je tekst aanpassingen alleen maar in een model te doen, en de opmaak slechts in de views. Precies zoals dat in mijn ogen zou moeten.

Ik zit alleen nog met 1 probleem. Hoe kent de view het model? Het lijkt mij onhandig om deze steeds mee te moeten geven aan elke view. Want als je dan een ander model wilt moet je dat op veel plaatsen veranderen. En tegelijkertijd wil ik het ook niet abstraheren naar een parrent class want dan maak je een harde koppeling en verlies je dus de dynamiciteit (dat is geen woord, misschien dynamiek)

Jelmer schreef op 08.06.2009 21:19:
... of het praktisch handig is vraag ik me af. Net als exceptions. Ik gebruik ze zelf erg graag, maar alleen voor de gevallen waar ik in de normale loop van de applicatie geen fouten verwacht. Dat iemand fout een formuliertje invult verwacht ik eigenlijk wel, en ik wil meerdere van deze fouten tegelijkertijd kunnen weergeven, en al dan niet hints geven over hoe het wel moet, welke tekens wel toegestaan zijn. (iets wat niet noodzakelijk in een exception zelf zit)

Het gebruik van exceptions is in mijn ogen duidelijk. Die worden alleen gegooid als er een uitzonderlijke situatie optreed. Dus niet als er een formulier fout ingevuld wordt. Dit is immers standaard functionaliteit van een applicatie, geen uitzondering.
De exception die ik in het voorbeeld opvang is om te kijken of het formulier gegeneerd kan worden (niet 2x dezelfde elementnaam).

Conclusie so far:
foutmeldingen sla ik op in een model. In praktijk komen deze niet uit een db maar staan ze hardcoded getyped. Dit wordt een array met keys als identifier.
De message van een exception blijft voor debuggen, maar aan de hand van de error code die ik mee ga geven valt de 'mooie' errorcode te achterhalen.

2 problemen:
- Hoe kent de view het model?
- mooie manier om dubbele identifiers te voorkomen
Gewijzigd op 01/01/1970 01:00:00 door Citroen Anoniem Graag
 
Jelmer -

Jelmer -

08/06/2009 22:42:00
Quote Anchor link
Wat betreft dat foutmeldingen (let wel, vertalingen!) data zijn verschillen we van mening. Mijns inziens is een foutmelding die jij wilt weergeven niets anders dan een voor de gebruiker vriendelijke manier van melden dat je applicatie een probleem heeft. Het is aan de presentatie-laag om te bepalen hoe die melding gaat worden gepresenteerd. Waarom dat ook niet de presentatie-laag laten bepalen hoe de melding wordt gepresenteerd? (hey, zie je dat?) Wat verschilt de kleur van de tekst van de gekozen woorden voor de tekst? Het is beiden onderdeel van de presentatie, beiden van het vaste deel van de applicatie, het frontend dat het backend–het model–bruikbaar maakt.

Sowieso is het handig om vanuit de view bij je model-laag te kunnen komen. Het is zelfs verdomd handig, want zo hoef je niet de code om bijvoorbeeld recente topics te tonen in je footer in al je controllers op te nemen. Zend doet dat geloof ik door een "helper" te gebruiken, maar in weze is dat hetzelfde. De view kan de helper aanroepen, de helper heeft toegang tot het model (en nog veel meer, wat ik dan weer meer twijfelachtig vindt. Helper zou read-only moeten zijn)

Ik doe het zelf door een object waar alle instanties van de losse onderdelen van het model mee te geven bij het instantiëren van de view. Je kan ook singleton of registery gebruiken, maar dan heb je het nadeel dat jij noemt: je hebt je classnames hardcoded getypt. Daarnaast heb je minder controle over welke instantie (of beter: van welke class een instantie) je object gebruikt.

Mocht je door willen gaan voor dat foutmeldingen-in-model-idee, dan raadt ik een of andere vorm van namespaces aan. Classname-vd-exception+errorCode misschien?
 
Citroen Anoniem Graag

Citroen Anoniem Graag

08/06/2009 23:41:00
Quote Anchor link
Ik zou even willen opmerken dat het niet alleen om applicatie-errors gaat maar ook om usernotices.

Mijns inziens is een foutmelding die jij wilt weergeven niets anders dan een voor de gebruiker vriendelijke manier van melden dat je applicatie een probleem heeft.
Klopt met als aanvulling dat ik een usernotice geen applicatie error vind, maar dat het voor de gebruiker wél een error is.

Het is aan de presentatie-laag om te bepalen hoe die melding gaat worden gepresenteerd.
Klopt!

Waarom dan ook niet de presentatie-laag laten bepalen hoe de melding wordt gepresenteerd?
Wat is het verschil met de vorige zin?

Wat verschilt de kleur van de tekst van de gekozen woorden voor de tekst?
De kleur is slechts een weergave van de kennis maar niet de kennis zelf. De letterkleur van de foutmelding zou je in de printview misschien zwart willen hebben maar in de weblayout rood, terwijl de tekst onveranderd is. Daarmee is het in mijn ogen niet het zelfde.

Het is beiden onderdeel van de presentatie,
Klopt, echter is 1 deel van de presentatie de kennis (uit het model) en het andere deel de weergave van de kennis op een specifieke manier.

beiden van het vaste deel van de applicatie,
Dat is precies wat ik wil veranderen. Ik wil de meldingen niet in de controller hebben omdat het in mijn ogen niets anders is dan data en die daarom dus ook in die laag thuis hoort.

Sowieso is het handig om vanuit de view bij je model-laag te kunnen komen. Het is zelfs verdomd handig, want zo hoef je niet de code om bijvoorbeeld recente topics te tonen in je footer in al je controllers op te nemen. Zend doet dat geloof ik door een "helper" te gebruiken, maar in weze is dat hetzelfde. De view kan de helper aanroepen, de helper heeft toegang tot het model (en nog veel meer, wat ik dan weer meer twijfelachtig vindt. Helper zou read-only moeten zijn)
Daar heb ik inderdaad een loader voor, alleen moet je op die manier in elke view het model aanroepen. Iets wat flexibiliteit geeft maar ook veel dezelfde regels code.

Ik doe het zelf door een object waar alle instanties van de losse onderdelen van het model mee te geven bij het instantiëren van de view. Je kan ook singleton of registery gebruiken, maar dan heb je het nadeel dat jij noemt: je hebt je classnames hardcoded getypt. Daarnaast heb je minder controle over welke instantie (of beter: van welke class een instantie) je object gebruikt.
Ik heb die harde koppeling iets zachter gemaakt door aan een core class de optie mee te geven wat de Register class is (Framework::setAttribute(Framework::ATTR_REGISTER_CLASS, (Framework::ATRR_DEFAULT || callback)) Op die manier heb je echter nog steeds maar de mogelijkheid om 1 register te gebruiken, maar dat ter zijde.

De reden dat ik mij dit afvraag is puur flexibiliteit:
Na een tijd met mijn framework te hebben geëxperimenteerd vond ik het onbevredigend dat de presentatie niet puur uit .de view voortkwam in communucatie met een model (die door de controller geleverd wordt).* je moest toch in alle 3 de lagen rommelen als je net een iets andere zin wilde om te vertellen dat de inloggegevens niet juist waren/form niet ingevuld/je wel ingelogd moet zijn/je sessie is verlopen/javascript niet aan staat/.... .

*
Een View is een visuele representatie van zijn model(len). Het geeft bepaalde attributen van het model
weer en verbergt juist anderen. Je zou dus kunnen zeggen dat het fungeert als een presentatiefilter.
Een View is gekoppeld aan zijn model (of een gedeelte daarvan) en verkrijgt zijn informatie van het model
door hier vragen aan te stellen.
 
Mark PHP

Mark PHP

12/06/2009 23:44:00
Quote Anchor link
Toevalligerwijs wilde ik vandaag een soortgelijk topic starten. In mijn huidige framework implementeer ik het MVC pattern nog een beetje onhandig. Een View kan bij mij niet zonder bijbehorende controller, iets wat ik absoluut niet logisch vind. Zie het footer voorbeeld van Jelmer.

Waar ik nog wel mee zit is waar je precies je database instance, log instance, config instance, language instance etc. aanmaakt. Dit kan op verschillende manieren:
A - in je index.php en dan via een (soort) Registry doorgeven aan de FrontController. Deze zou het dan op zijn buurt kunnen injecteren in de controllers. Blijft het probleem dat je views en models ook toegang tot dit 'Registry' moeten hebben.
B - elke instance apart injecteren in je objecten. Op deze manier kan je bijvoorbeeld de view de toegang tot de database ontzeggen, wat me zeer logisch lijkt. Aan de andere kant leidt dit tot code die je liever kwijt bent dan rijk.
C - apart aanmaken in elk model / view / controller. Dit lijkt me sowieso geen goede oplossing. Zeker omdat je later ook alle instances wilt kunnen bereiken vanuit je plugins / widgets / libraries.

Momenteel is het bovenstaande waar ik nog mee zit. Ik vind geen van bovenstaande oplossingen echt ideaal, dus ik vraag me af wat de andere suggesties zijn.
Gewijzigd op 01/01/1970 01:00:00 door Mark PHP
 
Jelmer -

Jelmer -

13/06/2009 10:43:00
Quote Anchor link
Ik doe het zelf op de ietswat "vieze" manier, door een soort registery instance op te bouwen in de config, en deze aan de frontcontroller te geven. Die geeft hem dan weer aan de controller die die start, en uiteindelijk ook aan de view. De model bouw ik ook op in de config, in diezelfde code waar ik ook dat registery-ding opbouw dus daar kan ik direct pdo & caches aan de model-classes hangen.

Je zou je registery-dinges (het is bij mij niet helemaal registery, het is meer gewoon een dom object met properties, geen singleton, meer een soort context) deels kunnen kopiëren naar een wat afgeslankte versie voor de view.

Eigenlijk is deze manier niet eens zo heel vies, wanneer je je context/registery object volledig specificeert in een class die allemaal interfaces implementeert, waarbij iedere interface verteld dat er een bepaald object bij je registery opvraagbaar is. Dan heb je en het voordeel van één argument ipv een leger setters bij je controller en view, en het voordeel van de eisen die je aan classes kan stellen.
 
Mark PHP

Mark PHP

13/06/2009 16:01:00
Quote Anchor link
Oke oke.

Je zegt dat je het model in je config opbouwt. Maar aangezien het vaak voorkomt dat je meerdere modellen binnen een controller gebruikt, hoe moet ik dit precies voor me zien?

Verder zie ik niet helemaal in hoe dat interface principe werkt. Ongeveer zo?
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
class Context implements Database_Context, Cache_Context {
  public function getDatabase();
  public function setDatabase(Database $db);
  public function getCache();
  public function setCache(Cache $cache);
}


class MyController implements Database_Context {
  //roept getDatabase() uit Context instance aan.
  public function getDatabase();
}

?>
Waarbij de controller dan geen expliciete kennis heeft over het bestaan van een getCache() methode.
Gewijzigd op 01/01/1970 01:00:00 door Mark PHP
 
Jelmer -

Jelmer -

13/06/2009 17:32:00
Quote Anchor link
Code (php)
PHP script in nieuw venster Selecteer het PHP script
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
<?php

interface DatabaseProvider {
    public function getDatabase();
}


interface CacheProvider {
    public function getCache();
}


abstract Class Context {
    
}


Class ControllerContext extends Context implements DatabaseProvider, CacheProvider {

    public function getDatabase() {}
    public function getCache() {}
    
}


Class ViewContext extends Context implements CacheProvider {

    public function getCache() {}

}


class Controller {
    
    public function __construct(DatabaseProvider $context) {}
    
    // of
    
    public function __construct(Context $context)
    {

        if(!$context instanceof DatabaseProvider)
            throw new InvalidArgumentException('Wrong context');
        
        // doe iets met de db
        
        if(!$context instanceof CacheProvider)
            throw new CompleteFailure('Still wrong context...');
    }
}


$x = new ViewContext();
$y = new Controller($x); // prrr! fout
?>


Het maakt op zich niet zoveel uit of je interfaces gebruikt of gewoon een method aan Context toevoegt die je kan vragen of de context een bepaalde instantie van iets kan leveren. Eigenlijk is het puur syntactic sugar. Nu kan je aan de buitenkant van het object zien of het het goeie object is, en anders moet je het vragen. (In talen als C++ had het wel uitgemaakt omdat het daar tijdens compilen berekend kan worden. PHP doet de controle altijd pas wanneer hij hem tegenkomt bij het uitvoeren)


Ik gebruik dit ook om m'n model in op te slaan, omdat m'n config scriptje zeg maar hier op neerkomt:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<?php

$context
= new Context();

$pdo = new PDO('...');
$context->set_pdo($pdo);

// if memcache beschikbaar
$cache = new Cache_Memcache('...');
$context->set_cache($cache);

$topic_store = new Topic_Store($pdo, $cache);
$context->set_topics($topic_store);

// userstore gebruikt andere cache, niet beschikbaar voor de controllers
$slave_cache = new Cache_Memcache('...');
$user_store = new User_Store($pdo, $slave_cache);
$context->set_users($user_store);

return $context;
?>


Maar je kan je context class ook zo schrijven dat hij pas objecten aanmaakt wanneer ze voor het eerst aangeroepen worden. Scheelt weer in opstarttijd van je script.

edit: maar soms wil je ook wel eens alle topics van een user hebben. Ik heb dat zo opgelost (door ze los te koppelen. Je kan beiden zonder de ander gebruiken in principe) (werkt wel alleen met 5.3 en wat trucjes)
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
<?php
User_Record::prototype()->topics = function(User_Record $user) use ($topic_store)
{

    return $topic_store->find_topics_by_user($user);
};

?>

Trucje met getters, closures en late static binding in PHP 5.3. Ik voeg tijdens runtime methods aan User objecten toe om gemakkelijk bij hun topics te komen. Maar ik kan ook nog $topic_store->find_by_user($User) aanroepen. Ook weer syntactic sugar, maar ik vind $user->topics() toch leuker staan. Dit gaat echter wel weer compleet in tegen dat wat ik hierboven schreef over aan de buitenkant kunnen zien of een class iets kan. User_Record::topics() bestaat namelijk helemaal niet echt :)
Gewijzigd op 01/01/1970 01:00:00 door Jelmer -
 
Mark PHP

Mark PHP

14/06/2009 00:14:00
Quote Anchor link
Interessante materie.

Op deze manier de zaken aanpakken zit volgens mij wel muziek in. Enkel als je contexten wilt doorgeven bijvoorbeeld van de Controller naar de View wordt het wel een vager verhaal.

De view moet beschikken over bijvoorbeeld de language context, terwijl dit bij de controller niet in de context zit. Een oplossing zou zijn de view al in de frontController te setten, maar dat lijkt me niet de oplossing. En dan nog, dit probleem geldt ongetwijfeld niet alleen voor dit voorbeeld.

Verder wordt het tijd dat PHP5.3 uitkomt (sinds 11/6 RC3), namespaces bieden echt een groot voordeel (ten opzichte van o.a. de Poor Man's Namespace). Verder vind ik het dynamisch aanmaken van methoden bij objecten er veelbelovend uitzien.
Gewijzigd op 01/01/1970 01:00:00 door Mark PHP
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.