php globale var doet erg moeilijk

[Anoniem: 273091]

ik heb deze code

code:

<?php
if(!is_dir('ini_'))
chdir('../');

require_once('ini_/ini_config.php');
require_once('func_/func_getusergroups.php');

function isadministrator($user_id) {
    global $group_administrators;
    $groups=getusergroups($user_id);
    if(!is_array($groups))
    $groups=array($groups);
    $adup=strtoupper($group_administrators);
    if(in_array($adup, $groups))
    $isadmin=1;
    else
    $isadmin=0;
    
    return $isadmin;
}
?>

gebruikt om op te kunnen vragen of een gebruiker een administrator is, deze functie is onderdeel van een framework dat ik zelf gemaakt heb en is opgeslagen in een los bestand. dit bestand wordt onderdeel van index.php via require_once. index.php ligt een map hoger en daarom wordt dat pad aangepast bij de require functie een vergelijkbare constructie als in de requires in code...

nu heb ik hetzelfde bedacht voor een andere locatie. deze ligt echter veel mappen verder en gebruikt dus deze code om het op te vragen....

$tempdir=getcwd();
chdir("../../../../../../");
require_once("func_/func_checklogin.php");
require_once("func_/func_isadministrator.php");
$group_administrators="administrators";
$login=checklogin();
if(isadministrator($login['id']))
return true;
chdir($tempdir);

eerste geval werkt, tweede geval werkt niet.
nu heb ik achterhaald in welke richting ik dus moet denken. $global_administrators werkt niet in geval twee waarom weet ik niet. in bijde gevallen is het pad hetzelfde maar toch wordt global niet meegenomen in code in case twee waarom?

[Freeaqingme]

heb je ook overwogen om gewoon geen globale vars te gebruiken?

[ACM]

Afgezien van het feit dat ik niet zo goed zie waarom je een global zou nodig hebben voor iets wat je ook gewoon met een 2e parameter op kan lossen... Global staat los van het pad waar je bent, ik snap iig de toegevoegde waarde van die chdir's niet van je.

Het feit dat er een 'return true' staat suggereert dat je dat 2e blok code in een functie hebt staan? (overigens wordt je laatste chdir dus niet uitgevoerd als iemand admin blijkt te zijn) In dat geval ligt het waarschijnlijk daaraan, want dan is je $group_administrators helemaal niet als globale variabele gedefinieerd, maar in de scope van de functie die je hebt weggelaten in je code-weergave.

Als je per se global's wilt gebruiken verdient het sowieso de voorkeur om dan ook expliciet met de $GLOBALS-superglobal array te werken. Oftewel altijd lezen en schrijven naar $GLOBALS['group_administrator']. Dan heb je nooit last van het per ongeluk mixen van locale en globale scopes.

[Tiemez]

Met

PHP:

dirname(__FILE__)

kun je het path opvragen van de huidige php file

Jij weet welke files je nodig hebt en waar deze staan. Die chdirs maken het er niet leesbaarder op.

je kan ook (niet via cli) gebruik maken van de variabele

PHP:

$_SERVER["DOCUMENT_ROOT"];

[Cartman!]

Je kunt ook 'gewoon' je includepath aanpassen, dan heb je dat gedoe met chdirs ook niet. Overigens zou je de boel meteen flexibeler kunnen maken en gewoon de naam van de groep waar iemand in hoort meegeven aan de functie, dan hoef je niet voor iedere groep (eigenlijk een recht of permissie) een losse functie te gaan maken.
Echter zou ik sowieso even kijken naar je structuur, als je op een centrale plek de huidige usergegevens onthoud (singleton bijv) dan hoef je niet steeds het userid mee te geven en doe je gewoon zoiets:

PHP:

if(Auth::checkPermission('view_this_specific_content')) {
// doe je ding
}

[ReenL]

en als je dan toch contcreet wilt weten waarom het niet werkt:

File: /path/to/index.php

PHP:

echo getcwd().'<br />';
require '1/2/3/4/5.php';

File: /path/to/1/2/3/4/5.php

PHP:

echo getcwd();

Als je nu naar http://localhost/path/to gaat zul je deze output zien:

code:

/path/to/
/path/to/

Als je naar http://localhost/path/to/1/2/3/4/5 gaat zul je dit zien:

code:

/path/to/1/2/3/4/

In het zend framework wordt het opgelost zoals Tiemez dat aangeeft in de vorm van:

PHP:

define('SYSTEM_PATH', dirname(__FILE__));

Ik raad je ook aan naar andere frameworks te kijken voordat je, je eigen framework (verder) gaat bouwen andere frameworks hebben namelijk ook soortgelijke problemen op moeten lossen.

[Ventieldopje]

Iets met het wiel en een baksteen ... hmm, nouja in ieder geval iets met het wiel.
1. Lijkt me niet zo handig om voor elke functie die je schrijft een include te moeten maken
2.

code:

if(!is_array($groups))
    $groups=array($groups);

... Are you mad?!
3. chdir voor includes is een no go, ReenL geeft je de goede oplossing (die van Zend)

Ik raad je aan eens naar het Zend Framework te kijken, niet een van de makkelijkste om mee te beginnen maar als je het door hebt werkt het heerlijk

[Leftblank]

Phas0r schreef op donderdag 21 oktober 2010 @ 00:19:
[..]
Ik raad je aan eens naar het Zend Framework te kijken, niet een van de makkelijkste om mee te beginnen maar als je het door hebt werkt het heerlijk

Als ervaren Java/OO-programmeur ja , Zend heeft wel een vrij complexe structuur wat het niet echt lekker maakt als eerste framework imo. Gezien de problemen van de TS lijkt het me niet echt de juiste oplossing voor dit moment.

[Freeaqingme]

Het spreekwoordelijke mes snijdt hier wel aan twee kanten natuurlijk. Lang geleden kwam ik met php niet verder dan verzamelingen van functies die ik in classes gooide en de objectgeorienteerde-api van mysqli, van objecten had ik verder geen verstand. Totdat ik echter naar ZF ben gaan kijken. Toegegeven de learningcurve was wat stijl (dat zou die tegenwoordig minder moeten zijn omdat er nu dingen als zend_layout en zend_application zijn), maar eenmaal voorbij 't learning point snapte ik wel in een keer wat men nou altijd bedoeld had met OOP, MVC en allerhande Design Patterns. Als TS dus de tijd en energie er in wil steken om goed te leren programmeren zou ik daarvoor kiezen. Moet er snel iets af dan ligt Cakephp of CodeIgniter waarschijnlijk meer voor de hand als eerste fw.

[Anoniem: 273091]

het probleem is dat ik het framework zeer specifiek is en puur op content management en wel op de manier waarop ik et wil. de is_dir uitzonderingen die bovenaanstaan zijn volgens mij niet van toepassing op de functies maar op een ander type in het framework maar zitter er in voor de zekerheid, maar doen momenteel niets vanwege de manier van aanvragen (gaat nog verdwijnen) elke functie word in princiepe ge include maar dit gebeurd in een keer door een scanner, dit is zodat het makkelijk uitgebreid kan worden. ik kan niet alles heel makkelijk doen omdat het een framework is, en niet alles op uitzondering gebouwd moet worden dan krijg je chaos. ik vraag me af waarom een global include niet werkt als er eerst van map gewisseld moet worden naar de exacte zelfde map als de uitvoermap van een ander bestand. terwijl dat bestand wel werkt.

[Freeaqingme]

Welk CMS gebruik je dan? Kilnkt erg php3-achtig (en nee, dat is niet positief)...

[ Voor 23% gewijzigd door Freeaqingme op 22-10-2010 15:51 ]

[Anoniem: 273091]

zelfgemaakt dus althans ben mee bezig laatste stapjes en dit werkt niet:)

[moozzuzz]

Kan je niet gewoon absolute paden gebruiken? Ik begrijp sowieso niet waarom je persé wenst te werken met cwd()...

De variable $global_administrators komt overigens niet voor in je geposte code... moeilijk. Zie ook opm ACM.

[Anoniem: 35775]

Ook zonder een framework als Zend maar met een basis in OOP en design patterns zouden dit soort problemen / vraagstukken makkelijk te tacklen zijn ...

bijvoorbeeld door het implementeren van een registry die een OO alternatief voor globals kan zijn of door een User object aan te maken die je vanuit iedere locatie op kunt vragen door bijvoorbeeld : Application::getInstance()->getUser();

Ik geloof er verder heilig in dat het eerst goed is om zelf in dingen te duiken voordat je grijpt naar een off-the-shelve oplossing als Zend, CodeIgniter. Cake ... pas als je voldoende kennis hebt opgebouwd snap je dan ook wat deze frameworks doen onder de motorkap.

[NMe]

Anoniem: 273091 schreef op vrijdag 22 oktober 2010 @ 15:57:
zelfgemaakt dus althans ben mee bezig laatste stapjes en dit werkt niet:)

Dan zit je CMS dus niet goed in elkaar en zit je nergens aan vast. Gewoon dit stukje opnieuw ontwerpen en goed opzetten.

[Freeaqingme]

Anoniem: 35775 schreef op vrijdag 22 oktober 2010 @ 16:24:
bijvoorbeeld door het implementeren van een registry die een OO alternatief voor globals kan zijn of door een User object aan te maken die je vanuit iedere locatie op kunt vragen door bijvoorbeeld : Application::getInstance()->getUser();

Raad dan ook meteen aan zoals "de standaarden" het voorschrijven

Dan krijg je dus iets als Tuxedo_Appliction::getInstance()->getUser(); (dan gaat 't dus om de prefix/namespace)

[Anoniem: 273091]

okay er woren geen classes gebruikt (schk niet) eigen design logica werkt erg goed en dit is de eerste dat ik tegen een soort probleem aanloop dus ik wil het ook opgelost hebben. cwd kan anders als het anders kan maar de root van de site word bepaald in een bestand ook in ini_config.php als net zoals $group_administrators

[Cartman!]

Heb je de rest van de reacties niet gelezen nu? Er worden echt heel veel goede tips aangedragen.

[Anoniem: 273091]

Cartman! schreef op zaterdag 23 oktober 2010 @ 13:00:
Heb je de rest van de reacties niet gelezen nu? Er worden echt heel veel goede tips aangedragen.

ik zoek ze nog maar het praktische probleem is nog niet opgelost en daar is tot zover ik dan kan zien nog geen antwoord opgegeven.

[MueR]

Je praktische probleem is een verkeerde opzet. Dat kan je zelf oplossen door wat van de tips die hier gegeven worden te gebruiken. Als je dat niet wil doen, zelf weten. Het zou niet voor het eerst zijn dat je advies vraagt en het vervolgens compleet negeert.

[Cartman!]

Anoniem: 273091 schreef op zaterdag 23 oktober 2010 @ 13:39:
[...]

ik zoek ze nog maar het praktische probleem is nog niet opgelost en daar is tot zover ik dan kan zien nog geen antwoord opgegeven.

Dat is dus je echte probleem, dat je de gegeven tips niet weet te linken aan je probleem.

[NMe]

Anoniem: 273091 schreef op zaterdag 23 oktober 2010 @ 13:39:
[...]

ik zoek ze nog maar het praktische probleem is nog niet opgelost en daar is tot zover ik dan kan zien nog geen antwoord opgegeven.

Je design is niet goed, het commentaar dat je hierboven gehad hebt is meer dan voldoende om je op weg te helpen bij een fatsoenlijk redesign. We blijven je niet aan het handje houden zoals je in bijna al je topics hier doet. Op een gegeven moment zul je toch echt moeten leren programmeren...

Dit topic gaat op slot, ga eerst maar eens aan de slag met het goeie commentaar dat je gehad hebt.

offtopic:
Wat betreft het singletonverhaal: ik zal daar niet in een slotje op ingaan, dat is vrij flauw aangezien jullie allemaal niet meer kunnen reageren. Wél vind ik het MSDN-blog een stuk beter, maar dat legt dan ook echt uit waarom bepaalde dingen zo zijn in plaats van ze gewoon als waarheid te poneren. Op die manier kan een programmeur voor zichzelf bepalen in welke mate zo'n argument opgaat in zijn situatie in plaats van dat PFZ-artikel dat maar zomaar roept dát het zo is zonder verdere redenatie. Daarnaast kunnen al die argumenten dus meer of minder toepasselijk zijn op een bepaald project.

Mocht iemand hier een nieuw topic over willen openen: feel free. Singleton: vermijden of juist niet?