proc se do frameworku vratilo define?

pawouk

Zdravim, jde o malickost, ale zajimalo by me proc se do indexu v sentboxu vratilo define APP_DIR, WWW_DIR atd… pred nejakou dobou to bylo odstraneno a me to prislo jako krok vpred. Vedel by nekdo duvod tohoto pocinu? Diky

Filip Procházka

Protože ty informace jsou prostě konstanty. Ale možná by stálo za to, je dát do namespace.

V aplikaci je ale používat nemusíš (a neměl bys).

nanuqcz

Taky se mi řešení bez konstant líbilo daleko více… Takhle je to „pro něco si šáhni do contextu, něco hledej v konstantách …“ – předtím to prostě bylo přehlednější a jednodušší :-(

pawouk

@HosipLan: No právě protože bych je neměl použít tak nechápu proč jsou to konstanty :-) To je podstata té otázky…

Filip Procházka

@**xxxObiWan**: prostě na ně nesahej a bude ti hej ;)

$presentersDir = $this->context->expand('%appDir%/presenters');

Editoval HosipLan (10. 1. 2012 7:24)

joseff

Ja se take priklanim k tomu ze to moc nechapu, prijde mi to krok zpet… Ma nekdo rozumne vysvetleni? Connection se take v drtive vetsine aplikaci nemeni a neni to konstanta. I kdyz by se dalo uplne stejne udelat databaze jako konstanta a pak rict aby ji nikdo nepouzival… prijde mi to to same.

22

v drtive vetsine aplikaci nemeni !== nikdy se nemění

… těch konstant si nemusíš v index.php vůbec všímat.. wwwDir a appDir maš v SystemContaineru

Editoval 22 (9. 1. 2012 12:53)

Nox

A já myslel že globálnost je zlo™ … co když bych chtěl použít knihovnu/framework, který má taky LIBS_DIR třeba, není to lepší přes $params. Jaké mají konstanty výhodu? (kromě toho, že jsou dostupné všude což mimo jiné není moc DI)

bazo

este vzdy si to mozte spravit po starom a konstanty nepouzivat

Nox

Tak vždycky si můžeme Nette úplně přeprogramovat … otázka je, který postup by měl být vhodnější pro uživatele sandboxu

Anebo tedy prostě obecně ve frameworku mít

Editoval Nox (9. 1. 2012 13:53)

Aurielle

Když se podíváte do kódu Nette tak zjistíte, že existenci konstant Nette vůbec nekontroluje a není potřeba je využívat. Proč se vrátily do sandboxu je věc druhá, možná z důvodu „přehlednosti“ pro začátečníky – přece jenom je lepší nadefinovat konstantu než inicializovat $container->params (a to mám pocit že v novém configuratoru ani nejde).

David Grudl

Konstanty v sandboxu nemají nic společného s frameworkem, je to čistě věc souborů index.php a bootstrap.php a nikde jinde se nepoužívají. Klidně můžete používat proměnné, je to fuk. Obojí je globální úplně stejně, není rozdíl mezi přístupem přes APP_DIR nebo $GLOBALS['appDir'].

duke

@Nox: Problém s kolizemi s jinými knihovnami by šel vyřešit přes namespaced konstanty, např.:

namespace MyApp;

const WWW_DIR = __DIR__;

Z hlediska DI by to byl problém, pouze pokud by se tyto konstanty používali zevnitř aplikace (tj. kdekoli mimo index.php a bootstrap.php). Samotná existence těchto konstant nevytváří nijakou závislost ničeho na ničem. Pokud nedojde k nevhodnému použití (zevnitř aplikace), je zde nedostatek jen z pohledu „data hiding“.

Ve verzi, kdy se místo konstant používala globální proměnná $params, která se následně kopírovala do containeru, byl problém úplně stejný, protože pokud si pamatuju, tak se žádné unset($params) nekonalo (patrně proto, že používat globální $params narozdíl od globálních konstant, by nikoho ani nenapadlo). Nicméně pokud by ten unset proběhl, bylo by to z pohedu data hiding asi čistší. Na druhou stranu, použití konstant mi přijde estetičtější. :-)

David Grudl

duke napsal(a):

A teď ještě jak stejným způsobem vyrobit APP_DIR ;-)

Nox

duke napsal(a):

Ok, díky, máš pravdu

duke

David Grudl napsal(a):

A teď ještě jak stejným způsobem vyrobit APP_DIR ;-)

David naráží na to, že const narozdíl od define neumožňuje pracovat s výrazy, což jsem skutečně přehlédl. Nicméně možným řešením je zde eval.

function defConst($name, $value)
{
    $code = __NAMESPACE__ !== '' ? ('namespace ' . __NAMESPACE__ . ';') : '';
    $code .= "const $name = '" . str_replace("'", "\\'", (string) $value) . "';";
    eval($code);
}

defConst('APP_DIR', __DIR__ . '/../app');

Aurielle

Aneb jak se škrábat levou rukou za pravým uchem, uděláme z nepěkných konstant nechutný eval…

duke

Souhlasím s tím, že než použít eval, je vhodnější konstanty vůbec nepoužít. S tím příkladem jsem jen odpovídal na přímo položenou otázku.

Aurielle

Já bych to radši než přemýšlet nad použitím evalu rovnou zavrhl s tím, že to nejde (a není potřeba) :D

Jan Tvrdík

duke wrote:

David naráží na to, že const narozdíl od define neumožňuje pracovat s výrazy, což jsem skutečně přehlédl. Nicméně možným řešením je zde eval.

Doprdele proč eval? Vždyť jde normálně použít define.

define(__NAMESPACE__ . '\\APP_DIR', __DIR__ . '/../app');

bojovyletoun

tak třeba já používám své, řešení bez konstant a bez paramentrů.
index.php: <?php require "./app/bootstrap.php";
bootstrap

/* # set dirs */
$dir = __DIR__;
$tmp = "$dir/../temp";
$log = "$dir/../log";
$lib = "$dir/../../../libs";

/* # load nette, start debug */
require "$lib/nette/loader.php";

duke

Jan Tvrdík napsal(a):

Vždyť jde normálně použít define.

Máš pravdu. Z nějakého důvodu jsem měl za to, že define toto nepodporuje. Dík za tuto informaci. Nicméně na mou obhajobu musím podotknout, že můj příklad s evalem byl přímou opovědí na to, jak stejným způsobem (tj. pomocí const) nastavit APP_DIR. :-)

duke

HosipLan napsal(a):

Maj gad, co řešíte?
namespace App;

const WWW_DIR = __DIR__;
const APP_DIR = realpath(__DIR__ . '/../app');

Řešíme mj. to, že tvůj příklad právě nefunguje (nelze volat realpath v definici konstanty přes const). :-)

David Grudl

Řešíte problém, který neexistuje, způsobem, který nejde.

Patrik Votoček

Proč je tu proboha tolik příspěvků? Vždyť vám nikdo nebrání udělat si vlastní sandbox kde konstanty nebudou! Nikdo vás přece nenutí používat výhradně officiální sandbox/skeleton.