Recyklace konstant APP_DIR, LIBS_DIR, TEMP_DIR a WWW_DIR

pekelnik

Recyklace konstant APP_DIR, LIBS_DIR, TEMP_DIR a WWW_DIR

Pokračujeme v oblíbeném tématu Zbavování se prošlého magi :)

Zjistil jsem, že nejsem sám komu se příliš nelíbí definování globálních konstant, které sám nepoužívám, zatím co framework je buhvíkde potřebuje (prosím, nechytat za slovo).

Domnívám se že k tomuto účelu je ve frameworku báječný systém proměnných prostředí.

Ideální index.php by měl vypadat takto:

<?php
require __DIR__ . '/../bootstrap.php';
?>

Přístup frameworku by být mohl zhruba tento:

<?php
if (Environment::getVariable('tempDir', NULL) === NULL) {
      throw new InvalidStateException('Undefined environment variable tempDir.');
}
?>

Konec. Žádné hledání globální konstanty nebo snad „nouzové“ fallbacky __DIR__ či getcwd().

Na programátorovi pak bude zda proměnné definuje v configu nebo v bootstrapu tak aby byly včas dostupné.

Já to mám udělané tak, že v bootstrapu definuji %appDir% a v configu s ním pracuji:

variable.cacheDir = %appDir%/../cache

Co si o tom myslíte?

Editoval pekelnik (4. 10. 2010 22:47)

gawan

+1 mne sa to páči

Honza Marek

Mno…

Já jsem rád, že ty konstanty existujou. Neznám spolehlivější nebo jednodušší cestu, jak zjistit třeba WWW_DIR než vzít ho z konstanty WWW_DIR.
Jak se liší magyje TEMP_DIR a Environment::getVariable(„tempDir“)? Jedno vypadá sofistikovaněji a proto je to čistší řešení?

Kde samo nette ty konstanty potřebuje:

APP_DIR použije Debug, pokud nemá definovanou proměnnou $logDirectory
TEMP_DIR použito v Tools::enterCriticalSection
LIBS_DIR v Nette nepoužito
WWW_DIR v Nette nepoužito

pekelnik

@honza: vždyť jo – proti samotným konstantám nic nemám… jen se mi nelíbí, že je Nette používá.

Vzniká duplicita hodnot TEMP_DIR a %tempDir%, které jsou magicky synchronizované :) – nejde o to že něco je více sofistikované.

Jan Tvrdík

Souhlasím s tím, že toto magické použití konstant by chtělo odstranit. Pokud je to jen na těch dvou místech, tak by to snad neměl být problém.

westrem

Taky si myslim, ze v tomto pripade je FW prilis inteligentny a ze vznikaju duplicity. Kazdopadne navrhoval by som moznost vypnut/zapnut toto automaticke synchro konstant pre niekoho kto to vyuziva ale aby to defaultne bolo vypnute. Co vy na to?

kravčo

Tuším začína hon na mágiu vo veľkom, čarodejnice traste sa!

Honza Marek napsal(a):

Mno…

Já jsem rád, že ty konstanty existujou. Neznám spolehlivější nebo jednodušší cestu, jak zjistit třeba WWW_DIR než vzít ho z konstanty WWW_DIR.

Jak se liší magyje TEMP_DIR a Environment::getVariable(„tempDir“)? Jedno vypadá sofistikovaněji a proto je to čistší řešení?

Súhlas s Honzom v oboch bodoch.

Kde samo nette ty konstanty potřebuje:

APP_DIR použije Debug, pokud nemá definovanou proměnnou $logDirectory

TEMP_DIR použito v Tools::enterCriticalSection

LIBS_DIR v Nette nepoužito

WWW_DIR v Nette nepoužito

Tu musím protestovať. Konštanty nepotrebuje, používa ich ak sú definované, v oboch prípadoch existuje logické riešenie v prípade, že definované nie sú. Vo frameworku je okrem toho oveľa viac miest, kde sa tieto konštanty využívajú, ale magicky, cez Environment::getVariable().

Presenter: %appDir%
Debug: APP_DIR (kontrolované pomocou defined())
Configurator: %appDir%, %tempDir%
Configurator: %libsDir% (predvolená hodnota NULL)
FileTemplate: %appDir% (predvolená hodnota prázdny string)
FileTemplate: %tempDir%
LatteMacros: %appDir% (predvolená hodnota prázdny string)
Tools: TEMP_DIR (kontrolované pomocou defined())

Problematické je azda iba použitie %appDir% pri automagickom hľadaní šablón, no aj tu sa dá poskytnúť fallback hodnota, povedzme getcwd() .'/templates/'.

Prvý prípad má jednoduché riešenie, tretí predpokladám pôjde kade ľahšie zrušením mágie okolo Environment a štvrtý detto. Konštanty preto ostanú používateľovi a ako hinty frameworku (žiadnu z nich nebude vyžadovať).

Editoval kravčo (4. 10. 2010 22:36)

arron

Trochu bych tu asi rozlisosval dve veci a to konfiguraci aplikace (config.ini) a konfiguraci frameworku (konstanty).

Konstanty (a jejich pohodlne vyhledani environmentem) jsou velmi pohodlna zalezitost jak rict frameworku kde jsou jake dulezite cesty a IMHO to do zadne konfigurace vubec nepatri (je to proste jenom nastaveni nejakych parametru pro FW). Umoznuje to napriklad to, ze muzu velmi jednoduse zmenit strukturu adresaru jednoduchym zasahem do jednoho souboru (index.php).

Na druhe strane je konfigurace aplikace, ktera je v config.ini (ci podobnem) a ta zase nema s konfiguraci FW nic spolecneho a melo by ji byt tak nejak jedno, v jake adresarove strukture bezi.

Kdyz to shrnu, tak si myslim, ze stavajici stav je v pohode (neshledavam na nem nic magickeho) az asi na ten temp, kde by jeho nenalezeni melo asi skoncit vyjimkou.

Editoval arron (4. 10. 2010 23:57)

pekelnik

@arron: v configu se konfiguruje i samotné PHP – proč by to nemělo mít nic společného s konfigurací frameworku?

Lopo

pekelnik napsal(a):

@arron: v configu se konfiguruje i samotné PHP – proč by to nemělo mít nic společného s konfigurací frameworku?

ja by som povedal prave preto, ze je to konfiguracia PHP – v idealnom pripade by tie php veci mali byt nastavene uz v php.ini, tj zase len .ini subor

a myslim ze bolo presne povedane, ze v index.php su tie konstanty spravne pretoze definuju zakladne veci pre FW a v config.ini su uz veci pre samotnu app

ale nebranim sa tomu, aby sa tieto 2 veci nejakym sposobom ujednotili a urcili sa jasne pravidla kedy sa ma co pouzivat

mne tam pasuju WWW_DIR, APP_DIR, LIBS_DIR a mozno VAR_DIR, ostatne adresare by uz asi mali byt od nich odvodene v config.ini

_Martin_

Jestli mi něco přijde jako magie, tak dělit na adresáře, které lze mít v index.php a které v config.ini. Jednou už tu něco podobného bylo a vedlo to jenom k problémům (jakože temp dir se nemůže definovat v configu, protože si konfigurátor kešuje konfiguraci a neměl by jí kam uložit, ale složku šablon do konfigu klidně dejte).

V tuto chvíli je definice cest na jednom místě a v okamžiku, kdy bude hotová dokumentace, půjde o velmi jednoduché a nemagické řešení.

A mimochodem, komu začíná bootstrap.php řádkem:

require LIBS_DIR . '/Nette/loader.php';

Tady si s Environment::getVariable() neškrtnete.

pekelnik

**@martin: ** ad dělení adresářů na ty z konstanty a na ty odvozené: +1

ad require LIBS_DIR . '/Nette/loader.php';

tahle konstanta se použije právě jednou, stejně jako APP_DIR se použijé právě jednou v index.php

jaký je rozdíl v tomhle:

require __DIR__ . '/../libs/Nette/loader.php';

Editoval pekelnik (5. 10. 2010 12:57)

arron

pekelnik napsal(a):

@arron: v configu se konfiguruje i samotné PHP – proč by to nemělo mít nic společného s konfigurací frameworku?

Je to proto, ze kazda aplikace muze vyzadovat trochu jine nastavani php (napr. memory_limit). Cili je to taky aplikacni konfigurace, ktera tam patri.

arron

pekelnik napsal(a):

jaký je rozdíl v tomhle:

require __DIR__ . '/../libs/Nette/loader.php';

Rozdil je v tom, ze APP_DIR muze byt jednou __DIR__ . '/../libs' a jindy treba __DIR__ . '/libs'.

Navic APP_DIR vyuziju treba tehdy, kdyz budu hledat jake mam v aplikaci nahrane konkretni moduly.

<OT>Prijde to jenom me, nebo tu na foru resime posledni dobou pekne ptakoviny?</OT>

Editoval arron (5. 10. 2010 13:03)

David Grudl

Dlouhodobě se snažím z frameworku odstranit proměnné prostředí. V současné verzi už žádné výchozí nejsou a použití těch s fallbackem na konstanty se postupně přesune do třídy Configurator. Tedy žádná magie.

Rozdíl mezi TEMP_DIR a Environment::getVariable(„tempDir“) je dosti zásadní. Nedefinovaná konstanta vyhodí v prvním případě E_NOTICE, ve druhém výjimku. Pokud potřebuju konstantu např. z důvodu testování změnit, v prvním případě to nejde, ve druhém ano.

pekelnik

@david: reauguji na odstavce

Odstranění výchozích proměnných (%lang%, %encoding% atd.) vítám. Doufám, že to není předzvěstí odstranění celého mechanismu proměnných prostředí, který je především díky expanzi fakt šikovný.
Co je tedy lepší? Já bych řekl že druhá možnost.

bojovyletoun

Navrhuji toto, co vy nato?
index.php je v wwwrootu a obsahuje pouze

require __DIR__ . "/app" . "/bootstrap.php";

a bootstrap.php v složce s aplikací (třeba app/bootstrap.php) toto

define("LIBS_DIR", __DIR__ . "/../libs");
define("APP_DIR", __DIR__);
define("TEMP_DIR", APP_DIR . "/temp");
require LIBS_DIR . '/Nette/loader.php';

používaám strukturu: wwwroot:

index.php
css/
images/
app/
app/bootstrap.php
app/log/
app/temp/
libs/

v případě jiné struktury stačí jen změnit prostředek v index.php („/app“) a LIBS_DIR v bootstrapu

Editoval bojovyletoun (28. 10. 2010 19:11)

Patrik Votoček

$vote--;

Lopo

$vote--;

v wwwroot-e by mali byt len staticke veci (img, css, js)
vsetko ostatne by malo byt mimo wwwroot aby to nebolo priamo dostupne
log, temp (serverom generovane veci) by mali byt mimo ostatne veci

myslim ze aktualne delenie v examples je uplne v pohode a tazko sa vymysli lepsie

arron

No, jeste by se to urcite dalo trochu vyplepsit, ale stavajici stav uz k dokonalosti opravdu nema daleko:-)

Filip Procházka

--$vote;

Editoval HosipLan (29. 10. 2010 15:37)

jansfabik

David Grudl napsal(a):
Rozdíl mezi TEMP_DIR a Environment::getVariable(„tempDir“) je dosti zásadní. Nedefinovaná konstanta vyhodí v prvním případě E_NOTICE, ve druhém výjimku. Pokud potřebuju konstantu např. z důvodu testování změnit, v prvním případě to nejde, ve druhém ano.

Právě kvůli tomu testování jsem pro nahrazení konstanty TEMP_DIR za proměnnou prostředí. U těch ostatních to nemá smysl – dovede si snad někdo představit, že by za běhu měnil APP_DIR nebo LIBS_DIR?

Úplně ty konstanty odstranit nejde, protože v index.php nejde čistým způsobem nastavit wwwDir jako proměnnou prostředí.