Adresarova struktura knihovny Nette
- wdolek
- Člen | 331
Po nejake dobe jsem se opet podival na Nette, a ponekud jsem se musel skrabat na hlave, kdyz jsem videl rozmisteni trid v souborech/adresarich. Jsem si vedom toho, ze u Nette s RobotLoaderem to neni zas tak uplne zapotrebi, jenze co kdyz by nekdo rad pouzil Nette jako doplnek v jinem frameworku, ktery nedisponuje tak chytrym loaderem?
Napsal jsem si maly skriptik:
https://gist.github.com/834678
… a nechal si vypsat vysledky:
$ php tokenize.php ../__repos/nette/ Nette | grep "\[er\]" | sed "s/does not correspond to path/vs/"
[er] "Nette\ComponentContainer" vs "Nette/ComponentModel/ComponentContainer.php"
[er] "Nette\IComponent" vs "Nette/ComponentModel/IComponent.php"
[er] "Nette\Component" vs "Nette/ComponentModel/Component.php"
[er] "Nette\IComponentContainer" vs "Nette/ComponentModel/IComponentContainer.php"
[er] "Nette\RecursiveComponentIterator" vs "Nette/ComponentModel/RecursiveComponentIterator.php"
[er] "Nette\ITranslator" vs "Nette/Localization/ITranslator.php"
[er] "Nette\AmbiguousServiceException" vs "Nette/Injection/AmbiguousServiceException.php"
[er] "Nette\Context" vs "Nette/Injection/Context.php"
[er] "Nette\IContext" vs "Nette/Injection/IContext.php"
[er] "Nette\Database\DatabasePanel" vs "Nette/Database/Diagnostics/DatabasePanel.php"
[er] "Nette\Application\BadSignalException" vs "Nette/Application/exceptions/BadSignalException.php"
[er] "Nette\Application\ForbiddenRequestException" vs "Nette/Application/exceptions/ForbiddenRequestException.php"
[er] "Nette\Application\ApplicationException" vs "Nette/Application/exceptions/ApplicationException.php"
[er] "Nette\Application\AbortException" vs "Nette/Application/exceptions/AbortException.php"
[er] "Nette\Application\InvalidPresenterException" vs "Nette/Application/exceptions/InvalidPresenterException.php"
[er] "Nette\Application\BadRequestException" vs "Nette/Application/exceptions/BadRequestException.php"
[er] "Nette\Application\InvalidLinkException" vs "Nette/Application/exceptions/InvalidLinkException.php"
[er] "Nette\Application\RoutingDebugger" vs "Nette/Application/Diagnostics/RoutingDebugger.php"
[er] "Nette\Application\CliRouter" vs "Nette/Application/Routers/CliRouter.php"
[er] "Nette\Application\SimpleRouter" vs "Nette/Application/Routers/SimpleRouter.php"
[er] "Nette\Application\MultiRouter" vs "Nette/Application/Routers/MultiRouter.php"
[er] "Nette\Application\Route" vs "Nette/Application/Routers/Route.php"
[er] "Nette\Application\DownloadResponse" vs "Nette/Application/Responses/DownloadResponse.php"
[er] "Nette\Application\ForwardingResponse" vs "Nette/Application/Responses/ForwardingResponse.php"
[er] "Nette\Application\RedirectingResponse" vs "Nette/Application/Responses/RedirectingResponse.php"
[er] "Nette\Application\JsonResponse" vs "Nette/Application/Responses/JsonResponse.php"
[er] "Nette\Application\RenderResponse" vs "Nette/Application/Responses/RenderResponse.php"
[er] "Nette\Web\IHttpRequest" vs "Nette/Http/IHttpRequest.php"
[er] "Nette\Web\UriScript" vs "Nette/Http/UriScript.php"
[er] "Nette\Web\IUser" vs "Nette/Http/IUser.php"
[er] "Nette\Web\SessionNamespace" vs "Nette/Http/SessionNamespace.php"
[er] "Nette\Web\HttpResponse" vs "Nette/Http/HttpResponse.php"
[er] "Nette\Web\User" vs "Nette/Http/User.php"
[er] "Nette\Web\HttpUploadedFile" vs "Nette/Http/HttpUploadedFile.php"
[er] "Nette\Web\Uri" vs "Nette/Http/Uri.php"
[er] "Nette\Web\HttpContext" vs "Nette/Http/HttpContext.php"
[er] "Nette\Web\Session" vs "Nette/Http/Session.php"
[er] "Nette\Web\IHttpResponse" vs "Nette/Http/IHttpResponse.php"
[er] "Nette\Web\HttpRequest" vs "Nette/Http/HttpRequest.php"
[er] "Nette\Web\HttpRequestFactory" vs "Nette/Http/HttpRequestFactory.php"
[er] "Nette\Debug" vs "Nette/Diagnostics/Debug.php"
[er] "Nette\DebugHelpers" vs "Nette/Diagnostics/DebugHelpers.php"
[er] "Nette\DebugPanel" vs "Nette/Diagnostics/DebugPanel.php"
[er] "Nette\IDebugPanel" vs "Nette/Diagnostics/IDebugPanel.php"
[er] "Nette\Environment" vs "Nette/Environment/Environment.php"
[er] "Nette\Configurator" vs "Nette/Environment/Configurator.php"
[er] "Nette\Forms\Button" vs "Nette/Forms/Controls/Button.php"
[er] "Nette\Forms\SelectBox" vs "Nette/Forms/Controls/SelectBox.php"
[er] "Nette\Forms\FormControl" vs "Nette/Forms/Controls/FormControl.php"
[er] "Nette\Forms\MultiSelectBox" vs "Nette/Forms/Controls/MultiSelectBox.php"
[er] "Nette\Forms\SubmitButton" vs "Nette/Forms/Controls/SubmitButton.php"
[er] "Nette\Forms\FileUpload" vs "Nette/Forms/Controls/FileUpload.php"
[er] "Nette\Forms\ImageButton" vs "Nette/Forms/Controls/ImageButton.php"
[er] "Nette\Forms\RadioList" vs "Nette/Forms/Controls/RadioList.php"
[er] "Nette\Forms\TextArea" vs "Nette/Forms/Controls/TextArea.php"
[er] "Nette\Forms\HiddenField" vs "Nette/Forms/Controls/HiddenField.php"
[er] "Nette\Forms\TextInput" vs "Nette/Forms/Controls/TextInput.php"
[er] "Nette\Forms\TextBase" vs "Nette/Forms/Controls/TextBase.php"
[er] "Nette\Forms\Checkbox" vs "Nette/Forms/Controls/Checkbox.php"
[er] "Nette\Forms\DefaultFormRenderer" vs "Nette/Forms/Renderers/DefaultFormRenderer.php"
[er] "Nette\Templates\LatteFilter" vs "Nette/Latte/LatteFilter.php"
[er] "Nette\Templates\LatteMacros" vs "Nette/Latte/LatteMacros.php"
[er] "Nette\Templates\LatteException" vs "Nette/Latte/LatteException.php"
[er] "Nette\Templates\CachingHelper" vs "Nette/Latte/CachingHelper.php"
[er] "Nette\Framework" vs "Nette/tools/Framework.php"
[er] "Nette\Tokenizer" vs "Nette/tools/Tokenizer.php"
[er] "Nette\Web\Html" vs "Nette/tools/Html.php"
[er] "Nette\JsonException" vs "Nette/tools/JsonException.php"
[er] "Nette\String" vs "Nette/tools/String.php"
[er] "Nette\ArrayHash" vs "Nette/tools/ArrayHash.php"
[er] "Nette\MapIterator" vs "Nette/tools/iterators/MapIterator.php"
[er] "Nette\SmartCachingIterator" vs "Nette/tools/iterators/SmartCachingIterator.php"
[er] "Nette\CallbackFilterIterator" vs "Nette/tools/iterators/CallbackFilterIterator.php"
[er] "Nette\RecursiveCallbackFilterIterator" vs "Nette/tools/iterators/RecursiveCallbackFilterIterator.php"
[er] "Nette\GenericRecursiveIterator" vs "Nette/tools/iterators/GenericRecursiveIterator.php"
[er] "Nette\InstanceFilterIterator" vs "Nette/tools/iterators/InstanceFilterIterator.php"
[er] "Nette\ObjectMixin" vs "Nette/tools/ObjectMixin.php"
[er] "Nette\SafeStream" vs "Nette/tools/SafeStream.php"
[er] "Nette\TokenizerException" vs "Nette/tools/TokenizerException.php"
[er] "Nette\ArrayList" vs "Nette/tools/ArrayList.php"
[er] "Nette\Callback" vs "Nette/tools/Callback.php"
[er] "Nette\Finder" vs "Nette/tools/Finder.php"
[er] "Nette\RecursiveDirectoryIteratorFixed" vs "Nette/tools/Finder.php"
[er] "Nette\Paginator" vs "Nette/tools/Paginator.php"
[er] "ArgumentOutOfRangeException" vs "Nette/tools/exceptions.php"
[er] "InvalidStateException" vs "Nette/tools/exceptions.php"
[er] "NotImplementedException" vs "Nette/tools/exceptions.php"
[er] "NotSupportedException" vs "Nette/tools/exceptions.php"
[er] "DeprecatedException" vs "Nette/tools/exceptions.php"
[er] "MemberAccessException" vs "Nette/tools/exceptions.php"
[er] "IOException" vs "Nette/tools/exceptions.php"
[er] "FileNotFoundException" vs "Nette/tools/exceptions.php"
[er] "DirectoryNotFoundException" vs "Nette/tools/exceptions.php"
[er] "FatalErrorException" vs "Nette/tools/exceptions.php"
[er] "Nette\FreezableObject" vs "Nette/tools/FreezableObject.php"
[er] "Nette\RegexpException" vs "Nette/tools/RegexpException.php"
[er] "Nette\Json" vs "Nette/tools/Json.php"
[er] "Nette\Object" vs "Nette/tools/Object.php"
[er] "DateTime53" vs "Nette/tools/DateTime53.php"
[er] "Nette\Tools" vs "Nette/tools/Tools.php"
[er] "Nette\ArrayTools" vs "Nette/tools/ArrayTools.php"
[er] "Nette\IFreezable" vs "Nette/tools/IFreezable.php"
[er] "Nette\Neon" vs "Nette/tools/Neon.php"
[er] "Nette\NeonException" vs "Nette/tools/Neon.php"
[er] "Nette\Image" vs "Nette/tools/Image.php"
Ocenil bych, kdyby se Nette drzelo nejakeho sandardu – popsano zde: PSR-0 Final Proposal, http://groups.google.com/…nal-proposal
Jde o to, ze trida Foo\Bar
je umistena v souboru
Foo/Bar.php
a ne jinde. Take je mi jasne, ze uz asi neni prilis
mnoho casu s tim neco udelat.
Rozhodne bych byl rad, kdyby se nad mym vyplodem nekdo zamyslel a treba vyvolal nejakou diskusi – proc to zmenit/nezmenit.
- Jan Tvrdík
- Nette guru | 2595
To je naprostá blbost. Struktura Nette je navržená tak, aby se s ní
programátorovi dobře pracovalo. Pokud budu chtít použit Nette bez
RobotLoaderu
, tak použiji NetteLoader
.
- Patrik Votoček
- Člen | 2221
Navíc je to umocněné faktem že aktuálně je adresářová struktura poněkud rozhašená kvůli přichazejícímu přejmenování namespace (adresáře jsou podle nových namespace ale namespace samotné jsou zatím staré)
btw Nette si na PSR-0 nikdy nehrálo a asi ani nikdy nebude…
- wdolek
- Člen | 331
Struktura Nette je navržená tak, aby se s ní programátorovi dobře pracovalo
inu to je prave velmi sporne :D … ja jsem si ted navykl na to, ze kdyz mam
A\B\C\D tridu, tak se na ni podivam v souboru A/B/C/D.php …
bohuzel v Nette je ta trida treba v A/D.php … coz zrovna pohodlne neni.
clovek musi hledat, grepovat zdrojaky a kdo vi co. (a jeste horsi pripad jsou
Forms\Controls …)
Pokud budu chtít použit Nette bez
RobotLoaderu
, tak použijiNetteLoader
.
takze kvuli formularum budu muset includnout cele Nette? no to je pekna hloupost ;) … (a nebo budu muset projit zdrojaky a ruco si to naincludovat, coz popira to, ze je to navrzene k usnadneni prace)
btw Nette si na PSR-0 nikdy nehrálo a asi ani nikdy nebude…
a to je velka skoda… vsichni na to hraji, Nette ne…
Editoval wdolek (19. 2. 2011 11:04)
- redhead
- Člen | 1313
Chlapi, nic proti, ale jsem taky proto aby namespace reflektovaly adresáře. Má to tak taky Java a nedokážu najít jedinou výtku, spíš je to pro mě plus.
Co se týče pohodlnosti programátora, tak žádnou pohodlnost nevidím.
V čem přesně? Stejně používáte IDE, kde se namespace doplňuje samo, a
k tomu RobotLoader. To by jste ke své spokojenosti také mohli hodit všechny
soubory do složky Nette/
a bylo by po starostech..
- Patrik Votoček
- Člen | 2221
wdolek napsal(a):
a to je velka skoda… vsichni na to hraji, Nette ne…
Proto má Nette RobotLoader a né „PSR-0 loader“.
Ono se to třeba změní zároveň s odstřihnutím (až přijde – doufám že brzo) podpory pro PHP 5.2.
Btw.: taky se mě líbí co namespace to složka ale zase se mě líbí složka pro exception nebo routy i když vlastní namespace nemají.
- jasir
- Člen | 746
Patrik Votoček, Jan Tvrdík
Chlapi, Nette přeci Robotloader nepoužívá vůbec :-), čili to spolu nesouvisí.
Já osobně, když už „detailní namespaces“, viz jinde, tak ať namespace = adresář. To je jediné intuitivní při hledání souboru ve frameworku, jinak aby se člověk učil nějakou logiku/nelogiku, se kterou se prý „dobře pracuje“, ovšem fakt nevím proč.
Editoval jasir (19. 2. 2011 11:35)
- wdolek
- Člen | 331
No ja bych nove vyjimky, ktere pridava Nette, dal proste do
Nette\Exceptions
. Kolik sem si uzil starosti s
NotImplementedException
– celou dobu to v IDE vypadalo, ze je
to klasicka SPL vyjimka. Kdyz sem ji pak chtel pouzit jinde, tak sem se hrozne
divil, ze mi to pada kvuli jeji neexistenci. … coz znamena, ze toto dle honzy
pohodlne pouzivani akorat uci programatora blbostem.
Ale chapu, ze pokud jde o neco jako „vendor-lock-in“, tak je to prinosne :D Jen pak bude problem na Nette nekoho nalakat ;)
- Jan Tvrdík
- Nette guru | 2595
jasir napsal(a):
Chlapi, Nette přeci Robotloader nepoužívá vůbec :-), čili to spolu nesouvisí.
Mýlíš se. Zapnutí RobotLoaderu
vypne
NetteLoader
.
wdolek napsal:
toto dle honzy pohodlne pouzivani akorat uci programatora blbostem
Nic takového jsem nikdy neřekl.
takze kvuli formularum budu muset includnout cele Nette?
Proč bys to proboha dělal? Chceš, aby se ti Nette načítalo samo? –
Použij Nette\Loaders
. Chceš něco dalšího? – načte se
automaticky, až bude potřeba.
S jmennými prostory pracuji jinak, než se soubory. Zatímco jmenné
prostory mi napovídá IDE, tak složky si proklikávám sám. Tzn., že jmenné
prostory musí dávat smysl logický, zatímco adresářová struktura musí
být navržená tak, aby se dobře proklikávala. Není nezbytně nutný jmenný
prostor Nette\Forms\Controls
, protože by to pro mě znamenalo
více psaní. Ale složka Nette/Forms/controls
je potřeba,
protože mi umožňuje rychleji najít třídu, kterou potřebuji.
- wdolek
- Člen | 331
Není nezbytně nutný jmenný prostor
Nette\Forms\Controls
, protože by to pro mě znamenalo více psaní. Ale složkaNette/Forms/controls
je potřeba, protože mi umožňuje rychleji najít třídu, kterou potřebuji.
use case:
wdolek si chce najit zdrojovy soubor pro tridu
Nette\Forms\Checkbox
. ze ZF, Symfony, … dalsiho trilionu
frameworku… je zvykly na nejaky obecny (vyse zmineny „standard“) zpusob
pojmenovani trid/souboru.
vyda se tedy nejprve do slozky Nette
, pak hleda slozku
Forms
– nalezne ji, prechazi do ni. nyni programator ocekava
soubor Checkbox.php, ale at kouka jak kouka, zadny takovy tam neni. co ted?
- jak bych asi postupoval v terminalu (co bych psal):
nano Ne<tab>\Fo<tab>\Chec<tab>k<tab>b<tab>… FFFFUUU
- jak bych postupoval v nautilu/exploreru/…:
kliknu na zlutou slozku Nette, kliknu na zlutou slozku Forms, koukam po bile ikonce reprezentujici php soubor Checkbox.php… FFFUUU
takze bych tu pohodlnost videl spise v tom, ze s Nette pracujes nekolik let
a vis ze to tak je. v opacnem pripade je to
locate
/find
/grep
, popripade klik
klik klik klik klik klik …
- Jan Tvrdík
- Nette guru | 2595
takze bych tu pohodlnost videl spise v tom, ze s Nette pracujes nekolik let a vis ze to tak je. v opacnem pripade je to
locate
/find
/grep
, popripade klik klik klik klik klik klik …
Ano, vím z hlavy, kde co najdu. Lituji lidi, kteří se pohybují
v terminálu, a také lidi, kteří neumí používat Průzkumník / Total
Commander a klikají myší. I v hloupém průzkumníku se dá pohybovat
neuvěřitelně rychle. Stačí zmáčknout N
⇒ vidím (!)
zvýrazněnou složku Nette (to terminál nemá) ⇒ Enter ⇒ F
⇒ vidím zvýrazněnu složku Forms ⇒ Enter ⇒ Ch
⇒ nevidím
zvýrazněno Checkbox.php ⇒ očima přeletím celý seznam,
intuitivně otvírám Controls ⇒ Ch
a
hotovo.
- hrach
- Člen | 1838
Tyvole, Honzo, nerikam ze nevyvijim na WIN a pouzivam Speedcommander, ale na serveru je treba taky pracovat! A tam je teda ve vetsine pripadu konzole. A rikej si co chces, ale wdolek ma v tomto naprostou pravdu. A pokud pouziva konzoli na locale, tak to neni vec k litovani. K litovani je akorat dana situace, ze tu je 10 nette-like-guru lidi, ktery maji stejne ruzne predstavy o „nejlepsim moznem reseni“ namespace v Nette, ty se nějak dohodnou a vysledkem je to, ze to nam „beznym“ lidem stejne nevyhovuje a zpusobi to BC breaky.
A btw, v konzoli cd n<tab><tab> a 1) jsem tam, nebo 2) vidim, z ceho muzu vybirat ← a to mi pruzkumnik nevyfiltruje :P
Editoval hrach (20. 2. 2011 12:33)
- wdolek
- Člen | 331
nevidím zvýrazněno Checkbox.php ⇒ očima přeletím celý seznam, intuitivně otvírám Controls ⇒
Ch
a hotovo.
samozrejme, ze si pak intuitivne reknu, ze je to asi v
controls
, ale jeminkote :D ja se nechci zastavit v procesu hledani
souboru, a patrat v pameti nebo intuitivne odhadovat, kde to teda asi je, kdyz
to neni tam, kde to ocekavam.
a kdyz jsi nakousl ten total commander – nema on ten quick search udelany
prave tak, ze ti uplne zmizi vse kolem? takze pri zadani „Chec…“ ti vse ve
slozce zmizi (protoze tam nic takoveho neni) a ty pak vis prd, ze je tam nejaky
adresar controls
?
Editoval wdolek (20. 2. 2011 11:19)
- Filip Procházka
- Moderator | 4668
netbeans? CTRL+O (najít typ) "Chec" ENTER
konzole? $ mc
průzkumník? fuj…
Všeobecně mám raději když soubor najdu podle jeho namespace, ale
protože mám IDE (hezky se na něj vymlouvá, že?) tak si hledám podle typu.
Jak často potřebujete najít nějaký soubor z knihovny Nette na serveru? Tu
přeci maximálně tak zkopírujete nebo provedete
git pull origin master
.
Já když mám hodně souborů, v nějaké komponentě třeba, tak si ji
taky rozděluju podle logiky. Udělám si složku
komponenta\containers
, komponenta\mappers
,
komponenta\builders
, … ale nechávám to všechno v jednom
namespace komponenta
Máme NetteLoader
a RobotsLoader
, je proto úplně
jedno v jakých je to adresářích. Soubory se dají najít vždycky snadno a
když si je chci prohlédnout, proč bych je otevíral na serveru, když je tam
úplně to stejné, co mám na localhostu.
Tato diskuze je bezpředmětná, bežte raději kritizovat namespacy :)
Editoval HosipLan (20. 2. 2011 12:56)
- bojovyletoun
- Člen | 667
<ot> já bych zrušil i namespace<ot>
Původně jsem byl taky pro „přísnou“ konvenci z důvodu, že to asi bude rychlejší a srozumitelnější. Jenže pro mě je to srozumitelné i takhle (co kde leží)- něco dojde hned (Form/Controls) a něco si člověk zapamatuje (exceptions, shortcuts). Samozřejmě časem (měsíc,dva).
Pak je tu skvělé Nette API, které se dá stáhnout. A když něco nemohu
najít, tak není problém v totalcommanderu
zmáčknout Alt F7 Alt t DownloadRespo Enter
Jinak v totalcommanderu jde filtrovaný výpis souborů, přepíná se
Ctrl S
, pokud je filtrováno, ukáže se trychtýřek.Esc filtr
zruší.
PS: Díky za Ctrl O
– to je pěkný
pomocník
Abych se vyjádřil, tak mě je jedno, jestli třídy budou uložené podle PSR-0, nebo ne, když se něco přesune tak si na to zvyknu, ale měnit něco jen tak je zbytečné.
- Lopata
- Člen | 139
Mně také přišlo rozdělení do složek poněkud bizarní, ale pak jsem se naučil používat feturu v NetBeans Ctrl+klik na třídu/funkci/cokoliv, která vám otevře soubor, ve kterém se to nachází. Do zdroje se stejně potřebujede kouknout skoro vždy když už jméno té třídy máte stejně napsané. Naučil jsem se s tím žít a dnes se pomocí tohoto dostanu k souboru stejně rychleji, než kdyby to rozložení soborů bylo sebelepší. IDE to pořeší. Souhlasím s HosipLanem, že důležitější jsou namespacy. Já takhle totiž s adresářovou strukturou vůbec nepřijdu do styku.
- Honza Marek
- Člen | 1664
Hádáte se o ptákovinách. Tady je otázka jediná – upřednostnit drobné zlepšení pohodlí komunity, co vyvíjí Nette nebo uživatelů, kteří chtějí používat jen část Nette v jiném frameworku a načítat ho pomocí externího autoloaderu.
- wdolek
- Člen | 331
Honzo, diky…
diskuse se zvrhla na to, jak je to v IDE/Total Commanderu a jinde bezpredmetne, kde co je. to mozna ano. duvodem, proc me soucasny stav poburuje neni v tom, ze se to blbe hleda na urovni fs, ale spise v tom, ze s timto rozdelenim nemohu pouzit standardni loadery ze ZF, Symfony, … a jinych – nemohu vlastne ani vytvorit zadny jiny loader, ktery by tridu pouzil (includoval soubor), protoze evidentne neexistuje zadne pravidlo (a udelat logiku, ktera pozna, ze trida je control, a tak asi bude v adresari controls… to je trosku overhead).
takze, zapomenme na IDE, na Total Commandery, na terminaly… na to, ze mame git a podobne. soustredme se v teto debate na to podstatne – absence rozumneho pravidla, ktere by umoznilo jednoduse nacitat auto_loadem tridy z Nette bez pouziti NetteLoaderu nebo RobotLoaderu, popripade nejakeho prihloupleho hledani kde co je a vytvareni nejakych mapovani…
- Filip Procházka
- Moderator | 4668
Kdyby jsi otázku položil takto hned na začátku, tak se nemusíme „hádat“ :)
Moje otázka: Proč je problém použít „ten škaredý“
NetteLoader
, který to řeší za tebe?
A klidně se budu opakovat: Není to jedno? (asi jsem rozmazlenej RobotLoaderem)
- wdolek
- Člen | 331
Kdyby jsi otázku položil takto hned na začátku, tak se nemusíme „hádat“ :)
wdolek napsal v prvnim postu
„… jenze co kdyz by nekdo rad pouzil Nette jako doplnek v jinem frameworku …“
;)
Moje otázka: Proč je problém použít „ten škaredý“
NetteLoader
, který to řeší za tebe?
to mam tedy v projektu psanem v ABC Frameworku pouzivat jak loader
ABC Frameworku, a kdyz ten failne, tak pouzit NetteLoader
?
(takze zbytecne stravim cas vymyslenim nejakeho „sveho“ loaderu, ktery to
cele ohandluje)… nebo to lze resit jinak? jak?
nebylo by lepsi, aby to proste fungovalo „out-of-box“ aniz bych musel na neco sahnout, neco konfigurovat, … (tedy diky nejakemu domluvenemu pravidlu, jak se to bude delat)
Není to jedno?
ne, neni to jedno. chce byt Nette takovy hobby framework pro par obdivovatelu, nebo chceme Nette poslat do sveta?
a k cemu jsou treba coding standards? kdyby si kazdy jednotlivec psal zdrojak jak jemu se to libi, tak tu mame tak neprehledne zdrojaky, az by z toho nakonec vsichni plakali. myslim, ze s navrhem jak pojmenovavat tridy/jmenne prostory/adresare v kterych se skripty nachazi je to podobne. jde o to, usnadnit si praci v momente, kdy programator prechazi od projektu k projektu, pouziva jednu cast projektu v druhem a pod.
samozrejme, pokud si komunita Nette preje mit vlastni pisecek a ignorovat okolni svet, proc ne. v takovem pripade mi ale prijde, ze vynalozene usili na framework je zbytecne – protoze dela radost jen nekolika malo lidem.
- wdolek
- Člen | 331
a jeste bych rad dodal, ze za extremni nesmysl povazuji umisteni
„zakladniho kamene“ frameworku – Nette\Object
do slozky
tools
, protoze to s tools
nema nic spolecneho.
v tools
bych ocekaval skriptiky, ktere s frameworkem pramalo
souvisi (tedy ne zadne jeho komponenty), ale spis skripty pro nejakou
„udrzbu“ projektu, generovani skeletonu, a … co ja vim co.
take se pozastavuji nad tim, proc jsou nektere vyjimky v
exceptions.php
a nektere maji vlastni soubor
RegexpException
…
urcite mi filip nebo honza vysvetli tu uzasnou logiku, ktera se za tim skryva ;D … dekuji
- Filip Procházka
- Moderator | 4668
wdolek napsal v prvnim postu …
;)
Musíš víc jasně, i pro nás pomalejší :P
ne, neni to jedno. chce byt Nette takovy hobby framework pro par obdivovatelu, nebo chceme Nette poslat do sveta?
Ale já to neobhajuju, já jenom zastávám stanovisko, že je mi to jedno :D Ale máš pravdu, že standartizací se to dostane mezi více lidí :)
(takze zbytecne stravim cas vymyslenim nejakeho „sveho“ loaderu, ktery to cele ohandluje)… nebo to lze resit jinak? jak?
vždycky jsem si myslel, že autoloading se řadi do fronty a
nenahrazuje předchozí definovaný. Proto když zařadím dva autoloadery za
sebe, tak když jeden nenajde třídu, vrátí ho ten druhý, popřípadě ani
jeden, nebo ne? + class_exists
?
Editoval HosipLan (20. 2. 2011 18:30)
- Filip Procházka
- Moderator | 4668
nooo ono to tak asi i funguje, pokud použiješ __autoload
, ale
spl_autoload_register
to řadí :)
- Jan Tvrdík
- Nette guru | 2595
Tady se to koukám docela zvrhlo :)
RobotLoader
není vhodný, když má projekt hodně souborů
(A Zend jich hodně má).
- Tharos
- Člen | 1030
arron: Ono je to navíc asi trochu i o přístupu. To, že RobotLoader žádné konvence nevyžaduje, je dvousečná zbraň. Pro jednu skupinu vývojářů je to skvělá věc, jiní zase vítají, když jim framework jasně definuje pravidla (a to se přirozeně týká i uspořádání souborů na serveru).
Nette je dost benevolentní framework (viz například volnost v modelové vrstvě) a je tak orientované řekl bych spíše na zkušenější programátory. Těm méně zkušeným dává možná až příliš velkou volnost „prasení“. :) Řekl bych, že většina významných světových frameworků se snaží být méně benevolentní, a proto v nich není loader typu RobotLoader.
Editoval Tharos (20. 2. 2011 22:29)
- wdolek
- Člen | 331
arron napsal(a):
Mno, vzhledem k tomu, co tu napsal HospiLan (#27), tak uz je tato debata asi bezpredmetna:-) Asi by se tu dala zacit dalsi o tom, jestli ma Nette jasna pravidla a proc, ale poustet se mi do ni nechce:-)
neni bezpredmetna. to ze se loader registruje jako dalsi v poradi je stale vec navic.
- programator si musi v bootstrapu pro zvoleny FW pridat nejaky loader pro Nette k tomu, ktery jiz ma (nemluve o duvodu proc by nekdo musel kvuli nejake soucasti brat z frameworku i jeho loader!)
- pri kazdem pozadavku na aplikaci skript vykonava dalsi nesmysly navic – na blogisek asi dobry, ale u nejake vetsi aplikace bych se vyvaroval vsem zbytecnostem
… a navic mam rad poradek :)
PS: zda se, ze se nikdo nema k reakci na #24 – pro me dukaz toho, ze nejake pravidlo by zavedeno byt melo, protoze soucasna struktura taktez neni zcela koser (a kdyz uz by se to zmenilo, proc nesahnout po nejakem common pravidlu)
Editoval wdolek (21. 2. 2011 0:31)
- Filip Procházka
- Moderator | 4668
Mám třeba teď v projektu 3 frameworky, z RobotLoaderu v Nette jsem si kompletně vyloučil libs a načítá jenom adresář app. Na symfony (byť používám jenom konzoli) mám jeho vlastní loader (jedna instance jedné třídy). Na Zend (kvůli GDATA) mám taky jeho loader (jedna instance jedné třídy). Nette má pak taky svůj loader.
Všechno je lazy. Nette, Symfony i Zend + aplikaci načítá RobotLoader. Nikdy nemám načtené nic co v aktuálním requestu nevyužiju.
Samozřejmě to neomlouvá absenci pravidla pro umístění tříd v adresářové struktuře. A máš pravdu, že takové pravidlo by se opravdu hodilo. :)
//edit: jo a zapoměl jsem na Doctrine 2, na ten používám taky jeho
nativní Doctrine/Common/ClassLoader
Editoval HosipLan (21. 2. 2011 7:51)
- paranoiq
- Člen | 392
jména tříd a adresářová struktura knihovny mají úplně jiný účel a většinou i jiné uživatele
adresáře nejčastěji používá autor knihovny a hlavní je, aby vše bylo logicky roztříděno a dalo se rychle najít při změnách v kódu
oproti tomu třídy samotné nejčastěji používají uživatelé a je jim většinou šuma fuk, kde se třídy berou. hlavní je, aby jejich jména byla 1) popisná a 2) stručná
při pohledu na názvy tříd třeba v takovém ZF, který přístup 1:1 praktikuje, je hned jasné, že bod 2) nesplní. a někdy se kvůli délce názvů ztrácí v šumu i ta popisnost
snažit se napasovat jmenné prostory 1:1 na filesystém je píčovina a u některých knihoven „z nouze ctnost“
- David Grudl
- Nette Core | 8218
Tady se motá hodně věcí dohromady, tak postupně.
- Načítání tříd z Nette opravdu není potřeba za žádných okolností
řešit, ať už se používá jen část frameworku nebo Nette ve spojitosti
s jinou knihovnou. Tohle prostě funguje automaticky tím, že se zavolá
require 'Nette/loader.php'
resp.require 'nette.min.php'
. Nesouvisí s tím ani RobotLoader. - Adresářová struktura víceméně odpovídá mým představám o kategorizaci/katalogizaci tříd frameworku.
- Jmenné prostory odpovídají historickému vývoji. Zde by mělo dojít k větším změnám, které sice dovedu realizovat bez BC breaku, ale dokud se nedohodne definitivní podoba, nechci se do toho pouštět.
- Zatím jsme se dohodli, že se nedohodneme :-) Nebo že bychom si to rozdali v sobotu na PS?
- Patrik Votoček
- Člen | 2221
David Grudl napsal(a):
Tady se motá hodně věcí dohromady, tak postupně.
- Zatím jsme se dohodli, že se nedohodneme :-) Nebo že bychom si to rozdali v sobotu na PS?
Není špatný nápad stejě tak by šlo DI.
<OT>Máme sehnat bazének a bahno?</OT>