[PHP] OO probleem met functie buiten object

[xilent_xage]

Hoi,

Ik heb de volgende functie geschreven:

code:

#try to include custom file else normal file-------------------------------------------------------
function custom_include( $filename ) {
    
    #init
    global $_paths;

    #try to include custom file
    if ( is_readable($_paths['web_root'] . "_custom/" . $filename) ) { include($_paths['web_root'] . $_paths['custom'] . "/" . $filename); }

    #try to include normal file
    elseif ( is_readable($_paths['web_root'] . $filename) ) { include($_paths['web_root'] . $filename); }

}

Zoals je ziet is het doel om bij een include eerst te checken of er een custom versie van bestaat, en zoja die te gebruiken. Als de custom versie niet bestaat probeert ie het standaard bestand te includen.

Deze functie staat in index.php zodat ie altijd beschikbaar is zonder globals te hoeven gebruiken. Ik gebruik de functie onder andere voor het inlezen van config bestanden. Een config bestand ziet er bij mij doorgaans uit als:

code:

$this->settings['toon_banner'] = true;
$this->settings['toon_zoek'] = false;
...

en wordt geinclude door classes (objecten).

Probleem is dat de config file, als deze wordt uitgevoerd middels mijn eigen custom_include ipv include, hij $this niet kent. Hij zit dus buiten de class. Hoe los ik dit op?

[vorlox]

Uh niet op deze manier.
Wanneer je deze functie geen onderdeel maakt van een class kun je nooit $this aanroepen.

Je zou met een singleton kunnen werken echter dat is niet het mooiste alleem kun je dan ipv $this overal $instance = singleton::getInstance(); gebruiken

[Exception]

Door inplaats van $this de variable waarmee je de class hebt gedefineerd te gebruiken.

PHP:

$dezeclass = new MijnClass();

$dezeclass->settings['toon_banner'] = true;

Of begrijp ik je nu verkeerd?

[ Voor 7% gewijzigd door Exception op 20-07-2008 10:55 ]

[Haan]

Ik weet niks van PHP, maar normaal gesproken roep je met het keyword 'this' iets aan vanuit een object op het object zelf, bijvoorbeeld this.DoSomething(), wil je van 'buiten' iets in het object aanroepen, dan wordt het myObject.DoSomething(). (waarbij je dus wel eerst een object genaamd 'myObject' hebt aangemaakt!)

Misschien helpt dit.

edit:
en alweer te laat ik zeg hetzelfde als Jeff van Hees hierboven

[ Voor 9% gewijzigd door Haan op 20-07-2008 10:58 ]

[xilent_xage]

@Jeff & @Haan: De settings file weet natuurlijk niet met welke naam zijn class wordt aangeroepen.
@vorlox: Singletons ben ik niet zo'n fan van

Als ik dit zo lees kan ik beter eieren voor mijn geld kiezen en de functie custom_include gewoon in elke class includen... jammer, das toch niet zo mooi en behoorlijk omslachtig.

[mjax]

xilent_xage schreef op zondag 20 juli 2008 @ 11:28:
Singletons ben ik niet zo'n fan van

Een Settings class is toch vaak een mooi voorbeeld van een Singleton. Door een Singleton te implementeren is je probleem meteen opgelost.

[Cartman!]

Waarom maak je er geen static functie van dan?

PHP:

// deze in MyClass gooien
static function includeFile($filename)
{
// doe je ding
// return je ding
}

// zo aanroepen
MyClass::includeFile('filename');

volgens mij is dat wat je wil. Er is overigens helemaal niks mis met singletons maar als het hierbij blijft is dat ook niet nodig..

[Face_-_LeSS]

Waarom zet je je settings in een .php bestand? je kan deze veel beter in een xml of gewoon een txt bestand zetten. Dan maak je in php een klasse die deze settings uitleest.

Zal misschien iets minder snel zijn dan een include maar wel veel netter en minder kans op fouten.

[Cartman!]

Maar dan wel buiten je webroot plaatsen natuurlijk...

Je config in een singleton gooien is echt handig ieder geval, kun je er overal bij met iets als

PHP:

$config = Config::getInstance();
echo $config->path_root;

[Verwijderd]

mjax schreef op zondag 20 juli 2008 @ 11:34:
Een Settings class is toch vaak een mooi voorbeeld van een Singleton. Door een Singleton te implementeren is je probleem meteen opgelost.

Een Singleton is een goed voorbeeld van niets meer dan een beperking die je sinds dag 1 je project in sluist. 'There can be only one' druist wel enorm in tegen de herbruikbaarheid van componenten.

[SchizoDuckie]

Verwijderd schreef op zondag 20 juli 2008 @ 13:22:
[...]
Een Singleton is een goed voorbeeld van niets meer dan een beperking die je sinds dag 1 je project in sluist. 'There can be only one' druist wel enorm in tegen de herbruikbaarheid van componenten.

Dat is best een loos argument voor bijv. zoiets als een settings class of een database class waar je er bijv. altijd maar 1 van hebt. Als je voor een ander project dat ding niet als singleton nodig hebt, sloop je de singleton functionaliteit eruit en kan je hem gewoon gebruiken.

Ik kan echt met m'n pet niet bij die evangelisten die weigeren om een juiste oplossing voor een probleem te gebruiken omdat ze ergens gelezen hebben 'dat het vies is'. Uiteindelijk kom je dan op een andere oplossing uit, die ranzig is, andere mensen niet simpel kunnen doorgronden en jebent een hoop tijd kwijt voor niets.

[ Voor 9% gewijzigd door SchizoDuckie op 20-07-2008 13:46 ]

[xilent_xage]

misschien had ik er ook even bij moeten vermelden dat ik mijn functie niet alleen gebruik voor het importeren van settings, maar ook van bijv functies, die binnen de class aangeroepen moeten kunnen worden...

@Face_-_LeSS: Daar ben ik juist vanaf gestapt. Ik vond t traag en omslachtig. Maargoed, das een andere discussie.

[Toolskyn]

Waarschijnlijk zal er wel iets tegen zijn, maar voor zover ik zie heb je als er iets 'custom' is, je gewoon een bestandje met dezelfde naam hebt in je _custom mapje, waarom zet je dan niet gewoon _custom vooraan in je include path? Ik bedoel dan kijkt PHP wel voor je of die toevallig in _custom bestaat, zoniet dan gaat hij verder met de rest van je include path. (mijn vraag is dus eignelijk: wat is het nut van die functie?)

[ Voor 7% gewijzigd door Toolskyn op 20-07-2008 15:33 ]

[xilent_xage]

Bedankt Toolskyn! Simple, beautiful! Niks Wel wat Niks op af te dingen. Stom dat ik er niet aan heb gedacht en het zo ingewikkeld aan het proberen was...

[ Voor 10% gewijzigd door xilent_xage op 20-07-2008 16:23 ]

[xilent_xage]

Alleen jammer dat deze methode niet werkt als de file gewoon gevonden kan worden: Dan checkt ie de custom dir natuurlijk niet...

Terug naar de tekentafel.

[xilent_xage]

Nevermind, . stond nog voor mijn dirs. Het werkt nu!

[Verwijderd]

SchizoDuckie schreef op zondag 20 juli 2008 @ 13:44:
Dat is best een loos argument voor bijv. zoiets als een settings class of een database class waar je er bijv. altijd maar 1 van hebt.

Tsja, je zou ook open kunnen staan om iets te leren.

[igmar]

Verwijderd schreef op zondag 20 juli 2008 @ 13:22:
Een Singleton is een goed voorbeeld van niets meer dan een beperking die je sinds dag 1 je project in sluist. 'There can be only one' druist wel enorm in tegen de herbruikbaarheid van componenten.

Hoezo net herbuikbaar ? omdat je maar 1 instantiatie van dat object kan doen ? Wat heeft dat met herbuikbaarheid te maken ?

[Verwijderd]

igmar schreef op maandag 21 juli 2008 @ 11:35:
Hoezo net herbuikbaar ? omdat je maar 1 instantiatie van dat object kan doen ? Wat heeft dat met herbuikbaarheid te maken ?

Hoezo is het wel herbruikbaar volgens jou dan? Tip: denk dan vooral aan classes die de singleton gebruiken.

En om het maar even af te maken:
- Hoe testbaar is je code?
- Waar ligt de verantwoordelijkheid van je classes?
- Welke eigenschappen van de singleton class heeft de gebruikende class echt nodig?

[g4wx3]

Mijn ei:

Doe je settings toch maar in een php-bestand.
Ik wou eens de settings opslaan in settings.ini, en was dan bezig om een class te schrijven, daarnaast dan ook nog apche-bestand maken, om toegang tot het bestand te verbieden ed.

Veel werk, en heb vrij snel beseft dat het nogal een dol idee is om het zo ingewikkeld te maken.

Ik sla de settings van MySQL op in config.php, heel simpel:

PHP:

<?php
$server = 'localhost';
$username = 'root';
$password = 'root';
$database = 'database';
$config = 'config';
?>

Configureren van mysql doe ik vanuit de site zelf, dus ik hoef mijn bestand niet te bewerken de hard way.
doch, ik was te lui om het netjes te scripten met php: Ik include het bestand, probeer een verbinding te maken, als deze mislukt krijg je een form, waar je de gegevens in dient in te vullen. En op luie manier herscrhijf ik dan opnieuw het hele bestand. Voorkomt ook dat er mee gerotzooid wordt.

de laatste entry in het bestand is de naam van de table met al de andere config-dingen

Eenmaal ik een verbinding heb met de database, kan ik al men overige instellingen opslaan in de datebase.

er zijn andere manieren, dan werken met een bestand om instellingen in op te slaan, maar zo is het wel het gemakkelijkste. Normaal zal ook nooit iemand de inhoudt van je config bestand kunnen uitlezen. (tenzij je ftp wordt gehacked)

Uitreksel van de code:

PHP:

# MySQL connect
$server = NULL;         //server
$username = NULL;       //username
$password = NULL;       //password
$database = NULL;       //database
$config = NULL;         //table: general config

$mysql_settings = 'resources/shared/config.php';
if(!file_exists($mysql_settings))
{
    $fp_config = fopen($mysql_settings,'w');
    fclose($fp_config);
}
include($mysql_settings);

# ============================================================================
# connect MySQL
$db = new DBI($server, $username, $password,$database);
$status = $db->status();

# ============================================================================
# setup MySQL
if($status!=7)
{
    include('resources/apps/dbsetup/app.php'); 
}

Wel te verstaan dat ik hier niet al te veel energie in heb gestoken.
*als ik eens met verschillende rechten wil verbinden met de database, werk ik gewoon met 2 bestanden.

[ Voor 25% gewijzigd door g4wx3 op 21-07-2008 16:38 ]

[Cartman!]

g4wx3 schreef op maandag 21 juli 2008 @ 16:21:
Doe je settings toch maar in een php-bestand.
Ik wou eens de settings opslaan in settings.ini, en was dan bezig om een class te schrijven, daarnaast dan ook nog apche-bestand maken, om toegang tot het bestand te verbieden ed.

Veel werk, en heb vrij snel beseft dat het nogal een dol idee is om het zo ingewikkeld te maken.

Gewoon buiten de documentroot plaatsen, nergens gezeik meer mee. Settings in een .ini werkt heel handig. Ik gebruik Zend Framework en daar heb je gewoon een Config class waar je de locatie opgeeft en dan krijg je keurig je hele ini file terug als object. Echt een aanrader (sowieso is heel Zend Framework een enorme aanrader).

[Verwijderd]

g4wx3 schreef op maandag 21 juli 2008 @ 16:21:
Doe je settings toch maar in een php-bestand.
Ik wou eens de settings opslaan in settings.ini, en was dan bezig om een class te schrijven, daarnaast dan ook nog apche-bestand maken, om toegang tot het bestand te verbieden ed.

Veel werk, en heb vrij snel beseft dat het nogal een dol idee is om het zo ingewikkeld te maken.

Da's heel erg afhankelijk van wie de config moet beheren. Doe je (of 1 van je collega-PHP'ers) dat zelf, dan is een config.php een goed werkbare optie, maar wanneer 't moet gebeuren door een consultant of een helpdesk medewerker dan zou ik direct kiezen voor een settings.ini oplossing.
En het parsen van een ini-file is nou ook niet echt rocket science...

Het voordeel van een ini-file is dat je helpdesk medewerkers daar al ervaring mee hebben, en dat 't niet uitmaakt of die medewerker die '$' vergeet of niet helemaal correct met de quotes omgaat.
En zo'n parsertje schrijf je in een verloren uurtje of zo.

Het mooiste is natuurlijk een mooi config/admin tooltje waar ook de helpdesk blij van wordt, maar dat is vaak een iets te dure optie (kost je toch wel een paar dagen om daar een net framework voor op te zetten)...

[Verwijderd]

Wat een gelul hier. Een .ini bestand openen en inlezen kost je exact 1 function call naar parse_ini_file. Met het Zend Framework heb je meteen een zooitje mooie wrappers voor allerlei zaken als configuratie en database connectiviteit.

Ik stel voor dat vóórdat we met zijn allen g4wx3's kamikazetechnieken gaan toepassen, éérst nog even gaan kijken naar het Zend Framework. Dat zit dan toch nét even iets beter in elkaar.

[vorlox]

Verwijderd schreef op maandag 21 juli 2008 @ 21:41:
Wat een gelul hier. Een .ini bestand openen en inlezen kost je exact 1 function call naar parse_ini_file. Met het Zend Framework heb je meteen een zooitje mooie wrappers voor allerlei zaken als configuratie en database connectiviteit.

Ik stel voor dat vóórdat we met zijn allen g4wx3's kamikazetechnieken gaan toepassen, éérst nog even gaan kijken naar het Zend Framework. Dat zit dan toch nét even iets beter in elkaar.

Ja je hebt helemaal gelijk ik ga een heel framework gebruiken en 10 includes laden om mijn settings in een ini op te slaan... ik ben echt heel dom denk ik maar is een ini bestand niet gewoon een text bestand en is een php bestand dat ook niet gewoon ? Waarom logic loslaten op iets wat geen logic nodig heeft? inderdaad allemaal gelul hier