jak na drobečkovou navigaci

Bertram

Ahojte potřeboval bych poradit s nejakým jednoduchým řešením drobečkové navigace.

Podotýkám,že doplněk Navigation jsem se snažil pochopit,ale bez úspěchu (-:
Postrádám u něj trochu osvěty,je zde bohužel jen pár komentářů ve zdrojáku a bohužel v angličtině.
Ale pokud je to někde trochu rozvinuto poprosil bych o dkaz já to nenašel.

Zkoušel jsem například předávat do šablon pole pomocí nehož jsem tuto navigaci skládal,ale je to hodně úmorné řešení a poněkud zdlouhavé a nešťastné.

bojovyletoun

presenter_

 protected function createComponentNav(){


	$nav = new Navigation();
	$nav->setupHomepage("Titulní stránka", $this->link("Default:"));
	$nav->add("Odkazy", $this->link("Odkazy:"));
	$nav->add("Novinky", $this->link("Novinky:"));
}

šablona <body>{control Nav}<hr>{block #content}</body>

Bertram

Děkuji za odpověď,ale moc mi to nepomohlo.

Je to vlastně mírně modifikované to,co už je napsáno u tohoto doplňku.
Jak již jsem psal,nechápu jeho funkčnost,kde a jak využívat jeho možností.
V reálném nasazení je totiž potřeba něco jiného než:

Titulní stránka > Odkazy > Novinky

A kdybych to měl pro každý presenter a ještě navíc pro každou akci modifikovat
,tak mi přijde jednoduší si to opravdu předávat v tom poli.

Taky mě napadlo to tvořit na základě presenteru : getReflection()->getName()
a akce : $this->getAction()

Ale narazil jsem na problém s diakrikou atd.

redhead

Využil bych anotací (jména s diakritikou, případně i pro linky presenter:akce). Zamysli se nad tím a možná tě něco na ten způsob napadne.

jtousek

Můj osobní názor je že jména s diakritikou která se pak někde zobrazují rozhodně nepatří do anotací a dokonce ani do továrničky komponenty. Veškerá data a texty teoreticky patří do modelu, šablon nebo nějakého translátoru. Presenter by neměl takhle přímo ovlivňovat, co se objeví na výstupu, od toho je view, ne?

redhead

Ono záleží na okolnostech a složitosti webu, ale jinak v zásadě máš pravdu. Do modelu bych to ale nedal, protože se to týká té oné stránky (presenteru-view), navíc je to hezky pospolu, a když nemám multijazyčný web, tak nemusím mít ani translátory. O šabloně nemluvě, když se snažíme udělat drobečky.

Komponenta, která by si přes reflection tahala ty názvy (a případně cesty) z anotací z aktuální presenter-akce mi přijde docela elegantní. Nemusí se nutně jednat o zobrazované názvy, ale třeba o nějaké pole keys, přes které se dostane zobrazený text (a to už např. přes ty translátory, atd.). Byla by to prakticky analogie k allowed anotaci, s ní nemusíme na začátek každé akce psát if($user->isAllowed(..)).. Stejně tak nemusíme pro každou akci specifikovat v těle metody jaké drobečky zobrazit.

Ale jak říkám, záleží na okolnostech. Pokud by se do drobečků měli dávat i nějaké nestatické názvy (článků apod.), tak není o čem mluvit.

jtousek

Ano, v případě malého webu to ničemu nevadí a elegantní to bezesporu je, jen jsem upozorňoval, že to ruší koncept MVC. Jinak jak jsi mluvil o tom translátoru tak na to už anotace nejsou třeba – jako ten klíč může klidně sloužit název Presenteru.

Co když ale teoreticky nechci mít takováto data uložená někde centrálně v translatoru, ale jakoby u toho Presenteru? Nebo spíše, každý presenter by měl svůj submodul a aplikaci bych chtěl přidávat funkce prostým přidáváním a odebíráním těchto submodulů. Tato data pro drobečkovou navigaci by si tedy měl uchovávat každý submodul v sobě, zřejmě ve vrstvě View. Napadá někoho, jak to přesně ukládat?

redhead

Ono těch klíčů by mohlo být víc na jeden presenter/akci. Např. bych chtěl specifikovat nějaké podsekce. Protože většinou se s presentery/akcemi dostáváme na zanoření 2 (presenter → akce) nebo 3 (modul → presenter → akce). S více klíči (a cestami na jejich presentery/akce) by to bylo tvárnější a dalo by se pak s tím docela kouzlit.

jtousek

jj v tom máš pravdu, ale i tak, kde ukládat hodnoty, které těm klíčům budou odpovídat?

Tyto texty patří do View. Jediné co mě napadá je, že by komponenta pro navigaci měla pro každý presenter (submodul) zvláštní šablonu, kde by tyto texty byly.

Máš jiný nápad?

redhead

Ano, něco takového mě taky napadlo, mít vedle souboru presenterů a šablon i nějaký resource pro tyhle data. Ale nakolik je to hezké řešení nevím. Nic jiného mě nenapadá.

jtousek

jj o tom jsem taky přemýšlel. Takovýhle soubor by pak byl nejspíše konfigurák, tedy ini nebo neon. I když to zase moc nesedí do vrstvy View.. Nebo to hnát přes latte šablony? Ach jo, připadá mi jeden nápad horší než druhý.

JakubJarabica

Jeden spôsob je použiť komponentu Navigation, ja však preferujem skladanie drobečkov využitím dedičnosti blokov. Extrémny prípad mám napr. tu: kanadské bodovanie

Drobečky vyzerajú takto:
SportVin > hokejbal > Slovenská hokejbalová extraliga > extraliga – seniori > štatistiky > kanadské bodovanie

A riešim to tak, že v globálnom layout.phtml mám

{block #drobecky}SportVin{block #drobecky2}{/block}{/block}

a v každom (sub)module, či layoute dedím predchádzajúci blok drobečkov, do ktorého pridávam ďalšiu úroveň. V uvedenom prípade #drobecky2 ak v detských šablónach nebude predefinovaný, zostane prázdny. Dá sa to pekne ošetrit podmienkami ifCurrent.

Tiež to má výhodu v tom, že využívam premenné zo šablón a dá sa prípadne využiť Translator zo šablóny.

jtousek

Nebylo by to lepší řešit pomocí {include #parent} namísto číslování?

JakubJarabica

Zrejme hej, len som si nie istý, či niekedy práve vďaka číslovaniu nepotrebujem predefinovávať niektoré úrovne. Takto by som musel mať pevne definovanú štruktúru.

Bertram

JAM3SoN napsal(a):

A riešim to tak, že v globálnom layout.phtml mám
{block #drobecky}SportVin{block #drobecky2}{/block}{/block}
a v každom (sub)module, či layoute dedím predchádzajúci blok drobečkov, do ktorého pridávam ďalšiu úroveň. V uvedenom prípade #drobecky2 ak v detských šablónach nebude predefinovaný, zostane prázdny. Dá sa to pekne ošetrit podmienkami ifCurrent.

Nemohl by jsi to trošku rozvést,jsem opravdu v úplných začátcích a dle tohoto popisu jen mlhavě tuším o čem je řeč.

JakubJarabica

Mám globálny @layout.phtml, ktorý extendujem v layoute každého modulu. Mám napríklad modul Sutaz a submodul Liga, takže v @layout.html patriacemu do modulu Sutaz pridám do drobečkov sport a sutaz, to sa následne podedí do modulu Liga, kde pridám do drobečkov ligu(v subore @layout.phtml submodulu Liga). Následne(ak treba) tak tento layout dedím ešte layoutom jednotlivých presenterov a potom už v samostatných šablónach jednotlivých akcií definujem posledné drobečky. Čiže ukážka:

@layout.phtml

{block #drobecky}SportVin{block #drobecky2}{/block}{/block}

SutazModule/templates/@layout.phtml

{extends predchadzajuceho layoutu}
{block #drobecky2}sport, sutaz {block #drobecky3}{/block}{/block} // predefinovanie prazdneho bloku z predchadzajucej urovne

SutazModule/LigaModule/templates/@layout.phtml

{extends predchadzajuceho layoutu}
{block #drobecky3}liga {block #drobecky4}{/block}{/block} // predefinovanie prazdneho bloku z predchadzajucej urovne

Funguje to tak, že od spodu hore „prebublajú“ jednotlivé bloky a predefinujú prázdne z vyšších úrovní.

Ako písal jtousek, malo by v pohode fungovať aj toto:
@layout.phtml

{block #drobecky}SportVin{/block}

SutazModule/templates/@layout.phtml

{extends predchadzajuceho layoutu}
{block #drobecky}{include #parent}sport, sutaz{/block} // predefinovanie prazdneho bloku z predchadzajucej urovne

SutazModule/LigaModule/templates/@layout.phtml

{extends predchadzajuceho layoutu}
{block #drobecky}{include #parent}liga{/block} // predefinovanie prazdneho bloku z predchadzajucej urovne

Toto však pre mňa situáciu nerieši, lebo nemôžem custom predefinovať ktorú chcem úroveň blokov.

Bertram

Děkuji,už je mi to mnohem jasnější,vyzkouším.
A jaký je názor Vás ostatních je toto ta „správná“ cesta?

jtousek

Bertram: Jak už jsem řekl, raději bych použil {include #parent} pro načtení rodičovského bloku. Argument, že by to muselo mít pevnou strukturu je zde samozřejmě na místě, ale pokud to není vyloženě nutné udělat jinak, jsem v tomto případě pro pevnou strukturu. (To číslování se mi fakt nelíbí.)