[PHP] Bestandsnaam opvragen gebaseerd op include_path

[xilent_xage]

Hoi,

Mijn framework wisselt soms het include_path. Nu wil ik mijn read_ini method eerder gelezen ini-files laten cachen. Daartoe wil ik een array op laten slaan met daarin het volledige path van de gelezen ini, en de inhoud ervan. Om dat een beetje soepel te laten verlopen moet ik dus soms weten welke file geopend zou worden, rekening houdend met de include_path.

Nu kan ik natuurlijk ergens een functie schrijven die de include_path explode, en dan met een loopje checken of een file is_readable. Maar ik heb het gevoel dat hier een eenvoudiger manier voor is?

Edit: En nu heb ik daar gelijk de volgende verwante vraag aan toe te voegen: Hoe kun je het absolute path ophalen van een geinclude file (zonder dat de betreffende file zelf te laten doen?)

[ Voor 14% gewijzigd door xilent_xage op 07-10-2012 11:44 ]

[TheNephilim]

Misschien heb je hier wat aan voor je eerste vraag: http://php.net/manual/en/function.is-writable.php Spreekt redelijk voor zich lijkt me XD

Wat betreft je 2e vraag: http://nl.php.net/realpath Deze functie kan aan de hand van bijv. ../../include.php het absolute pad ophalen. Je voert hier dus het pad in die je ook bij require_once() of include_once() hebt ingevoerd.

[NMe]

Waarom wisselt je include_path in je framework? Zelfs als je in verschillende views (bijvoorbeeld site en admin) verschillende paden nodig hebt, dan is het toch nog steeds voorspelbaar?

[xilent_xage]

excuus, wegens drukte eerder geen tijd om te kijken / antwoorden. Antwoord inmiddels gevonden: stream_resolve_include_path()

[Cartman!]

Kun je uitleggen waarom je het precies nodig hebt? Het klinkt nu alsof je dit nodig heb omdat je een ontwerpfout hebt gemaakt.

[xilent_xage]

ik gebruik de include path om bepaalde bestanden te kunnen customizen bij bijv een theme. Ik creeer dan bijv een index.php in de root die voor alle pagina's geldt. Maar voor bepaalde themes wil ik die kunnen overriden. Hiertoe pas ik de include path aan.

Als ik bijv 100 pagina's wil renderen die allemaal een eigen theme hebben dan wordt de include_path dus steeds aangepast.

[Cartman!]

Sorry dat ik t zeg, maar dan heb je toch een ontwerpfout gemaakt imo. Het aanpassen van je include_path zou tijdens het draaien van je script nooit nodig moeten zijn nadat je deze eenmalig hebt gezet in je bootstrap. Hoe ziet je mapstructuur eruit?

[xilent_xage]

Cartman! schreef op dinsdag 16 oktober 2012 @ 08:33:
Sorry dat ik t zeg, maar dan heb je toch een ontwerpfout gemaakt imo. Het aanpassen van je include_path zou tijdens het draaien van je script nooit nodig moeten zijn nadat je deze eenmalig hebt gezet in je bootstrap. Hoe ziet je mapstructuur eruit?

heu stuk of 2000 mappen, lijkt me wat teveel om hier te plempen

punt is dat ik code/html/css op verschillende niveau's wil kunnen overriden. Simpel gezegd heb je 3 niveau's: widgetniveau, daaronder paginaniveau, daaronder themeniveau. Ik wil in principe elk bestand op elk niveau kunnen definieren.

Stel ik render een twitter-widget op een pagina van paginatype 'gele pagina' met theme 'kleuren' dan pakt ie de controller (die bij mij render of compiler heet afhankelijk van de cache-state) volgens de include path:

_themes/kleuren/geel/twitter/compiler.php

als die niet bestaat dan

_themes/kleuren/geel/compiler.php

en als die niet bestaat dan:

_themes/kleuren/compiler.php
compiler.php

Op die manier kun je code van algemeen naar specifiek opbouwen waarbij ie altijd van specifiek naar algemeen fallbackt. De code zelf is MVC, maar welke model (entity), controller (compiler/render) of view (template)-file ie pakt hangt dus af van de widget, het paginatype en het theme van de betreffende pagina. Normaal gesproken stel je de include_path dus 1x in. Maar soms (vooral aan de CMS-kant) is het nodig om meerdere pagina's te compilen. Bijvoorbeeld als er een index van artikel-linkjes oid staat. In dat geval moeten soms enkele tientallen pagina's gecompiled worden. En dan wissel ik dus per compile de include_path.

[Janoz]

Zo'n vreemd ontwerp is dat niet, je zult het echter niet op moeten lossen met het includepath. Je kunt beter een losse functie schrijven die, obv file exists bepaald welk bestand ingeladen moet worden.

[ Voor 1% gewijzigd door Janoz op 19-10-2012 09:17 . Reden: negatie vergeten :X ]

[Cartman!]

Die mapstructuur is niets mis mee nee maar daarvoor hoef je niet het includepath zelf aan te passen, enkel de diepte waarop die de file gaat inladen. Zoals Janoz al zegt kun je zo diep mogelijk beginnen met controleren of je file bestaat, zo niet...stapje terug en controleren totdat je de juiste file gevonden hebt. Dan breek je uit de loop en include je die file zonder het include_path te hoeven wijzigen, die staat gewoon simpelweg op '/' zegmaar.

[xilent_xage]

Ik had eerst een custom functie, maar ben recent overgestapt op de include path. Mjin overwegingen waren:

1. Het is sneller
2. Het scheelt flink wat code
3. Include_path is daar in principe ook voor bedoeld.

Ik begrijp van jullie dat ik op punt 3 mis zit, en ben wel benieuwd waarom!

[Janoz]

include path is in principe iets statisch. Dat je het toevallig vanuit de code ook nog aan kunt passen betekend niet dat het daar ook voor bedoeld is. Dat het veel code scheelt betwijfel ik. Je hoeft immers slechts 1 functie te schrijven. Tot slot vraag ik me af waarop je de snelheid baseert.