[2010–09–23] úprava adresářové struktury

David Grudl

Výchozí adresářová struktura doznala zpřehlednění. Vypadá nyní takto:

app/
	presenters/
	templates/
	bootstrap.php

www/
	js/
	css/
	images/

libs/

log/

temp/
	cache/

tests/

Hlavní rozdíl je v tom, že složku app opustily datové adresáře temp a log. Cestu k adresáři temp určuje konstanta TEMP_DIR (resp. proměnná prostředí tempDir), která nemá výchozí hodnotu a je nutné ji nastavit (Nette se snaží být méně magické). Viz třeba skeleton.

Jelikož jde jen o výchozí nastavení, můžete používat jakoukoliv jinou strukturu. Pokud chcete zůstat u původní struktury, nastavte konstantu TEMP_DIR na adresář app/temp/ a proměnnou Debug::$logDirectory na app/log, případně použijte druhý parametr metody enable(). Nicméně cache se bude ukládat do podadresáře app/temp/cache, který je potřeba vytvořit a nastavit mu práva pro zápis.

arron

David Grudl napsal(a):

…který je potřeba vytvořit a nastavit mu práva pro zápis.

Nemohla by si zrovna cache svuj adresar vytvaret sama, pokud neexistuje? Mene magicke je nekdy lepsi (ackoliv zrovna me se to doceal libilo:-)), ale pamatovat si, ze kdyz chci pouzivat cache, tak musim jeste do tempu vytvaret dalsi adresar … :-/ Jsem toho nazoru, ze by se cache o sebe mela starat sama.

mcmatak

souhlas nehledě na to že po deploy mam skript který mi celý temp smaže automaticky, ale je fakt že bych tam mohl přidat i vytvoření této složky, každopádně zbytečná práce pro programátora

Patrik Votoček

Čekal jsem že složka temp bude ve skutečnosti složka data, ale budiž jdu si to překopat. :-p

gawan

ja mám ešte takú drobnosť…
Prvú vec, čo urobím po nakopírovaní skeletonu je, že premenujem document_root/ na web/. Zdá sa to len mne tak strašne dlhé? Ale nemám problém to robiť aj naďalej…

Šaman

Jsem pro automaticke vytvareni adresaru ve slozce TEMP.

Ondřej Mirtes

web je nicnerikajici nazev, my pouzivame public.

Tim chci rict, ze nema smysl to prejmenovavat, protoze kazdy ma jiny vkus :)

Filip Procházka

$cache->mkdir('temp/cache'); ++$automatic;

srigi

Osobne pouzivam www_root hlavne kvoli tomu, ze sa mi folder v Netbeansoch odsunie na koniec listingu projektu. To defaultne document_root strasi niekde medzi app a libs a mne to strasne vadi. Osobne by som prave kvoli tomuto bol za premenovanie na www_root v distribucii, ale je mi jasne, ze toto je IMO velka zmenu, ktoru asi nepresadim.

jtousek

Čekal jsem že složka temp bude ve skutečnosti složka data, ale budiž jdu si to překopat. :-p

A co použít spíše takovouto strukturu (místo temp a log):

data\
	cache\
	temp\
	log\

//EDIT: Nebo alespoň možnost nastavit složku pro cache manuálně.

Editoval jtousek (23. 9. 2010 16:56)

arron

Ono v zasade by to melo byt jeste trochu jinak:

www.neco.cz/
	data/ - tady se ukladaji veskera dynamicka data, ktera aplikace vytvari (CMS...)
		jedine tuhle slozku je potreba ve skutecnosti zalohovat (krome databaze prirozene)
	temp/ - sem se ukladaji vsechna data, ktera je mozne kdykoliv vymazat (cache...)
	log/ - logy (netreba dalsiho komentare)
	web/ - tady sedi samotna aplikace. Cela tahle slozka je pod kontrolou nejakeho SVN, GIT ci
		podobneho.
		Jsou to vsechno veci, ktere aplikace sama o sobe nikdy nemeni,
		ale je mozne to pomerne jednoduse updatovat, kdyz je to treba (nova verze aplikace atd.)
		aniz by hrozilo, ze se prepisi (smazou) dulezita data. Ve zkratce, jsou zde snadno
		obnovitelna data (z SVN ci podobneho)

		app/
		libs/
		document_root/
		whatever/

Je treba dalsiho komentare?

grey

já bych byl taky pro to, aby si cachce vytvářela složku automaricky, a document_root bych přejmenoval na public, přijde mi to nejlogičtější a nejhezčí :)

na1k

document_root nechat!

Je z toho na první pohled patrné, že to je složka do které se dostane návštěvník webu a že jsou v ní veřejná data. Web a jiné jsou sice názvy kratší, ale pojem je to úplně prázdný.

Případně něco jako www_root, což taky hned samo napovídá, že jde o root celého webu z pohledu uživatele.

Nilp

Public také říká, že jde o veřejnou část, a je hezčí. Public, web, www (od WWW_DIR), to už podle mě vyjde nastejno.

Editoval Nilp (23. 9. 2010 18:46)

redhead

Je to tak důležité? Můžete si to přenastavit a např. já do teď dělal v document_root a na serveru, kterej jsem teď dostal k dizpozici je public_html. Podle mě je tahle diskuse k ničemu

Ondřej Brejla

+1

westrem

srigi a na1k napsali

Suhlasim s argumentom co napisal srigi: www_root je podla mna (ak uz by sme chceli menit stavajuce) najvhodnejsi, pretoze:

je z neho jasne o co go
nemiesa sa v poradi medzi apps a lib ale je pekne na konci

aaron napsal

Ak spravne chapem tak ale uvodna cesta by bola www.neco.cz/web/document_root/ ako to riesis aby sa ti aj na request www.neco.cz/ zobrazila stranka? Dodatocnym .htaccess?

arron

westrem napsal(a):

Ak spravne chapem tak ale uvodna cesta by bola www.neco.cz/web/document_root/ ako to riesis aby sa ti aj na request www.neco.cz/ zobrazila stranka? Dodatocnym .htaccess?

Hlavni myslenka je, ze document_root daneho virtualu bude nastaveny do www.neco.cz/web/document_root/. Resim to nasledovne:

bud mam hosting, kde si to muzu nastavit (napr. vlastni server). To nejbezpecnejsi reseni, protoze pak se nikdo nedostane k datum, ke kterym nema mit pristup. Nevyhoda je takova, ze pokud jsou potreba nejake slozitejsi rewrite, tak se musi dat primo do definice toho virtualu, protoze z .htaccess neni pristup do z document_root do adresaru vyse.
nebo si to nemuzu nastavit a pak hodin index.php do www.neco.cz/ a prepisu tam prislusne cesty. .htaccess s rewrity hodim hned vedle, takze pokud tam nejsou nejake speciality, tak nemusim nic upravovat. Nicmene mam tam treba pridane rewrite na css a js

Editoval arron (23. 9. 2010 19:15)

Filip Procházka

redhead +1

v6ak

vrtak-cz:

temp – smažeš a nevadí to
data – smažeš a uživatelé smažou tebe ;-)

Nilp

Popravdě mě nenapadají žádná jiná dočasná data, než cache, jako idální mi připadá struktura data/{cache,sessions,logs,...}. Ale jsou to podružnosti, ať si to každý nastaví jak chce.

arron

Nilp napsal(a):

Popravdě mě nenapadají žádná jiná dočasná data, než cache, jako idální mi připadá struktura data/{cache,sessions,logs,...}. Ale jsou to podružnosti, ať si to každý nastaví jak chce.

No treba nahledy obrazku…

ve chvili kdyz to das do stejne slozky jako data, kam se ukladaji veci uploadovane z CMS, tak pak se to musis nejak vhodne vyloucit ze zalohy (protoze zalohovat to je nesmysl…), coz je minimalne opruz.

pekelnik

Proč se to jmenuje document_root je myslím celkem jasné.
Že by se to mohlo jmenovat jinak je také jasné.
Ovšem že někoho trápí jak se jmenuje adresář ve skeletonu to už mi jasné není.
Však si to můžete pojmenovat jak chcete no ni?

Osobně používám web ze stejného důvodu jako @srigi ;)

Jinak samozřejmě vítám tuhle úpravu, přestože sám mám odjakživa tyhle adresáře mimo app a sice v adresáři var.

Pro zájemce zajímavé čtení: http://www.pathname.com/…fhs-2.3.html :D

Editoval pekelnik (23. 9. 2010 22:57)

David Grudl

Podadresář cache by se asi vytvářet mohl.

Filip Procházka

Automatické vytváření složky cache už je na githubu :)

RDPanek

arron napsal(a):

westrem napsal(a):

Ak spravne chapem tak ale uvodna cesta by bola www.neco.cz/web/document_root/ ako to riesis aby sa ti aj na request www.neco.cz/ zobrazila stranka? Dodatocnym .htaccess?

Hlavni myslenka je, ze document_root daneho virtualu bude nastaveny do www.neco.cz/web/document_root/. Resim to nasledovne:

bud mam hosting, kde si to muzu nastavit (napr. vlastni server). To nejbezpecnejsi reseni, protoze pak se nikdo nedostane k datum, ke kterym nema mit pristup. Nevyhoda je takova, ze pokud jsou potreba nejake slozitejsi rewrite, tak se musi dat primo do definice toho virtualu, protoze z .htaccess neni pristup do z document_root do adresaru vyse.

nebo si to nemuzu nastavit a pak hodin index.php do www.neco.cz/ a prepisu tam prislusne cesty. .htaccess s rewrity hodim hned vedle, takze pokud tam nejsou nejake speciality, tak nemusim nic upravovat. Nicmene mam tam treba pridane rewrite na css a js

Řeším tak, že vyjmu index.php a změním cesty.

BigCharlie

Hlavní rozdíl je v tom, že složku app opustily datové adresáře temp a log. Cestu k adresáři temp určuje konstanta TEMP_DIR (resp. proměnná prostředí tempDir), která nemá výchozí hodnotu a je nutné ji nastavit (Nette se snaží být méně magické). Viz třeba skeleton.

Možná opomenutí, možná je to schválně, ale do skeletonu bych doplnil nastavení cesty k tempDir – předchozí věta vyzní tak, že to tam člověk najde. I když hláška je dostatečně výmluvná.

David Grudl

Vždyť tam je

BigCharlie

tak to se omlouvám za epic fail – oprašoval jsem dnes jeden starší projekt z Nette 0.9.4 na 2.x, ale do indexu mě vůbec nenapadlo se podívat – mám nějak zafixováno, „že na něj přeci nikdy sáhnout nemusím“.

Nilp

A TEMP_DIR se automaticky registruje jako tempDir proměnná v Environment? Nemůžu to nikde najít.

jtousek

Ano registruje.

kravčo

Nie neregistruje.

Environment pri požiadavke na premennú hľadá najprv medzi svojimi premennými, následne ak nenájde, hľadá medzi definovanými konštantami. Pre premennú myCoolVar hľadá konštantu MY_COOL_VAR.

Nilp

To je pěkně ošklivá a nezdokumentovaná magie :)
Edit: díky!

Editoval Nilp (5. 10. 2010 9:01)

Ani

Tak mě napadlo, že už asi není potřeba ten prefix c- u cache, když má vlastní adresář.