Co takhle fáze pro AJAX requesty?

@22: Handler na to mám, nevím jak jinak bych to dělal :), ale není pravda, že pak při volání signálu mám jen onu handle fázi, mám právě všechny tři – actionDetail, handleKomenter a renderDetail

Znamenalo by to tedy, že pokud bych chtěl AJAXovat, měl bych vše v action a render fázi obalit do podmínky if(!$this->isAjax()) { ... } protože jinak by se to s největší pravděpodobností vykonávalo zbytečně.

Pokud ale chci invalidovat snippet, musí (pravděpodobně – jiný způsob neznám) dojít k renderování. A tím, že většinou v render fázích bývá plnění šablony → volání dotazů na db (jako například getPhotos(), getFavouritePhotos() apod.), bych sem musel dát tu samou podmínku (viz výš).

Možná by stačilo, kdybych mohl odeslat payload s tím, že se vyrendruje šablona, ale nedojde k volání samotné fáze render (vím, trochu se to odporuje). Nebo spíš že by se vybraly jen ty invalidované snippety ze šablony, ty se naplnily daty a ty bych mohl odeslat do payload.

Editoval joe (29. 6. 2011 2:03)

že se v podstatě natahuje znovu stránka akorát se vymění ta část stránky, která je invalidní…

Tohle nevím jestli je to, o čem píšu :)

že se provede celej životní cyklus

O tohle mi jde. Protože se v něm provede úplně všechno, jakoby to AJAX request nebyl. A tak když bych chtěl třeba přes AJAX (signál) nastavit nějakou proměnnou (tzn. nepotřeboval bych vůbec db), tak i přes to, by se provedly všechny dotazy, co jsou naházený v těch různých fázích presenteru – pokud to nebude dostatečně ošetřený. Tzn. že pak ten AJAX tam je k ničemu, protože se vlastně provádí jako kdyby tam vůbec nebyl, ale jen s tim rozdílem, že se ta stránka znovu nenačte…

Díky za odkazy, seriál znám pomalu už nazpaměť a ten komentář, na který odkazuješ je už rok starý :-) Každopádně v tom seriálu o AJAXu jsem neobjevil nic, co by „problému“ nějak pomohlo.

Nepoužíváš AJAX na stránce, kde kromě toho, co chceš mít AJAXem, taháš i jiná data? Pak bych chtěl vidět, jak to máte kdo ošetřené :-)

Editoval joe (29. 6. 2011 8:10)

Pomocí komponenty to sice můžu mít, nicméně tam chybí to nejdůležitější

if($this->presenter->isAjax()) {
	$this->snippetMode = TRUE;
	$this->invalidateControl();
	$this->render();
	$this->getPresenter()->sendPayload();
}

Protože jinak opět dojde k volání všeho i na aktivním presenteru. Ale to není řešení. Používat komponentu jenom z toho důvodu, že používám AJAX se mi teda nelíbí, to si to raději projdu a napíšu podmínky, než vytvářet komponentu pro jednu věc ;)

Editoval joe (29. 6. 2011 8:50)

V tom případě jsi vůbec nepochopil sílu Nette :)

Je to možné :), plno věcí neznám a rád si nechám poradit

Kdyby jsi měl všechno jako komponenty, tak ti nevadí, co se děje v presenteru.

Jakto? Vem si třeba tu zmíněnou komponentu PollControl. Dám ji na stránku (třeba profil uživatele, viz výš ten wireframe). A pokud ji zajaxovatím, tak přece nechci volat to, co je v presenteru – to mě zajímá jenom v případě klasickýho požadavku. V případě AJAXu ale už ne, protože by se vše načítalo zbytečně → a to je to, o co mi jde.

Pomocnou metodu (ajaxSendComponent) si napsat můžu, ale to neřeší ten problém, protože pokud jako komponentu do ní dosadim presenter, zase se bude volat renderXXX a tam to zase musim opodmínkovat.

Tzn., že já chci v tom signálu handleMoreComments ukončit cyklus presenteru, ale chci invalidovat snippet, abych to měl v payloadu. Ale už mě nezajímá to ostatní, co je v renderXXX, kde bude něco jako $this->template->comments = $this->comments->getAll();

Ty jsi nepochopil o co mi jde. Komponenty, když jsou v továrničkách a tvoříš je pomocí DI, tak jak jsem naznačil, vypisují data a pokládají dotazy, pouze v případě, že je vykreslíš.

Use-case

• přijdu na stránku
  • presenter přijme request
    • v action se nic neděje
    • v render se nic neděje
    • vykresluje se šablona
      • lazy zavolání komponenty1 → dotaz na databázi
      • lazy zavolání komponenty2 → dotaz na databázi
      • lazy zavolání komponenty3 → dotaz na databázi
      • lazy zavolání komponenty4 → dotaz na databázi
  • presenter vrátí odpověď
• pošlu ajax request
  • presenter příjme request
    • v action se nic neděje
    • identifikuje se signál, a presenter ho zkusí zpracovat
      • lazy se vytvoří komponenta, příjme signál
        • překonfiguruje se
        • změní svůj stav
        • naplní šablonu… ⇒ jeden doraz do databáze
        • zde je možnost odeslat výsledek pomocí sendResponse
    • v render se nic nedělej (možno přeskočit)
    • vykreslí se šablona (možno přeskočit)
      • zpracují se pouze požadované snippety (1 signál => 1 komponenta)
  • presenter vrátí ajaxovou odpoveď

Kde se ti co volá znovu?

@**Patrik Votoček**: Vzhledem k tomu, že je to v kategorii feature requests, tak bych předpokládal, že chce, aby to udělal někdo jiný, za něj :)

Pak ti vyletí výjimka v půlce renderování stránky a…

@Patrik Votoček: nebrání mi k tomu asi nic, nejsem v tomhle přeupravování/přetěžování zběhlý. Díky za tip.

@HosipLan: dal jsem to do této kategorie proto, protože si myslím, že by to framework mohl podporovat a ne abych všude psal podmínky (vzápětí budu komentovat tvůj use case), ne proto, že bych v tomhle vláknu čekal konkrétní odpověď na můj problém. A neznamená, že když tu nemám nálepku „Nette guru“, že si neumím nic udělat.

Mně se zdá, že jsi nějaký komponentovaný, nebudu každý výpis (chápej jeden dotaz s podporou AJAXu) psát jako novou komponentu. Komponenta se hodí tehdy, pokud ji budu používat na více místech nebo zaobaluje nějakou komplexní činnost – například košík v internetovém obchodě. Taky určitě nemáš samostatnou komponentu na přidávání zboží do košíku (to je totiž taky docela hloupost).

V tom tvém use casu si přeskakuješ ty fáze jak chceš.

v action se nic neděje
v render se nic neděje

To se právě děje, kdyby se nedělo nic, tak není žádný problém. Tím jsi napsal, že vlastně nevíš o co mi jde, se mi zdá…

Přinejmenším mám v render nastavování dat do šablony (a ne, nechci data načítat z databáze až tam).

Jinak mi chceš naznačit, že ve tvých presenterech jsou jen prázdné hlavičky

actionDetail() {}

renderDetail() {}

když se tam tedy „nic neděje“?

EDIT: nahraju někam příklad, ať je to úplně totálně jasné každému

Editoval joe (29. 6. 2011 17:10)

@**Foowie**: Tohle se už řešilo. Nechce se mi hledat téma. Ale minimálně moje řešení je lepší než obyčejný callback, jehož volání v šabloně se mi vůbec nelíbí. https://gist.github.com/670938

@**joe**: Pokud chceš něco změnit, sepiš RFC. Tzn předlož problém, ukázku use-case, řešení a ukázku použití řešení.

edit:
Nevidím problém v konfigurovatelné komponentě, která mi vypisuje zboží a umí ho přidávat do košíku :)

Není úplně v pořádku, si komponenty představovat jenom jako vymazlené třídy, nebo celé balíky, které si stáhneš na addons.nette.org. Komponenta je cokoliv, co jde připojit do presenteru.

Editoval HosipLan (30. 6. 2011 8:35)

@**22**: „Celej životní cyklus“ zní strašně depresivně, jako by se to mělo narodit a umřít (což se technicky vzato i děje) :) Toho se nezbavíš, je to daň za flexibilitu MVC, ale vždycky si to můžeš přizpůsobit konkrétnímu případu, aby se nevykonávaly věci zbytečně.

@**joe**: ještě jedna věc, actionDefault a renderDefault psát nemusíš, pokud by byly prázdné :)

Editoval HosipLan (30. 6. 2011 13:10)

joe napsal(a):

„Pouhým zAJAXováním“ bych musel zasahovat do ostatních funkcí, dle mě zbytečně.

Jsou tři možnosti, jak se tomu vyhnout:

1. AJAXem volat specializovaná view, která dělají a zobrazují jen to, co je potřeba.
2. využívat v metodách render lazy-loading, tj. třeba $this->template->albums = $this->albums->order('artist')->order('title'); z CD-collection + konfigurovat komponenty v createComponent metodách
3. vůbec data do šablon nevkládat, vytvořit k tomu v presenteru funkce a nechat šablony, ať si je sami získávají přes $presenter->getAlbums().

AJAXem volat specializovaná view, která dělají a zobrazují jen to, co je potřeba.

To by znamenalo mít jinou adresu pro non-AJAX a AJAX požadavek…

public function actionDefault()
{
	if ($this->isAjax()) {
		$this->setView('ajaxDefault');
	}
}

public function renderDefault() { }
public function renderAjaxDefault() {}

Adresa se ti nezmění :)

konfigurovat komponenty v createComponent metodách

To právě ne vždycky jde, například pokud bych chtěl používat tu komponentu pro anketu a anketní otázku bych mohl vybírat právě v action/render fázi podle ID parametru v URL.

protected function createComponentPoll()
{
	// nebo si to můžeš v action uložit do privátní $this->pollId
	return new PollControl($this->context->pollsModel, $this->getParam('pollId'));
}

vůbec data do šablon nevkládat, vytvořit k tomu v presenteru funkce…

… tady je zase „problém“ s případnou chybou a pak se mi nenačte celá stránka.

To není tak úplně pravda, pokud uvažuješ, že jediné dvě věci, co se můžou pokazit, jsou,

• že v databázi ještě nemáš žádná data (například nikdo nevložil komentář),
• nebo se snažíš získat záznam, který neexistuje

Pak při použití dibi (a myslím že i Nette\Database) musíš mít ošetřeny syntaktické chyby v SQL, takže parse error ti nevznikne a musíš mít ošetřeny stavy, kdy záznam nenajde (prázdné/neexistující) nemůže se ti v šabloně nikdy stát chyba.

class ArticlePresenter extends BasePresenter
{
	// ...

	public function getComments()
	{
		try {
			return $this->context->commentsModel->findByArticle($this->articleId);
		} catch (ModelException $e) {
			Debugger::log($e); // zalogovat
			return array();
		}
	}

jenom v rychlosti, bez podmínek…

...
{foreach $comments = $presenter->comments as $comment}
	<div class="comment">{$comment->text}<br>Author: {$comment->authorName}</div>
{/foreach}

{if !$comments}Ještě nikdo nic nenapsal, buďte první!{/if}
...

Editoval HosipLan (2. 7. 2011 12:44)

To je nesmysl, přece nebudu zbytečně uvádět v URL parametr, když ani nevím dopředu jaký má být. Musel bych přesměrovávat → zbytečné a pokud bych ho tam nedával, musel bych se dotazovat db → taky zbytečné.

Co je na tom za nesmysl? Sám si uvedl, že se rozhoduješ podle parametru ID v URL a že prý to jde dělat jen v render/action fázi. HosipLan ti tu ale správně napsal, že to není pravda a že k parametru se můžeš dostat i v továrničce. Nechápu jaké „nevím dopředu jaký má být“, „musel bych přesměrovávat“ – to je nesmysl.

@redhead:
Nesmysl proto, protože v URL mám například ID topicu a ne konkrétní ID anktety, proto ho nemůžu volat $this->getParam('pollId');

@HosipLan:
O Presenterech toho možná nevím co ty, ale vím, že bych to mohl udělat jak jsi poslal teď (nikoli předtím, k čemu jsem se vyjadřoval). Takže otázky „Kde se ti co přesměrovává? Kde máš co v url?“ jsou tady celkem opožděné :)

Ano, je fajn vědět, že Presenter je třída jako každá jiná :)

Uložit si to do různých atributů třídy samozřejmě můžu, ale proč bych to dělal? Jen kvůli tomu, aby se to zpracovalo později? To mi nedává moc smysl… Pořád mi to přijde jako vyhýbání se nějakému komplexnímu řešení, které by mi přišlo přehlednější.

Při prvním kouknutí do kódu by ti bylo hned jasné, proč to je přes atribut třídy a není to nastaveno hned v té action/render té komponentě?

$this['pollControl']-> ... ;