autoloader

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Java developer - procesoptimalisatie (Inhouse)

Functie Wat ga je doen als Java developer? Jij als back end developer hebt al enige ervaring opgedaan in jouw vakgebied. Voornamelijk het werken met Java en Spring spreekt jou aan. Jij wordt samen met je collega developers in het team verantwoordelijk voor de gehele back end van de applicatie. Hierdoor heb jij veel zelfstandigheid in je rol en zul je ook zelf beslissingen samen met de PO maken. Er wordt gewerkt volgens de SCRUM methodiek, om zo structuur te creëren in de werkzaamheden. Binnen de 2-wekelijkse sprints pak jij je taken op die samen met de PO afgestemd zijn.

Bekijk vacature »

Softwareontwikkelaar Cleopatra

Functieomschrijving Voor de gemeente Amsterdam zijn wij op zoek naar een softwareontwikkelaar Cleopatra. De directie Verkeer en Openbare ruimte van de gemeente Amsterdam beschikt over een softwareapplicatie, "Cleopatra", waarmee geautomatiseerde handhaving plaatsvindt (op basis van kentekenherkenning) van bepaalde gebieden waarin toegangseisen worden gesteld aan het verkeer. Voorbeelden ervan zijn de milieuzones, de zone zwaar verkeer, handhaving van brom- en snorfietser op het fietspad en autoluwe gebieden. Voor de doorontwikkeling en uitbreiding ervan zijn gespecialiseerde softwareontwikkelaars nodig die helpen bij het programmeren van de handhavingsmodules voor nieuwe gebieden en het verbeteren en bijwerken van de bestaande onderdelen van de softwareapplicatie. Functie

Bekijk vacature »

Software Developer .NET

Functie omschrijving .NET developer gezocht! Wij zoek op zoek naar een .NET Developer die zich niet uit het veld laat slaan voor een software bedrijf in de regio Veenendaal. Je gaat in deze functie aan de slag met het door ontwikkelen van bestaande producten en het ontwikkelen van nieuwe producten. Dit bedrijf ontwikkeld SaaS applicaties die zowel intern als extern gebruikt worden. Verder bestaat je functie uit: Het ontwikkelen en bouwen van webapplicatie, mobiele applicaties en websites vallen onder jouw verantwoordelijkheden; Werken met onder andere .NET, C#, HTML/CSS, Javascript en MSSQL/Oracle Databases; Hierin werk je samen met andere developers en

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 »

Senior Front-end Developer

Dit ga je doen Met behulp van diverse programmeertalen ontwikkelen van Front-end software; Het begeleiden van het front-end team; Het oplossen van incidenten; Het bijhouden van een backlog; Je hebt een actieve bijdrage in de wekelijkse overleggen met de omliggende teams; Je houdt trends bij en adviseert het management hierover waar nodig; Helder communiceren met de stakeholders om hen zo mee te nemen in projecten en laten inzien wat de duur en toegevoegde waarde van bepaalde projecten is. Hier ga je werken Deze organisatie heeft circa 40 miljoen bezoekers per maand en heeft innovatie hoog in het vaandel staan. Het

Bekijk vacature »

Junior Outsystems developer

Functie Als junior Outsystems developer wordt jij onderdeel van een multidisciplinair team van 23 software engineers. Ons team werkt agile en termen als Continuous Integration en Continuous Delivery zijn bij ons dagelijkse koek. Wij werken aan uitdagende en afwisselende projecten met als doel onze klanten een totaal oplossing aan te bieden. Als junior Outsystems developer krijg jij bij ons de kans om jezelf te ontwikkelen naar een volwaardige ervaren en gecertificeerde Outsystems developer. Jij een team met ervaren mensen (10+ ervaring) om je heen. Zo heb jij niet het gevoel dat jij meteen in het diepe wordt gegooid en uiteraard

Bekijk vacature »

.Net Front-end Ontwikkelaar

Wij zoeken een .Net Front-end Ontwikkelaar! Omschrijving Kun jij snel schakelen en ben je stressbestendig? Dan zoeken wij jou! Als .Net Front-end Ontwikkelaar help je mee aan de webapplicatie die over de hele wereld door allerlei bedrijven wordt gebruikt. Je werkt daarnaast mee aan nieuwe en verbeterde functionaliteiten en helpt met het oplossen van bugs. Over de opdrachtgever Je komt te werken in een ambitieus team dat zich blijft ontwikkelen. Dit is alle informatie die we nu kunnen delen over de werkplek. Als jij de .Net Front-end Ontwikkelaar bent voor deze job, vertellen we je snel nóg meer. Eisen Heb

Bekijk vacature »

Front end developer

Functie Binnen de functie van Front-end developer werk je mee aan uitdagende klantprojecten. In teamverband werk je aan de voorkant van onze state-of-the-art portaal oplossingen en apps. Dit alles gebeurt in een multidisciplinaire omgeving waarbij je de ruimte hebt om te sparren, je ideeën scherp te stellen, en waar je met de benodigde kennis en ervaring om je heen altijd terecht kunt bij je collega’s voor vragen en ondersteuning. Meestal werk je vanuit ons kantoor maar we bieden ook alle faciliteiten om thuis te kunnen werken. Voor sommige projecten ga je mee naar de klant, wellicht zelfs in het buitenland!

Bekijk vacature »

Software Programmeur

Functie omschrijving Voor onze opdrachtgever in omgeving Rotterdam zijn wij opzoek naar een software programmeur die goed kan schrijven in de talen C of C++ en die het leuk vind om te werken met Linux! Werkzaamheden Programmeur Je bent bezig met het ontwikkelen van software en webapplicaties. Je kunt technische klussen uitvoeren op locatie. Je onderhoudt contact met de projectleider om er zeker van te zijn dat een project goed verloopt. Je zult klanten ondersteunen. Verder zul je technische ontwerpen en gebruikersdocumentaties schrijven en deze onderhouden. Bedrijfsprofiel Dit bedrijf wil de klanten een volledige oplossing kunnen bieden, waarbij ze een

Bekijk vacature »

.NET Developer gezocht!

Functie omschrijving Wij zijn op zoek naar een .NET Developer! Wil jij werken voor een internationaal bedrijf waar je legio mogelijkheden krijgt als Software Ontwikkelaar? Grijp nu je kans en kijk snel of jouw vaardigheden aansluiten bij onderstaand profiel! Je kunt een uitdagende rol gaan vervullen als .NET Developer binnen een internationaal bedrijf dat gevestigd is in omgeving Bergen. Dit bedrijf is zeer vooruitstrevend en verricht betekenisvol werk. Binnen dit bedrijf wordt gewerkt aan de productie en ontwikkeling van medische middelen. Als .NET Developer ga jij je bezig houden met het volgende: Je wordt betrokken bij alle fasen van software

Bekijk vacature »

Software 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 »

.NET developer WO niveau voor predictive software

Bedrijfsomschrijving Dit bedrijf uit Den Bosch is om precies te zijn 15 medewerkers groot en ze ontwikkelen (predicitve) planning software. Dit doen zij voor allerlei mooie en bekende organisaties (bierbrouwerijen, gemeentes, oliemaatschappijen en diverse multinationals). Wegens meer en grotere vraag vanuit de klanten komen er nu posities vrij voor onder andere een .NET developer. Het bedrijf is goed met openbaar vervoer te bereiken. Functieomschrijving Je komt hier te werken in een team van 3 .NET developers en bent betrokken bij het gehele ontwikkelproces. Dus van idee naar ontwerp en van ontwikkeling tot testen en implementatie. Bij voorkeur ben je niet

Bekijk vacature »

Medior/senior Back-end developer gezocht!

Functie Vanwege de groei binnen het bedrijf zijn we op zoek naar versterking in het devlopmenttean. Als back-end developer bouw je aan de bedrijfssoftware die ons helpt bij de primaire processen. Een leuk (intern) project dus waarbij je de software continu doorontwikkeld! Je werkt in een klein team, we hebben dagelijks stand-ups en iedere twee weken een scrum-sessie, begeleid door onze Scrum Master. Hierin krijg je uitgebreid de kans om je ideeën te presenteren, en te overleggen met je mede-ontwikkelaars en de Product Owner. Binnen de ontwikkelteams gebruiken we Trello, Gitlab, Jiira, Confluence en Boockstack. Hiernaast werken ze met de

Bekijk vacature »

Front-End React Developer

As a Front-End React Developer you improve the user-experience of our web applications for your colleagues in Coolblue. How do I become a Front-End React Developer at Coolblue? As a Front-End React Developer you are responsible for developing user interface components and implementing them using React.js concepts and workflows. You work with the UX Designer and get energy from coming up with creative solutions and present these within the team. During the day you gather and welcome feedback on your technical and soft skills. Would you like to become a Front-End React Developer at Coolblue? Read below if the job

Bekijk vacature »

Back-end .NET Developer

Functie omschrijving C# / .NET Developer gezocht voor een dynamische organisatie in de regio Houten! Voor een leuke organisatie in de regio Houten zijn wij op zoek naar een Back-end developer die klaar is voor een nieuwe uitdaging. In deze functie werk jij aan verschillende projecten en ga je vaak bij klanten op bezoek. Binnen deze functie kun je een grote mate van uitdaging, diversiteit en verantwoordelijkheid treffen. Bedrijfsprofiel Waar ga je werken? Het bedrijf waar je gaat werken is gespecialiseerd in het ontwerpen en implementeren van procesautomatisering en procesinformatisering. Zij doen dit onder andere voor de (petro)chemie, pharma, infra,

Bekijk vacature »

Pagina: 1 2 volgende »

Ozzie PHP

Ozzie PHP

05/10/2013 00:31:10
Quote Anchor link
Ola,

Ik ga een autoloader maken die automatisch classes inlaadt. Nu wil ik gaan werken met een library met classes, maar naast die library wil ik ook gaan werken met "modules" die een eigen controller en model hebben. Behalve de classes uit de library hebben we dus ook controllers en models.

Nu vraag ik me af of het wijs/handig is om de models en controllers ook via de autoloader te laden. Stel we hebben een class "Product", en een bijbehorende module Product met daarin een ProductController en een ProductModel. Stel dat ik dan een nieuwe ProductController nodig heb, dan zou ik kunnen zeggen:

$product_controller = new ProductController();

De autoloader ziet nu dat de class-naam eindigt op "Controller" en weet dus dat het de bedoeling is om een controller in te laden.

Het feit is echter wel dat in 1 page request misschien wel tientallen classes moeten worden ingeladen, maar slechts enkele controllers/models.

Door nu telkens te controleren of de clas-naam eindigt op "Controller" of "Model" (wat in 90% van de gevallen niet zo zal zijn) vertraag ik de boel dus behoorlijk.

Nu is mijn vraag, is er een hele slimme/snelle manier om te controleren of de class-naam eindigt op "Controller" of "Model", of wordt dat sowieso een kwestie van substrings vergelijken? En mijn 2e vraag, zou het beter zijn om de controllers en models via een method in te laden in plaats van via de autoloader, zoiets als:

$product_model = $this->loadModel('Product');

Reacties zijn welkom!
Gewijzigd op 05/10/2013 00:34:03 door Ozzie PHP
 
PHP hulp

PHP hulp

28/04/2024 00:26:24
 
Wouter J

Wouter J

05/10/2013 01:01:16
Quote Anchor link
Zucht... snelheid. String functies (zoals substr) zijn de snelste PHP functies, wees niet bang en gebruik ze gewoon...

Daarnaast kijk eens naar PSR-0 en PSR-4, die bevatten wel mooie richtlijnen voor het schrijven van een autoloader. En ja, ALTIJD autoloader gebruiken.
 
Ozzie PHP

Ozzie PHP

05/10/2013 01:06:02
Quote Anchor link
okidokiej :)
thanks!
 
- Raoul -

- Raoul -

05/10/2013 02:29:53
Quote Anchor link
Waarom gebruik je niet gewoon de autoloader van Composer?
 
Ward van der Put
Moderator

Ward van der Put

05/10/2013 11:10:09
Quote Anchor link
Ozzie PHP op 05/10/2013 00:31:10:
Nu vraag ik me af of het wijs/handig is om de models en controllers ook via de autoloader te laden. Stel we hebben een class "Product", en een bijbehorende module Product met daarin een ProductController en een ProductModel. Stel dat ik dan een nieuwe ProductController nodig heb, dan zou ik kunnen zeggen:

$product_controller = new ProductController();

De autoloader ziet nu dat de class-naam eindigt op "Controller" en weet dus dat het de bedoeling is om een controller in te laden.

De autoloader hoeft niets te "zien" of te "weten", maar laadt gewoon automatisch Product.php of ProductController.php of ProductModel.php zodra je één van de klassen gebruikt. Het hele eiereneten bij een autoloader is juist dat je niet eerst van alles gaat zitten laden, maar pas iets laadt wanneer het nodig is.

Ik gebruik zelf inderdaad de autoloader uit PSR-0 met een kleine aanpassing. Dan moet je echter ook wel kiezen voor namespaces.
 
Wouter J

Wouter J

05/10/2013 13:18:07
Quote Anchor link
" Dan moet je echter ook wel kiezen voor namespaces."

Hoeft niet, ook de PEAR methoden worden nog ondersteund.
 
Ward van der Put
Moderator

Ward van der Put

05/10/2013 13:44:51
Quote Anchor link
Wouter, er is een duidelijke overlapping in de strategieën voor autoloading. PSR-0 formaliseert de status quo die we deels van PEAR kennen, zodat de interoperabiliteit verhoogd wordt.

Maar je hebt verder wel gelijk: ik vind dat je anno 2013 namespaces moet gebruiken, dus dat is zeker een waardeoordeel.
 
Ozzie PHP

Ozzie PHP

05/10/2013 15:50:29
Quote Anchor link
Ward van der Put op 05/10/2013 11:10:09:
De autoloader hoeft niets te "zien" of te "weten", maar laadt gewoon automatisch Product.php of ProductController.php of ProductModel.php zodra je één van de klassen gebruikt. Het hele eiereneten bij een autoloader is juist dat je niet eerst van alles gaat zitten laden, maar pas iets laadt wanneer het nodig is.

Ward, ik snap niet precies wat je hiermee wilt zeggen. Een autoloader treedt pas in werking op het moment dat er een class wordt aangeroepen die nog niet is ingeladen. Ik ga toch niet "van alles zitten laden"? Ik denk dat je me niet helemaal correct begrepen hebt.

Ik heb vroeger wel eens gewerkt met Zend Framework 1 en ik vind de manier van class benamingen (met underscores) wel fijn. Die namespacing dat bevalt me op de een of andere manier niet en dus hou ik het graag bij de "oude" manier. De autoloader weet aan de hand van een class-naam welk bestand hij moet inladen. En daar ging mijn vraag dus over. 95% van de classes die ik zal inladen zal een normale library class zijn. 5% zal een controller of model zijn (deze staan in een andere directory dan de library classes). Als ik controllers en models ook via de autoloader inlaadt, dan betekent dit dat er in 95% van de gevallen onnodig zal worden gecontroleerd of het om een controller of model gaat. Is dat wel slim is mijn vraag. Of moet ik de controllers en models via een aparte functie aanroepen (en dus niet via de autoloader). Dat is mijn vraag.
Gewijzigd op 05/10/2013 15:52:40 door Ozzie PHP
 
NOLot -

NOLot -

05/10/2013 16:22:43
Quote Anchor link
Als jij een namespace en een bijbehorende directory toevoegt, kun je een hele simpele check maken bij het laden van je class. Je loopt door al je toegevoegde directories heen, en pas zodra de namespace hetzelfde is ga je checks doen van file_exists enzo.

Symfony doet het ook: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/ClassLoader/UniversalClassLoader.php#L295

Op die manier geldt dat "onnodig controleren" ook niet echt, aangezien hij al meteen na de if statement afkapt

Edit: en als antwoord, one autoloader to rule them all...
Gewijzigd op 05/10/2013 16:24:19 door NOLot -
 
Ozzie PHP

Ozzie PHP

05/10/2013 16:29:18
Quote Anchor link
NOLot, thanks... maar ik ben niet gewend met namespaces te werken, en ik snap het principe ook niet zo goed.

Stel ik heb een fictieve class, een xml loader. Bij mij zou die dan in de library komen te staan in de directory "xml". zoiets als dit:

/library/xml/loader.php

De class-naam zou dan zijn xml_loader. Als ik de xml loader zou nodig hebben, dan doe ik dit:

$xml_loader = new xml_loader();

Aangezien de class nog niet is geladen, wordt de autoload functie geactiveerd. Aan de hand van de class-naam "xml_loader" gaat deze automatisch het juiste bestand "/library/xml/loader.php" inladen.

Zo is hoe ik het nu ongeveer doe.
 
Ward van der Put
Moderator

Ward van der Put

05/10/2013 16:33:02
Quote Anchor link
De autoloader laadt elke klasse. Wanneer die nodig is. Zodra die nodig is.

Waarom moet de autoloader dan controleren om welke type klasse het gaat? Dat is niet de taak van de autoloader: andere klassen bepalen welke klassen zij nodig hebben, de autoloader laadt ze vervolgens alleen maar.
 
NOLot -

NOLot -

05/10/2013 16:40:51
Quote Anchor link
Ozzie PHP op 05/10/2013 16:29:18:
NOLot, thanks... maar ik ben niet gewend met namespaces te werken, en ik snap het principe ook niet zo goed.

Stel ik heb een fictieve class, een xml loader. Bij mij zou die dan in de library komen te staan in de directory "xml". zoiets als dit:

/library/xml/loader.php

De class-naam zou dan zijn xml_loader. Als ik de xml loader zou nodig hebben, dan doe ik dit:

$xml_loader = new xml_loader();

Aangezien de class nog niet is geladen, wordt de autoload functie geactiveerd. Aan de hand van de class-naam "xml_loader" gaat deze automatisch het juiste bestand "/library/xml/loader.php" inladen.

Zo is hoe ik het nu ongeveer doe.


Dat voorbeeld ging niet over namespaces, maar classes met underscore.

Als jij je classes xml_loader noemt dan wordt het wel even zoeken ja voor de autoloader. Vooral als je dan ook je controllers home_indexcontroller noemt. Maar uiteindelijk is een autoloader altijd beter dan geen autoloader
 
Ozzie PHP

Ozzie PHP

05/10/2013 16:42:39
Quote Anchor link
"De autoloader laadt elke klasse. Wanneer die nodig is. Zodra die nodig is."
Dit is geheel duidelijk.

"Waarom moet de autoloader dan controleren om welke type klasse het gaat?"
Hij moet dat weten, omdat een model of controller in een andere map dan de library staat. Hij moet dus een ander pad aanroepen.

"Standaard" classes staan in de map library, maar een model staat in map foo, en een controller in map bar. De autoloader moet dus (aan de hand van de class-naam) weten waar hij het bestand moet zoeken. Is het zo duidelijker wat ik bedoel?

Toevoeging op 05/10/2013 16:46:07:

"Als jij je classes xml_loader noemt dan wordt het wel even zoeken ja voor de autoloader."

Nee, juist niet. Het geeft precies aan waar hij moet zoeken.
 
Ward van der Put
Moderator

Ward van der Put

05/10/2013 16:49:38
Quote Anchor link
Lees PSR-0 dan eens goed?! Die recommendation slaat een brug tussen namespaces en underscores.

OzzieCore_Product_Controller == /OzzieCore/Product/Controller.php
OzzieCore_Product_Model == /OzzieCore/Product/Model.php

Het is twee handen op één buik. Het werkt als je geen namespaces gebruikt. En het blijft werken als je alsnog namespaces gaat gebruiken. Het werkt zelfs in een gemengde omgeving, als je iets van een ander inhaakt op je eigen project.
 
Ozzie PHP

Ozzie PHP

05/10/2013 16:52:45
Quote Anchor link
Ward thanks, maar ik snap niet hoe dat namespacing werkt.

OzzieCore_Product_Controller == /OzzieCore/Product/Controller.php

Is "OzzieCore_Product_Controller" de class-naam? En wat is het verschil met namespacing en hoe ik het nu doe?
 
NOLot -

NOLot -

05/10/2013 17:12:42
Quote Anchor link
Ozzie PHP op 05/10/2013 16:42:39:
"Als jij je classes xml_loader noemt dan wordt het wel even zoeken ja voor de autoloader."

Nee, juist niet. Het geeft precies aan waar hij moet zoeken.


Nee juist niet :) Omdat jij geen namespaces gebruikt zul je dus je classes moeten prefixen met library_xml_loader en controller_home_indexcontroller als je niet wilt dat je autoloader nutteloos directories door gaat zoeken
 
Ward van der Put
Moderator

Ward van der Put

05/10/2013 17:19:37
Quote Anchor link
NOLot - op 05/10/2013 17:12:42:
Omdat jij geen namespaces gebruikt zul je dus je classes moeten prefixen met library_xml_loader en controller_home_indexcontroller als je niet wilt dat je autoloader nutteloos directories door gaat zoeken

Je hoeft geen include_path te gebruiken. Je kunt de autoloader ook direct op een specifiek bestand afsturen. Alleen... dat werkt veel makkelijker als je een namespace-achtige directorystructuur gebruikt. Dan kun je de underscore _ vervangen door de constante DIRECTORY_SEPARATOR.

Mijn autoloader ziet er als volgt uit. PSR-0 met twee kleine extra's.

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
<?php
/**
 * AutoLoader
 *
 * Load by vendor\class or by namespace\class:
 *
 *     autoload('StoreCore_Database');
 *
 * Load by namespace\package\class, by vendor\package\class,
 * or by package\subpackage\class:
 *
 *     autoload('StoreCore_Payments_iDEAL');
 *
 * @author  Ward van der Put <[email protected]>
 * @link    https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md
 * @param   string $classname
 * @return  void
 * @version 1.0
 */

function autoload($classname)
{

    $classname = ltrim($classname, '\\');
    $filename  = '';
    $namespace = '';
    if ($last_namespace_position = strrpos($classname, '\\')) {
        $namespace = substr($classname, 0, $last_namespace_position);
        $classname = substr($classname, $last_namespace_position + 1);
        $filename  = str_replace('\\', DIRECTORY_SEPARATOR, $namespace) . DIRECTORY_SEPARATOR;
    }

    $filename .= str_replace('_', DIRECTORY_SEPARATOR, $classname) . '.php';

    /**
     * De volgende aanvulling op het voorbeeld van de functie autoload() uit
     * PSR-0 maakt het pad naar het bestand met een klasse absoluut in plaats
     * van relatief.  Dit verkort de laadtijd.
     */

    $filename = __DIR__ . DIRECTORY_SEPARATOR . $filename;

    require $filename;
}


/** Register the autoloader */
spl_autoload_register('autoload');
?>
Gewijzigd op 05/10/2013 17:20:06 door Ward van der Put
 
Ozzie PHP

Ozzie PHP

05/10/2013 17:24:33
Quote Anchor link
@NOLot:

Ah, nu begrijp je me! :)

Ja, daar heb je gelijk in. Mijn idee was dus... alle classes staan in de library, dus hoef ik de class-naam niet te prefixen met library. Echter, als ik dus ook models en controllers ga gebruiken die in een andere directory staan wordt het een ander verhaal... Dan zou ik zoals jij zegt dit kunnen doen:

"controller_home_indexcontroller"

Of... ik laat de class-naam eindigen op "controller".

"home_indexcontroller"

Ik controleer dan of de class-naam eindigt op "controller" (of op "model") en zo ja, dan weet ik dat ik niet de library directory moet gebruiken, maar de model of controller directory. Maar dit kost dus wel telkens 2 extra controles, namelijk "eindigt de class-naam op model, zo nee... eindigt de class-naam op controller, zo nee... aha, dan ben ik dus een library class".

Ik ben in ieder geval blij dat jij nu precies begrijpt wat ik bedoel.

Is er dan een manier waarop namespaces me gaan helpen? En zo ja... kun je een klein voorbeeldje geven, zodat ik het principe snap?

@Ward:

Thanks, maar ik snap het principe van die namespaces nog niet. Wat is nou eigenlijk een namespace, en wat is het voordeel ten opzichte van hoe ik het nu doe (via de oude manier)?
 
Wouter J

Wouter J

05/10/2013 17:27:37
Quote Anchor link
Ozzie, en wat als je nou buiten het framework om andere klassen gaat aanmaken dan controllers en models? Dan weet de autoloader totaal niet meer waar je moet zoeken.

Dan kun je dus 2 dingen doen: Een autoloader voor je library maken en een autoloader voor je project klassen. dit kan best.
Of je zorgt ervoor dat de autoloader deze al uit zichzelf uit elkaar houdt doordat je ze prefixed met een zogenaamde 'vendor' naam. Bijv. library_xml_reader en ozzie_xml_reader. De eerste zou worden gezocht in library/xml/reader.php en de andere in ozzie/xml/reader.php

Merk overigens op dat xml_reader ook al een namespace is.

Offtopic:
Ward, de PSR-0 namespaces waren eerst de PEAR autoloading, dus Ozzie_Xml_Reader -> Ozzie/Xml/Reader.php De PSR-0 namespaces zijn later aangepast, toen PHP5.3 namespaces ging ondersteunen: Ozzie\Xml\Reader -> Ozzie/Xml/Reader.php

PSR-4 is nu bijna officieel en daarin gaat het nog een stapje verder, door te doen wat de composer autoloader doet: Werken met package en vendor namen. Stel je hebt een pagina "config" met de vendor "ozzie" dan wordt een klasse Ozzie\Config\Xml\Reader.php gezocht in ozzie-config/Xml/Reader.php
 
Ozzie PHP

Ozzie PHP

05/10/2013 17:35:01
Quote Anchor link
Wouter, thanks.

"Of je zorgt ervoor dat de autoloader deze al uit zichzelf uit elkaar houdt doordat je ze prefixed met een zogenaamde 'vendor' naam. Bijv. library_xml_reader en ozzie_xml_reader."

Maar dit betekent simpelweg dat ik mijn class dus niet xml_reader noem, maar library_xml_reader?

Dus:

$xml_reader = new library_xml_reader();

Zo bedoel je? (en is dit dan wat je noemt namespacing?)
 
NOLot -

NOLot -

05/10/2013 17:37:09
Quote Anchor link
Ozzie PHP op 05/10/2013 17:24:33:
@NOLot:

Ah, nu begrijp je me! :)

Ja, daar heb je gelijk in. Mijn idee was dus... alle classes staan in de library, dus hoef ik de class-naam niet te prefixen met library. Echter, als ik dus ook models en controllers ga gebruiken die in een andere directory staan wordt het een ander verhaal... Dan zou ik zoals jij zegt dit kunnen doen:

"controller_home_indexcontroller"

Of... ik laat de class-naam eindigen op "controller".

"home_indexcontroller"

Ik controleer dan of de class-naam eindigt op "controller" (of op "model") en zo ja, dan weet ik dat ik niet de library directory moet gebruiken, maar de model of controller directory. Maar dit kost dus wel telkens 2 extra controles, namelijk "eindigt de class-naam op model, zo nee... eindigt de class-naam op controller, zo nee... aha, dan ben ik dus een library class".

Ik ben in ieder geval blij dat jij nu precies begrijpt wat ik bedoel.

Is er dan een manier waarop namespaces me gaan helpen? En zo ja... kun je een klein voorbeeldje geven, zodat ik het principe snap?


Ik begreep de hele tijd al wat je bedoelde, echter vraag je iets te veel en probeer je iets te weinig naar mijn mening.

De fix die je doet is het toevoegen van de namespace Model, Controller en Library. OF je prefixt al je classes met model_core_user, controller_home_homecontroller, library_xml_loader. Namespaces is nieuwer, beter en duidelijker, dus ik zou voor die optie gaan. Dan heb je die 3 folders, Model, Controller en Library. Je autoloader stop je dan in dezelfde directory als die 3 folders, met dit erin

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
<?php
spl_autoload_register(function($clazz) {
    $file = __DIR__ . DIRECTORY_SEPARATOR . str_replace('\\', DIRECTORY_SEPARATOR, $clazz) .'.php';
    if (file_exists($file))
        require $file;
});
?>


En klaar, al je files worden autoloaded zonder enige vorm van "opzoeken".

Natuurlijk wil je later je folders op een andere plek neerzetten, dat is het moment dat je namespace => directory array's wil toevoegen, en een autoloader class wil maken. Maar zorg eerst dat je de basis begrijpt
Gewijzigd op 05/10/2013 17:37:31 door NOLot -
 

Pagina: 1 2 volgende »



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.