Routing methoden

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Oracle APEX developer

Wat je gaat doen: Als Oracle APEX ontwikkelaar bij DPA werk je samen met collega’s aan de meest interessante opdrachten. Je zult je ervaring met SQL, PL/SQL, JavaScript, HTML en CSS inzetten om wensen van opdrachtgevers te vertalen naar technische oplossingen. Je werk is heel afwisselend, omdat DPA zich niet beperkt tot een specifieke branche. Zo ben je de ene keer bezig binnen de zorgsector, de andere keer is dit bij de overheid. Wat we vragen: Klinkt goed? Voor deze functie breng je het volgende mee: Je hebt een hbo- of universitaire opleiding afgerond Je hebt 2 tot 5 jaar

Bekijk vacature »

Medior PHP Developer

Bij Getnoticed doen wij wat we leuk vinden, websites bouwen en online marketing. Voor veel van onze klanten doen we dan ook allebei. Wel zo fijn om campagnes te draaien voor conversiegerichte website die in eigen beheer zijn. In onze vestiging in Nederweert zitten onze development afdelingen en worden de websites gebouwd. Op dit moment zijn we op zoek naar jou: dé PHP/Back-end developer die net als wij, het hoofd boven het maaiveld durft uit te steken! In het kort Even een paar punten die omschrijven wat deze toffe baan inhoudt: Het bedenken van nieuwe functionaliteiten Het verbeteren van het

Bekijk vacature »

C# Developer

Functie omschrijving Gaat jouw hart sneller kloppen van software developen in C#.NET? Voor een softwarebedrijf in regio Den Bosch zijn wij op zoek naar een C# programmeur. Lees snel verder! Wat ga je doen? Je gaat werken met C# en ASP.NET MVC Framework om onder meer webapplicaties, webshops en websites te ontwikkelen. Je optimaliseert de bestaande software en helpt mee aan het automatiseren van bedrijfsprocessen. Je gaat samen met je collega's de juiste oplossing op basis van de wensen van de klanten uitwerken tot een mooi product. Bedrijfsprofiel Het ontwikkelen van softwareoplossingen en kantoorautomatiseringen is waar dit bedrijf voor staat.

Bekijk vacature »

PHP Web Developer

Functie omschrijving Voor een klein softwarebedrijf in de omgeving Roosendaal, zijn wij op zoek naar een PHP web developer met een aantal jaar werkervaring. Wil jij graag werken aan in-house software projecten voor diverse klanten? Voel jij je prettige in een klein team developers, waar jouw inbreng enorm gewaardeerd wordt? Lees dan snel verder! Jouw werkzaamheden zien er als volgt uit: Je wordt verantwoordelijk voor de ontwikkeling van diverse applicaties. Dit kan de ene keer een online platform voor aanbiedingen zijn, en de andere keer een software pakket dat gebruikt wordt om interne processen te automatiseren. Het zijn stuk voor

Bekijk vacature »

Senior Frontend developer

Wat je gaat doen: Of beter nog, wat wil jij doen? Bij DPA GEOS werken onze consultants als Frontend Developer in Agile teams bij onze klanten en zijn ze verantwoordelijk voor de grotere webapplicaties. Wil jij dit ook, want we zijn op zoek naar enthousiaste Frontend Developers om ons development team te versterken. Je draagt positief bij aan de teamgeest binnen een projectteam je kijkt verder dan je eigen rol. Eventueel begeleid je ook andere ontwikkelaars in het softwareontwikkelproces. Je gaat webapplicaties maken voor verschillende opdrachtgevers in jouw regio. Je bent een professional die het IT-vak serieus neemt en kwaliteit

Bekijk vacature »

Medior Java developer

Wat je gaat doen: Of beter nog, wat wil jij doen? Binnen DPA GEOS zijn we dan ook op zoek naar enthousiaste Java developers om ons development team te versterken. Als Java developer werk je in Agile/Scrum teams bij onze klanten en daarbij kun je eventueel ook andere ontwikkelaars begeleiden in het softwareontwikkelproces. Verder draag je positief bij aan de teamgeest binnen een projectteam en je kijkt verder dan je eigen rol. Je gaat software maken voor verschillende opdrachtgevers in jouw regio. Je bent een professional die het IT-vak serieus neemt en kwaliteit levert. Je leert snel vanwege je diepgaande

Bekijk vacature »

Junior/Medior Frontend Developer (React JavaScript

Bedrijfsomschrijving Voor deze opdrachtgever in Amsterdam ben ik opzoek naar een junior en/of medior frontend developer. Ervaring met React is een pre, maar geen harde eis. De organisatie maakt software voor een bouw-constructiebedrijf en doen dit met een internationaal team van ongeveer 12FTE. Het betreft een team met wisselende nationaliteiten, waarbij jouw vaardigheid in de Engelse taal ook van pas komen. Het is daarnaast een team met een prettige werksfeer, waar er veel aandacht is voor ontwikkeling. Het team staat onder leiding van twee senior fullstack ontwikkelaars die jou ook echt op weg helpen in je persoonlijke ontwikkeling. Functieomschrijving De

Bekijk vacature »

Medior Frontend developer

Wat je gaat doen: Of beter nog, wat wil jij doen? Bij DPA GEOS werken onze consultants als Frontend Developer in Agile teams bij onze klanten en zijn ze verantwoordelijk voor de grotere webapplicaties. Wil jij dit ook, want we zijn op zoek naar enthousiaste Frontend Developers om ons development team te versterken. Je draagt positief bij aan de teamgeest binnen een projectteam je kijkt verder dan je eigen rol. Eventueel begeleid je ook andere ontwikkelaars in het softwareontwikkelproces. Je gaat webapplicaties maken voor verschillende opdrachtgevers in jouw regio. Je bent een professional die het IT-vak serieus neemt en kwaliteit

Bekijk vacature »

Software Ontwikkelaar PHP

Functie omschrijving Software Ontwikkelaar PHP gezocht! Wij zijn op zoek naar een Software Ontwikkelaar die gaat bijdragen aan het verbeteren van de medicatieveiligheid voor een softwarebedrijf in de regio Nieuwegein. Voor deze functie zoeken wij een slimme en enthousiaste sollicitant die interesse heeft in farmacie, logistiek en ICT. Verder moet je beschikken over goed analytisch vermogen en ben je van nature gestructureerd en resultaatgericht. In deze functie moet je daadkrachtig, flexibel en communicatief goed zijn. Daarnaast ben je nieuwsgierig, kritisch en leergierig. Je werkzaamheden bestaan uit: Zelf de ruimte krijgen om ideeën te ontwikkelen en uit te voeren; Object georiënteerd

Bekijk vacature »

Adviseur Business IT

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 Adviseur Business IT op onze locatie Arnhem die hieraan wil bijdragen en misschien ben jij dat wel? Jouw bijdrage aan TenneT Als Adviseur Business IT ben je de brug tussen IT en de business organisatie. Je ondersteunt de Grid Field Operations Nederland (GFO-N) unit bij het in kaart brengen van IT vereisten en bij de implementeren van IT functionaliteit.

Bekijk vacature »

Software Developer Intern

Functie omschrijving We are looking for a dutch native speaker Voor een organisatie actief binnen de telecombranche zijn wij op zoek naar een Software Developer, die de interne applicaties en CRM systeem verder gaat uitbouwen en optimaliseren. Jij gaat met name de interne software via PHP verder uitbouwen. Daarnaast gebruik je ook HTML, CSS en Javascript. Verder heb je de volgende taken: Werken aan verschillende API koppelingen; Deelnemen aan overleggen met het development team; Collega's ondersteunen waar nodig; Meedenken aan verbeteringen van de interne applicaties & CRM systeem. Bedrijfsprofiel Deze organisatie is actief in het leveren van telecomservices aan klanten.

Bekijk vacature »

Senior Java developer

Wat je gaat doen: Of beter nog, wat wil jij doen? Binnen DPA GEOS zijn we dan ook op zoek naar enthousiaste Java developers om ons development team te versterken. Als Java developer werk je in Agile/Scrum teams bij onze klanten en daarbij kun je eventueel ook andere ontwikkelaars begeleiden in het softwareontwikkelproces. Verder draag je positief bij aan de teamgeest binnen een projectteam en kijk je verder dan je eigen rol. Je gaat software maken voor verschillende opdrachtgevers in jouw regio. Je bent een professional die het IT-vak serieus neemt en kwaliteit levert. Je leert snel vanwege je diepgaande

Bekijk vacature »

Magento2 Developer

Functie Ben jij een ontwikkelaar en wil jij een volgende stap zetten en als teamlead aan de slag? Lees dan snel verder! Voor een gewilde opdrachtgever in omgeving Delft zijn wij op zoek naar een programmeur die als meewerkend voorman aan de slag wilt gaan. Een developer die een team van twee man aan zal sturen. Jouw werkzaamheden zullen er als volgt uitzien; Ontwikkelen en ontwerpen van API's; Maatwerkoplossingen; Databeveiliging; Optimalisatie webshops; Ontwikkelen technische implementaties voor verbetering database; Aanspreekpunt voor de organisatie en verantwoordelijk voor de aansturing van externe developers. Zoek je veel uitdaging en veelzijdigheid in je werk dan

Bekijk vacature »

Front-end Developer

Front-end Developers opgelet! Bij Luminis zijn ze opzoek naar jou. Lees de vacature en solliciteer direct. Luminis is een software- en technologiebedrijf met meerdere vestigingen. Vanuit deze vestigingen werken 200 professionals aan technisch hoogwaardige oplossingen voor klanten zoals KLM, Nike en Bol.com. Ook ontwikkelt Luminis eigen oplossingen op het gebied van cloud, Internet of Things, data intelligence, e-sports en e-learning. Luminis onderscheidt zich door aantoonbaar voorop te lopen in technologie en innovatie. Luminis heeft drie kernpunten die verankerd zitten in alles wat we doen: het omarmen van nieuwe technologie, meesterschap en kennis delen. Functiebeschrijving First things first! Het is belangrijk

Bekijk vacature »

Oracle APEX developer

Wat je gaat doen: Als Oracle APEX ontwikkelaar bij DPA werk je samen met collega’s aan de meest interessante opdrachten. Je zult je ervaring met SQL, PL/SQL, JavaScript, HTML en CSS inzetten om wensen van opdrachtgevers te vertalen naar technische oplossingen. Je werk is heel afwisselend, omdat DPA zich niet beperkt tot een specifieke branche. Zo ben je de ene keer bezig binnen de zorgsector, de andere keer is dit bij de overheid. Wat we vragen: Klinkt goed? Voor deze functie breng je het volgende mee: Je hebt een hbo- of universitaire opleiding afgerond Je hebt 2 tot 5 jaar

Bekijk vacature »
Rob D

Rob D

09/12/2016 16:02:55
Quote Anchor link
Ik heb een tijd geleden een framework gebouwd en wil deze gaan upgraden naar een hogere PHP versie en modernere methodes.

De routing methodiek die ik nu gebruik is het volgende:
• de uri bestaat uit: http://domein.com/controller/method/param1/...
• lees de URI uit $_SERVER['REQUEST_URI']
• explode de URI in parts
• construeer het include path mbv de parts
• als de controller bestaat instantieer deze
• als de method bestaat roep deze aan met de parameters als argumenten
• bestaat de controller of method niet: 404.php

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
<?php
   $controllerFile
= "public/" . $app . "/controllers/" . $controllerPrefix . "Controller.class.php";

    if (file_exists($controllerFile)) {
        require_once $controllerFile;
    }
else {
        throw new Exception('Controller file does not exist: ' . $controllerFile);
    }


    $class = ucfirst($controllerPrefix) . 'Controller';
    if (class_exists($class)) {
        $controller = new $class();
        $controller->initLocale($country, $language);
        if (isset($urlParam) && !empty($urlParam)){
            $controller->index($controllerPrefix, $action, $urlParam);
        }
else {
            $controller->index($controllerPrefix, $action);
        }
    }
else {
        throw new Exception("Controller class does not exist") . '!';
    }

?>

Ik constateer echter dat alle bekendere frameworks, zoals Symphony, Laravel, Slim, etc een routing systeem gebruiken gebaseerd op, wat ik maar noem, een ‘hardcoded’ manier zoals in Laravel:

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php
Route::get('/', function(){}
Route::post('foo/bar', function(){}
Route::get('user/{id}', function($id){}
?>


Elk framework heeft natuurlijk zijn eigen coding style voor deze functionaliteit.

Hierdoor moet iedere route gecodeerd worden; heb ik 50 controller (niet abnormaal bij ons) moet ik 50x een get of post (of soms beide) regels coderen en dat elke keer als er een nieuwe controller wordt toegevoerd of verwijderd. Met mijn methode hoef ik dat niet en is dus veel generieker.

Mijn vraag daarom: waarom geven de framework toch voorkeur aan het uitschrijven van de uri? Anders gezegd: wat zijn de voor- en nadelen van beide methoden.

Ward:
Graag voortaan bij code de [code][/code]-tags gebruiken.
Hier kun je meer lezen over de mogelijke opmaakcodes.
Alvast bedankt!
Gewijzigd op 09/12/2016 16:07:56 door Ward van der Put
 
PHP hulp

PHP hulp

27/03/2023 13:24:34
 
Thomas van den Heuvel

Thomas van den Heuvel

09/12/2016 16:17:45
Quote Anchor link
Enkele notities:

file_exists() is i.i.g. een dure operatie. Wanneer je gebruik maakt van een autoloader dan heb je genoeg aan enkel een controle met class_exists().

Daarnaast lijkt mij isset($urlParam) && !empty($urlParam) nogal dubbelop, enkel !empty($urlParam) is genoeg, empty() heeft een isset() "ingebakken" controleert ook op het (niet) bestaan van de variabele.
Gewijzigd op 09/12/2016 16:18:58 door Thomas van den Heuvel
 
Ward van der Put
Moderator

Ward van der Put

09/12/2016 16:21:09
Quote Anchor link
Rob D op 09/12/2016 16:02:55:
Mijn vraag daarom: waarom geven de framework toch voorkeur aan het uitschrijven van de uri? Anders gezegd: wat zijn de voor- en nadelen van beide methoden.

Om bij het einde te beginnen: dat doen ze om expliciet te maken dat route /a/b/ onder verantwoordelijkheid valt van controller X en geen enkele andere controller. Daarnaast kun je dan ook nog route /c/d/ aan controller X hangen én controller X vervangen door controller Y, zonder de routes te veranderen.

In jouw oplossing kan dat niet en zijn die beslissingen allemaal impliciet én hard-coded. Als je bijvoorbeeld een route wilt wijzigen, moet je de naam van de controller wijzigen en daarmee vervolgens ook nog de bestandsnaam van het bestand waarin die controller is opgeslagen. Dat soort trapsgewijze, in de logica van de code verborgen afhankelijkheden moet je zoveel mogelijk beperken.
 
Rob D

Rob D

09/12/2016 16:32:06
Quote Anchor link
Dank je voor jullie input; ik sta voor de keuze om met een bestaand framework te gaan werken of mijn eigen
framework te verbeteren. Veel code is jaren geleden gemaakt en afgekeken van voorbeelden inclusief de fouten :(. Daarom neig ik naar een bestaand framework waar slimmere mensen dan ik aan gewerkt hebben, maar ik wil de code natuurlijk wel begrijpen.
 
Thomas van den Heuvel

Thomas van den Heuvel

09/12/2016 16:40:37
Quote Anchor link
Los daarvan (laatste alinea reactie @Ward) ben je niet vrij in de naamgeving van je URLs; je zit vast aan het <controller>/<method>[/<whatever>] stramien. Je kunt je site dan niet hiërarchisch indelen op URLs wat wel eens handig kan zijn.

Al ben ik niet zo weg van al dat soort expliciete mappings ontkoppel je je URLs wel van code.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

09/12/2016 21:37:19
Quote Anchor link
Rob D op 09/12/2016 16:32:06:
Dank je voor jullie input; ik sta voor de keuze om met een bestaand framework te gaan werken of mijn eigen
framework te verbeteren. Veel code is jaren geleden gemaakt en afgekeken van voorbeelden inclusief de fouten :(. Daarom neig ik naar een bestaand framework waar slimmere mensen dan ik aan gewerkt hebben, maar ik wil de code natuurlijk wel begrijpen.


Dat is nou precies het probleem. In plaats van bezig te zijn met het bouwen van een website zonder onder de motorkap te hoeven duiken ben je bezig met het ontwikkelen van een framework. Je kunt als individu niet alles zelf ontwikkelen of een klus komt nooit af.
Mijn inziens is het super belangrijk om voor de juiste tools te kiezen én te zorgen dat je hier snel in thuis raakt. Dat kan met wat video tuts, een boek of een heuse cursus. Dit is een kleine investering maar als je naar de uren kijkt heb je dat er zo uit.
 
Rob D

Rob D

12/12/2016 09:20:15
Quote Anchor link
Ik ben het met Frank maar deels mee eens.
Ik heb jullie misschien op heb verkeerde been gezet door met mijn vraag de indruk te wekken dat ik pas kort kom kijken in het PHP wereldje. Ik werk echter al zo'n 15 jaar met o.a. dit taaltje. Wij onderhouden al zo'n 10 jaar een framework dat wij gebruiken voor onze applicaties.
Ons framework wordt ingezet voor voor grote bedrijven wereldwijd. We praten hier niet over een website, maar over meerdere systemen met meerdere gigabytes aan code, gekoppeld aan een Oracle db met een paar honderd tabellen en een paar honderdduizende records.

Ik heb een aantal jaren geleden gekeken naar de bestaande frameworks, maar die konden toen niet de flexibiliteit leveren die wij nodig hadden en hebben. Natuurlijk blijf ik de ontwikkelingen met belangstelling volgen en ben ik geintesseerd in de methoden en technieken die gebruikt worden. Zeker als deze afwijken van methoden die wij (al jaren met succes) gebruiken.

Mijn punt:
Ja, er sluipen fouten in de code, maar die kan je in frameworks ook tegenkomen
Ja, een framework kan je helpen, maar kan je ook tegenwerken en is niet altijd zaligmakend
Ja, een framework kan je op ideeen brengen en daar kan je van profiteren
En ja, een framework kan zich over de jaren verder ontwikkelen zodat het wel een oplossing word.
Maar zelfbouw of gebruik maken van een bestaand framework zal altijd afhangen van de complexiteit, flexibiliteit en dynamiek die de markt vraagt.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

12/12/2016 10:27:53
Quote Anchor link
Ik kan me bijna niet voorstellen dat een framework als Symfony niet flexibel genoeg is.
Ik stuur zelf met enkele controllers hele websites aan. De meeste routes maak ik gewoon aan in het CMS en in technische termen wordt er voor het gros van de pagina's gebruik gemaakt van één dynamische route en één controller.
De controllers die er bij komen zijn meestal van de geïnstalleerde extra bundles. Deze bundles bieden een fortuin aan functionaliteit en zijn in enkele minuten te installeren en te configureren, wanneer je er mee bekend bent natuurlijk.

Fouten die in de code voorkomen kunnen verholpen worden. Maar je gaat problemen krijgen als je voor tientallen klanten of websites telkens dezelfde fouten moet gaan oplossen, of oplossingen niet meer compatible blijken te zijn. Dan wordt het al gauw een rommeltje. Modulair werken en versiebeheer worden dan ook heel erg belangrijk. Vraag me inmiddels af hoever jullie daar mee zijn.
 
Rob D

Rob D

12/12/2016 12:01:27
Quote Anchor link
Frank, ik denk dat je laatste vraag niet rechtstreeks met mijn oorspronkelijke vraag te maken heeft en misschien meer iets voor een ander forum. Maar ik wil je toch graag antwoorden.
Waarom denk je dat, als je niet gebruik maakt van Symphony, Laravel of Yii, dat je dan niet modulair kan werken? Wat heeft een framework te maken met Contiunues Delivery met GIT als onderdeel?
Natuurlijk werken wij met modules, imports van bestaande packages en versie beheer. Maar het hoe en welke
bepalen we nu zelf. Wij werken op onze manier al jaren, met een kleine bezetting, tot tevredenheid van onze
klanten. Wij gebruiken 1 framework voor verschillende klanten, vanuit tientallen landen, van over de hele wereld, met elk hun eigen talen en locale.
Dit kunnen wij alleen doen door zeer efficient onze software in te zetten. Echter zo'n oud systeem ontkomt niet aan de beruchte 'software rot'.

Ik kijk dus dan ook met belangstelling naar vernieuwing, waar een framework als Symphony een mogelijk goede optie is. Echter ben ik bang dat het ons, met de bezetting die we hebben en de continue oplever druk van de klant, jaren zal duren om onze code om te zetten. Dit legt een veel te grote druk op onze capaciteit. Wel wil ik onze software proberen deel voor deel om te buigen naar mainstream methoden zodat een eventuele migratiestap naar een regulier framework realistischer wordt.

Dus in theorie heb je gelijk, maar ik heb te maken met de praktijk en moet dit dus pragmatisch oplossen.


Toevoeging op 12/12/2016 12:11:09:

Nog even ter aanvulling: onze applicatie, met alle business rules, validaties, security issues, bestaat voor een zeer groot deel uit php code, webpaginas vol met javascript, Oracle stored procedures. Geen enkel framework levert mij die volledige functionaliteit, je zal die toch zelf moeten bouwen.
 
Ward van der Put
Moderator

Ward van der Put

12/12/2016 12:41:01
Quote Anchor link
Elke codebasis die 10 tot 15 jaar oud is, bevat onderdelen die (soms hopeloos) verouderd zijn. Dat geldt juist ook zeker voor PHP, want PHP 7 gebruik je anno bijna-2017 op veel onderdelen echt anders dan zo'n tien jaar geleden.

Als ik bijvoorbeeld dit zie, dan denk ik: service locator!
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
<?php
$controller
= new $class();
$controller->initLocale($country, $language);
?>

Elke controller moet apart geïnitialiseerd worden met land én taal? Zijn er dan geen controllers die prima werken zonder land en taal als twee God particles voor alles overheersende dependencies? En ook over het apart initialiseren van een controller en de rol van een constructor daarbij zijn in het laatste decennium boekwerken aan blogposts volgeschreven.

Als je dit wilt refactoren, dan zou ik waarschijnlijk niet met de routing beginnen. Begin met de fundamentelere bouwstenen, zoals gestructureerde namespaces voor core en apps en een fatsoenlijke autoloader die daarop aansluit.

Ik denk persoonlijk niet dat een PHP-framework bij zo'n grote live codebasis in combinatie met beperkte mensen en middelen (tijd!) de ideale oplossing is: dan moet je te veel ineens verbouwen.
 
Rob D

Rob D

12/12/2016 12:57:26
Quote Anchor link
Exact Ward, en dat ben ik nu aan het onderzoeken. Dat is wat ik bedoel met 'sofware rot'. Wij zijn de afgelopen jaren alleen maar bezig geweest met bouwen, bouwen en bouwen, zonder afstand te nemen van wat en waarmee we aan het bouwen zijn. We wisten dat het op een andere manier zou moeten, maar konden niet anders want we moesten overleven, dat is de praktijk.
We gaan dus nu onze software aanpakken, maar dat moet gefaseerd gaan en misschien eindigen we wel met Symphony, of eerder Laravel:)

Waar ik wel moeite mee heb is het idee, dat als je geen regulier framework gebruikt, dat je dan fout/dom bezig bent. Ik heb teveel methologien, dogma's, hypes zien komen en gaan, waaronder vele waarvan ik achteraf blij ben dat ik er in ben meegegaan. Er zijn ook genoeg grote(cms/social) producten op de markt die ook hun software baseren op eigen frameworks (en vaak niet al te mooi gebouwd).

Toch als, zoals in ieder bedrijf, standaardisatie belangrijk is het zinvol om altijd (af)kijken naar wat kant en klaar en beproeft beschikbaar is.
 
Ward van der Put
Moderator

Ward van der Put

12/12/2016 14:35:51
Quote Anchor link
Misschien moet je beginnen bij het stipje ver weg aan de horizon: wat denk je dat er allemaal is opgelost wanneer je alles hebt herschreven naar een framework van derden?

Met wat simpele basisprincipes kom je heel ver, ook zonder PHP-framework. Refactoring begint meestal met het afgaan op de stank van code smell. Gebruik je op twee plaatsen dezelfde drie SLOCs? Dan begint het te ruiken naar te vaak gedragen sokken. Heb je een methode met meer dan drie parameters? Dan doet die te veel en ruik je dat aan de zweetlucht.

Voordat je besluit welk (ander) PHP-framework veel beter is, moet je eigenlijk eerst nagaan hoe slecht je eigen framework nu is. Ik kan je het boek Refactoring van Martin Fowler aanbevelen.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

13/12/2016 13:05:07
Quote Anchor link
Beste Rob,

Ik zeg niet dat je zonder framework niet modulair of niet met versiebeheer kunt werken. Ik vroeg me enkel af of jullie dat wel deden. Hoop niet dat je me het kwalijk neemt dat ik geen enkel idee heb hoe jullie organisatie werkt :-)

Als je kunt antwoorden met Ja we hebben versiebeheer, migratie en verschillende onderdelen (blokken/bundles whatever) goed op de rails dan zal ik de laatste zijn die zegt dat je nu alle bestaande code moet gaan herschrijven om deze geschikt te maken voor welk framework dan ook.

En natuurlijk een eigen framework/systeem kan ook goed werken maar ik blijf wel van mening dat je tijd en dus geld moet investeren in het ontwikkelen maar ook in het onderhouden van een dergelijk systeem. Zo zijn er met de komst van PHP7 weer een aantal functies komen te vervallen. Maakte je daar gebruik van dan zul je dat vroeg of laat (ik denk vroeg) moeten wijzigen.

>> Nog even ter aanvulling: onze applicatie, met alle business rules, validaties, security issues, bestaat voor een zeer groot deel uit php code, webpaginas vol met javascript, Oracle stored procedures. Geen enkel framework levert mij die volledige functionaliteit, je zal die toch zelf moeten bouwen.

Dat klopt. Maar er zijn wel frameworks die je een goede structuur aanbieden waar je al deze onderdelen in kunt onderbrengen en nog eens kunt hergebruiken ook.

Cheers
 
Thomas van den Heuvel

Thomas van den Heuvel

13/12/2016 14:31:35
Quote Anchor link
Waarom moet het altijd of vanille- of chocolade-vla zijn? :/

Maak/doe eens een uitstapje/onderzoek en/of draai een project met een ander framework. Wie weet steek je er iets van op.
Gewijzigd op 13/12/2016 14:32:57 door Thomas van den Heuvel
 
Mr Beronne

Mr Beronne

13/12/2016 20:51:11
Quote Anchor link
Ik weet wel dat met een Framework (mits je deze onder de knie hebt), het ontwikkelen stukken sneller gaat. Het kost alleen even tijd om je te verdiepen in een framework wat zich uiteindelijk terugbetaald in
- rapid development
- code reuse
- template engine (html/php)
- handige ingebouwde functies zoals:
- snel databases en tabellen aanmaken
- queries schrijven
- onderlinge relaties met tabellen.
- onderscheidt tussen dev en live
- meestal een handige debugger
- etc...

Zo kan ik het lijstje nog wel even blijven aanvullen :)

Maar ik snap dat het lastig qua tijd en groei om alles te moeten overzetten naar een framework.
 
Rob D

Rob D

13/12/2016 22:07:32
Quote Anchor link
Hi Frank en Mr. Beronne,

Ik begrijp en ondersteun je punt over het gebruik van framework. Wat ik duidelijk wil maken is dat we wel een framework hebben. Een framework dat ik samen met een collega ruim 10 jaar geleden heb gebouwd.
Dat is wat ik ook aangaf in de 1e regel van mijn oorspronkelijke vraag.

Dit 'framework' is een MVC gebaseerd systeem, met routing, security modules, database abstractie (adodb), een mailer syteem. Geen template systeem voor de views, maar een page/form generatie systeem gebaseerd op phphtmllib, etc., etc.
Misschien is het in het verhaal belangrijk te weten dat we jaren geleden uit een volledige Oracle omgeving kwamen en onze programmeurs evenveel weten als de doorsnee DBA. Databases en queries maken zijn onze dagelijks brood. Wij maken geen websites, maar een complex transactie systeem, met honderden views en tabellen.

Dit systeem is echter verouderd en uit zijn voegen gegroeid maar in principe kan het alles en voldoet nog ruim aan de eisen van de markt. Ik heb reeds een nieuw framework gebouwd, maar eenvoudiger, meer op moderne principes, om onze apps 'leaner and meaner' te maken. Daarom kijk ik nu naar wat er in de php wereld is vernieuwd.

Mijn keus is dus: wat ga ik doen, ons nieuwere framework complient maken met de laatste stand van zaken in de php wereld (wat mijn programmeurs hart wil) of het adapteren van een bestaand framework dat zich reeds heeft bewezen in de markt (wat mijn managers hart wil).

Ons eigen framework voldoet en heeft zich bewezen; wij weten hoe we een framework moeten maken; zodra de basis er staat wordt die over de jaren nauwelijks nog gewijzigd. De functionele software (forms, javascript, db tables, business rules, proces flow, calculaties, gegenereerde pdf's en excel docs, (rest/soap) interfacing, etc) wordt bij ons wel dagelijks voor de ene of andere klant onder handen genomen. Dat levert een framework niet, maar is de eigenlijk core van elk systeem.
Vandaar dat ik mij niet zo druk maak over wat een framework voor ons mogelijk sneller kan doen; daar zit onze tijd niet in.

Waar het mij om gaat is om onze manier van bouwen mee te laten groeien met wat de markt doet. Als er iets beters, makkelijk of sneller is wil ik dat adapteren (ook als dat een nieuw framework betekent). Ik merk zowiezo al dat ik weer nieuwe dingen kan leren en ben daarom ook zeer blij met jullie input.


Toevoeging op 13/12/2016 22:32:28:

Thomas, ik zat te denken om een klein project te beginnen met Slim en die aan te vullen met de modules die ik nodig heb. Zo leer ik de pro's en cons stap voor stap. Maar misschien is het beter om meteen te beginnen aan een framework zoals Laravel of Symphony ...

Toevoeging op 14/12/2016 09:53:40:

Thomas, om even terug te komen op je opmerking over de empty() functie. Volgens mij test deze functie niet of de variabele bestaat.

Als bijv. $tstVar niet bestaat zal empty($tstVar) == true geven, terwijl isset($tstVar) == false geeft.
empty() geeft in dat geval geen melding, waar isset() dat wel doet.
 
Ward van der Put
Moderator

Ward van der Put

14/12/2016 11:29:51
Quote Anchor link
Thomas doelde op de vaak gebruikte constructie if (isset($var) && !empty($var)) voor "als de variabele bestaat en de variabele niet leeg is". Dat zijn twee of drie logische evaluaties waar je met één evaluatie kunt volstaan, want:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
<?php
var_dump(  empty($nonexistent) );  // bool(true)
var_dump( !empty($nonexistent) );  // bool(false)
var_dump(  isset($nonexistent) );  // bool(false)
?>
Gewijzigd op 14/12/2016 11:32:45 door Ward van der Put
 
Rob D

Rob D

14/12/2016 12:53:13
Quote Anchor link
Ja, het kwartje is gevallen, ik snap het.

Dank julle beide.
 
Ozzie PHP

Ozzie PHP

14/12/2016 15:22:46
Quote Anchor link
Rob D op 13/12/2016 22:07:32:
Mijn keus is dus: wat ga ik doen, ons nieuwere framework complient maken met de laatste stand van zaken in de php wereld (wat mijn programmeurs hart wil) of het adapteren van een bestaand framework dat zich reeds heeft bewezen in de markt (wat mijn managers hart wil).

Een programmeur: wil een gedegen, flexibel en stabiel systeem
Een manager: wil zo snel mogelijk een werkende oplossing

Kiezen voor een bestaand systeem is leuk, maar de leercurve van zo'n systeem is bijzonder groot. Weet je eindelijk na een jaar hoe alles een beetje werkt, komt er een nieuwe versie en werkt alles ineens anders. Of ... na 2 jaar besluiten de makers ineens om het systeem niet verder door te ontwikkelen. En dan?

Als ik jou zo hoor dan gaat het bij jullie om je core business. Ik zou me daarbij nooit afhankelijk maken van een extern framework. Wat zeg je straks als er iets niet werkt (vanwege een lek)? Geef je dan dat externe framework de schuld? In jouw geval zou ik dus altijd ervoor kiezen om je eigen framework te maken. Op de lange termijn is dat de veiligere oplossing.
 
Rob D

Rob D

15/12/2016 09:04:58
Quote Anchor link
Deze hele discussie geeft al aan dat een keuze voor een externe (of interne) systeem geen vanzelfsprekendheid is.

Als ik naar bijv. het routing systeem kijk van Slim of Laravel dan zijn die superflexibel, maar die flexibiliteit kan ook leiden naar onduidelijkheid. De ontwikkelaars willen een strakke, heldere methodiek, dat altijd werkt als je je maar aan de regels houdt.

De keuze is enerzijds lastig omdat ik niet voor Laravel wil kiezen en er dan achter komen dat ik eigenlijk Symphony nodig had. We hebben geen tijd om al die frameworks uit te proberen.
En van de andere kant heb ik een luxe positie, omdat we een systeem hebben dat werkt. Het huidige systeem is ontstaan door af te kijken en te nemen wat voor ons werkt, waarom zouden we dat dan nu ook niet doen.

Hoe dan ook is het een feit dat in de moderne frameworks veel best practices zitten die waard zijn om te gebruiken. Ook moet je rekening houden met het feit dat huidige frameworks veel modules bevatten die gemakkelijk zijn over te nemen of waar alternatieven voor bestaan.

Kortom, ik hoop door middel van een paar kleinere projectjes met verschillende frameworks een gevoel te krijgen welke kant we op gaan.
 



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.