Načítání Facebook postů v Nette Framework
Last updated
Was this helpful?
Last updated
Was this helpful?
Na jednom projektu jsem narazil na potřebu zobrazovat posty z Facebooku na klientově stránce. Inu začal jsem psát prototyp jak bych danou věc řešil. Prototyp jsem "spíchnul" za hodinku, ale bylo to uděláno tak trošku na hulváta. Tak jsem si řekl že to postupně přepíšu tak jak by to třeba napsal nějaký zkušený programátor s Nette frameworkem. Na jsem danou věc přednesl a Nette guruové mi přislíbili odbornější konzultace.
Článek není psán jako how-to (na takovém článku zapracuji) Je psán jak jsem postupoval, co jsem napsal, následně zavrhul nebo přepsal. Proto se nedivte, že tu třeba pracuji s Nette Cache, kterou v zápětí odstraním. Při čtení je dobré koukat na konkrétní a článek brát jako "přemýšlení nahlas" k těmto commitům.
Výsledkem je aplikace co naimportuje posty z dané Facebook zdi do databáze, v administraci si pak zvolíte, které posty chcete na své stránce zobrazit.
Techniky co se používají: Nette\Caching, Facebook SDK, Kdyby\Facebook, Nette\Database, Custom Latte Macro, Snippets.
Celý projekt je k naleznutí na Githubu
Začneme čistým projektem vycházející z Nette/Sandbox
composer create-project nette/sandbox Nette-Facebook-Reader
cd Nette-Facebook-Reader
zápis do "log" a "temp" folderu
chmod -R a+rw temp log
commit:
vyčistíme homepage šablonu a připravíme si nový Import Presenter se šablonou.
/app/templates/Import/default.latte
a /app/presenters/ImportPresenter.php
Přidáme si do composer.json závislost na Facebook SDK
a stahneme si ho pomoci composer update
.
[ /data/articles/1/facebook-developer.png .(Facebook Developer) ]
Stačí nám vyplnit pouze její název
[ /data/articles/1/create-new-app.png .(Create new App) ]
a zjistíme si Facebook App ID a App Secret
[ /data/articles/1/facebook-app-ids.png .(Facebook App IDs) ]
Na hulváta si zkusíme načíst data skrze Facebook Graph Api. V našem Import Presenteru přidáme do hlavičky
a metodu přepíšeme podle ukázky z dokumentace k PHP Facebook SDK
po zkouknutí výstupu bychom měli vidět dump pole o 25 položkách
[ /data/articles/1/dump-array-25.png .(dump array) ]
Malinko si zjednodušíme ošetření chyb jen na ukončení aplikace.
Přidáme si možnost cache pro požadavek. (Hlavně si tím urychlíme další rozšiřování, přeci jen čekat 10 sec na každý refresh mě nebaví).
O cachovaní se nám postara Nette Framework a jeho Nette\Caching\Cache;
Přidáme do use sekce
A ten si necháme poslat (injectnout) do třídy pomoci Nette Dependenci Injection. Jediné co musíme udělat je definovat public property $cacheStorage typu \Nette\Caching\IStorage a pomocí anotace @inject nám framework zařídí vše potřebné.
hup, a v našich metodách se ke storage dostaneme snadno pomocí $this->cacheStorage
V našem případě pokud se nám nepodaří načíst data z cache (a to se nám napoprvé určitě nepovede) tak si je načteme z Facebooku a do té cache si je uložíme:
Výsledkem je
Nyní by nám druhý request měl trvat výrazně kratší dobu.
[ /data/articles/1/with-cache.png .(with cache) ]
Dalším krokem je uložit si získána data do databáze. Pro práci s databází použijeme třídu Nette\Database. Vytvoříme si databázi a uživatele (díky klonování Nette Sandbox máme výborný nástroj Adminer přímo u projektu /adminer/).
Uživatel bude facebookwall a s heslem 'tajneheslo' bude mít přístup ke všem databázím začínající facebookwall_ v našem vývojovém případě konkrétně k databázi facebookwall_devel
a vytvoříme si tabulku kam si posty budeme ukládat.
V presenteru si řekneme ať nám framework předá objekt Nette\Database\Context
v konfiguračním souboru /app/config/config.local.neon si doplňíme připojení k databázi.
Pozor na zápis, liší se od Dibi a občas mě to dokáže zabrzdit ;-)
V presenteru si pak na hulváta doplníme ukládání jednotlivých řádku, připadne po opakovaném importu aktualizaci postit
můžeme se přesvědčit, že se nám vše uložilo
[ /data/articles/1/save-to-database.png .(save posts to database) ]
Předáme si výpis práve přidaných postů do šablony a tam si je vypíšeme.
a
V HomepagePresenteru si načteme posty co jsme načetly importem. Jelikož, ale nechcem zobrazovat všechny posty nastavíme si u některých v databázi status na 1 a budem zobrazovat pouze tyto.
a nesmíme zapomenout na přidání public property $database;
šablona pak může vypadat nějak takto:
Pokud se nad úkolem zamyslíme tak je to taková věc co by se nám mohla hodit i na jiném projektu. Připravíme si tedy modelovou vrstvu. Do ktere přepíšeme náš prototyp.
Všiměte si jak si v konstruktoru řekneme o Nette\Database\Context
app/model/FacebookWallpost.php
a v presenteru přepíšeme vypisování postů na
Property $database jsme nahradili za $wallpost a změnili typ třídy co chceme po frameworku aby nám předal. Aby to celé fungovalo musíme ješte danou servisu zaregitrovat v config.neon
To samé uděláme i s částí pro načítání dat z Facebooku.
Při přesunu odstraním používání cache, jelikož už jí při vývoji nepotřebuji ba naopak pokud chci zadat import tak chci aby se provedl vždy.
z Import presenteru přemístíme use sekci do modelu a presenter se nám rázem zjednodušil na
Jako pěkný, ale. Ale nám se ještě nelíbí
hesla chceme v konfiguraci a zde si jen řekneme o funkční session. Nahradíme tedy za
a do konstruktoru přidáme předání závislosti. plus nezapomene na deklarovaní property.
a našeho "hloupoučkého" managera definujeme v /app/model/FacebookSessionManager.php
registrujeme ho v config.neon
a v config.local.neon přidáme sekci s kódem a heslem k aplikaci
mnohem čitelnější.
teď ale příjde ta zajímavější část.
a aktualizujeme composer pomocí composer update
. Smažeme náš "hloupoučký" FacebookSessionManager.php a odebereme i jeho registraci do services v config.neon, zde naopak přidáme sekci extensions a do ní registrujeme Kdyby Facebook
Tato extension vyžaduje v configu Facebook App ID a Facebook Secret. Proto do lokálního config.local.neon přemístíme tyto informace ze sekce params (kam jsme si je uložili) do sekce facebook.
(APP_ID dejte do uvozovek, jinak je brán jako integer a Kdyby/Facebook vyhodí excaption.)
A ve FacebookWallpost.php uděláme pár změn. Prvně si upravíme use sekci. Odebereme Facebook SDK a nahradíme ho za Kdyby\Facebook a přidáme Tracy\Debugger.
Pak nahradíme inicializaci session managera za Kdyby\Facebook
a zjednoduší se nám i volání samotného požadavku. Plus si budeme logovat případnou chybu.
Q: Proč
return array();
namísto$this->terminate();
A: ???
Teď, když si znovu spustíme import, tak bychom měli v Tracy vidět novou ikonku Facebooku a u ní základní informace o volání jeho API. Krása.
[ /data/articles/1/kdyby-facebook-tracy.png .(Kdyby Facebook - Tracy extension) ]
Další vychytávkou co Kdyby\Facebook má je metoda iterate. Pokud jste si všimli tak volání Facebook API vrací cca 25 záznamů a adresu pro další (paging) toho tato metoda využívá umožnuje nad výsledkem iterovat třeba ve foreach a donačíst tak úplně všechny posty.
Nahradíme tedy volání api za iterate. Zde už dostáváme čisté "pole" všech postů tak poupravíme i samotné procházení výsledků.
Když teď, zkusíme import, v Tracy panelu uvidíme že se Facebook Api volalo vícekrát a v panelu je vidět detail každého volání.
a pak ve foreach
Filip do kódu přidal i ukázku jak se poprat s if peklem v šablonách pomocí Latte filtru.
filter se jmenuje fbPostLink
pokud daný post má definovaný link vrací tento link
pokud se podaří z post id (které obsahuje {pageId}_{postId} ) získat postId vrátí link na konkrétní post na facebooku
voláme ho nad objektem $post
šablona se nám pak zjednoduší na
Jako poslední úkol jsem si nechal administraci na povolování postů. Vytvoříme si nový presenter AdminPresenter a u vypsaných jednotlivých položek přidáme tlačítko enable, disable. To celé pak z "AJAXujem".
Začneme úpravou modelu, kam si přidáme metodu co nám vrátí všechny posty.
a následně si je načteme presenterem AdminPresenter a pošleme do šablony
šablonu je možno vidět v commitu.
Následuje vytvoření v modelu metod co se nám postarají o samotnou editaci postu.
a v presenteru si vytvořím dvě akce co funkcionalitu budou obsluhovat
v šabloně si upravím odkazy ať fungují
a fungujeme.
to samé uděláme i pro druhou metoru actionDisablePost. Upravíme si šablonu tak že budem zobrazovat obě tlačítka a jen skrze css budem schovávat to, které zrovna nebudem potřebovat.
a pak celé to rozhejbání v JavaScriptu. Pokud kliknem na odkaz co má třídu .ajax tak stopnem klasické volání, a zavoláme XHR požadavek. Pokud se nám vrátí message, že je post disablován, tak prohodíme zobrazení tlačítek. (v opačném případě také) Plus pár visuálních drobností (disablování butonu po kliknutí, změna kurzoru na hodinky)
Porovnávat message co se stalo není moc "profi", tak si zavedem nějakou proměnou s akcí a status zdali se provedla správně. To s použitím payload proměnné je vcelku snadné
v JavaScriptu se pak zeptáme co se dělo a jak to dopadlo a zobrazíme dynamicky flash zprávu.
Další radou od zkušených bylo použití signálů (handle).
Handle je na změnu stavu aktuálního view. Tj na smazání, zaktivnění položky etc. (Většinou totiž po provedení chceš znova vykreslit tu samou stránku).
Patrik Votoček
nebo
Handle je „subsignál“ aktuální akce, je to jako když odešleš formulář. Když máš akci, tak většinou by měla něco zobrazovat, nebo připravovat data pro formulář. Zpracování formuláře taky nedáváme do akce, ale napíšeme na to metodu, kterou dáš formuláři jako callback. Tak přesně to je signál, zpracování nějaké operace (třeba smazání řádků, nebo označení řádku jako hidden) pro aktuální akci (což je třeba výpis jednotlivých řádků).
Filip Procházka
Přepracování bylo snadné. Přejmenoval jsem metody z actionDisablePost na handleEnablePost a volání z
na vykřičníkový signál
TIP: piš méně
pri odkazovani na akci ve stejnem presenteru staci uvest nazev akce, nemusis jiz uvadet presenter
Matej21
druhým bude tabulka wallpostů
v tuto chvíli se stali tzv. controllem který v případě, že víme že se změnil tak ho necháme překreslit redrawControl. V našem případě pokud chceme změnit status postu tak necháme překreslit snippet flashes a wallposts
jediné co potřebujeme je zavolat její inicializaci.
pěkné zjednodušení, že? Kabelama se nám přenáší jen co se "opravdu" změnilo
[ /data/articles/1/snippets-response.png .(json snippets response) ]
Zpracování formulářu v Nette funguje na bázi signálu (handle) a tam abychom se vyhnuli problému s refreshem použijeme redirect(). Stejně je tomu i v našem případě se signály na disablování a enablování postu. Pokud se nejedná o ajaxový požadavek, tak přesměrujem.
každý řádek zabalíme do jednoznačne identifikovatelného snippetu (použijeme n makro)
a přidáme trochu logiky do handle. V případě že se jedná o ajaxový požadavek, načteme jen aktuálně zpracovávaný řádek a do šablony ho pošleme jako "seznam všech postů", v normálním požadavku pošleme do šablony posty všechny.
[ /data/articles/1/dynamic-snippets.png .(json dynamic snippets response) ]
Metody handleEnablePost a handleDisablePost($postId) mají dost kódu úplně stejného. Proto mě napadlo že bych je nějak předělal.
První nápad byl mít metodu handleChangePostStatus($postId, $actionType), kde by jako druhý parametr byl typ akce, disable nebo enable. Dva parametry se mi nakonec nelíbily.
TIP: rezervovaná slova
zde jsem původně měl parametr pojmenová pouze $action a ouhle nějak to nefungovalo. Narazil jsem na pojem rezervovaných proměnných. Tak bacha na ně ;-) Proto i submit button ve formuláři by neměl mít jméno action. Další slova jsou: $do, $_fid, (TODO) .. a $action
Druhým nápadem bylo mít metodu handleTogglePostStatus($postId), která by si zjistila zda je článek povolen a zakázala by ho nebo opačně. Zjistil jsem, že by status ani zjištovat nemusela jen by SQL update otočil hodnotu (nezkoušel jsem). Toto řešení jsem zavrhl kvůli zobrazení ve dvou oknech současně. Chování by mohlo být nelogické.
Třetím nápadem bylo vytáhnout společnou logiku do vlastní metody a u něj jsem zůstal.
Dobré je mít v repozitáři šablonu pro config.local.neon
Chtěl jsem oku lahodící výpis postů na homepage
A pomocí CSS animované zmizení flash message
Tím končí tento delší rozbor jak jsem připravoval aplikaci na zobrazování postů z Facebooku.
commit:
commit:
Přihlásime se na Facebook Developers a vytvoříme novou aplikaci.
commit:
commit:
commit:
Abychom mohli vytvořit instanci třídy Cache tak jí musíme předat nějaký cache storage kam si bude ukládat data. Viz API dokumentace
Více o cache si nastudujete v dokumentaci .
commit:
commit:
commit:
commit:
tuto verzi najdete pod tagem
commit:
commit:
commit:
tuto verzi najdete pod tagem
Jako první poslal pull request .
commit: odebírá zbytečné kontrolování složky kterou nepoužíváme
commit: Upravuje jak se zapisuje přihlašování k databázi. Nyní jsou parametry (jméno, heslo, server, databáze) vytáhnuté do sekce "parameters". Proto si ze souboru config.local.neon odeberte sekci nette - database a nahraďte ji
commit: přidává zmíněný SQL table creator do kódu
Jako první nahradíme v composer.json Facebook/SDK za
Filip pak přepsal mé ifové peklíčko do mnohem čitelnější podoby pomocí . Nahradil datum ve stringu za DateTime obalené v a vrácený záznam je přetypován na (nezapomenout definovat v use)
V HomepagePresernter definujeme metodu , která vrací presenteru template object, který se použije pro render šablon. K této šabloňe přidáme filtr, který se bude starat o odkazy na posty.
commit:
tuto verzi najdete pod tagem
Na doporučení Davida jsem odebral z projektového .gitignore soubory Sublime editoru a PHPStormu a zapsal jsem si je do globálního gitignore
Než začnem s php úpravama, provedem pár drobných změn na frontendu ať se na náš výtvor dá aspoň trošku koukat. Osobně mám rád , ale tu samou práci, pro tento případ i možná vhodnější, odvede
commit:
commit:
commit:
commit:
není to žádná hitparáda, ale funguje, a to se počítá ;-) Začnem úpravou presenteru. Ten pokud se bude jednat o ajaxový požadavek, tak na místo flashMessage nastavíme do proměnné payload message co se stalo, a následně pošleme uživateli tento payload. Metoda sendPayload je ulehčení ať se nemusíme starat o posílání JSON Response, vše je čitélne z obsahu
commit:
commit:
commit:
Teď přichází pořádné kladivo. Představme si že nechceme ručně ošetřovat ajaxové volání. Prostě ať se udělá co se udělat má a změní se jen potřebné. K tomu slouží . Snippet chápu jako pojmenovaný prvek na stránce, který v případě potřeby je možné nahradit za jeho aktuální verzi. V našem případě si pro začátek označíme dva snippety. Prvním bude blok kódu co se nám stará o výpis flash messsages
kód se nám dosti zjednodušil. Ještě dáme pryč celý náš JavaScript mechanismus co se staral o zpracování požadavku a použijeme knihovnu , která umí pracovat automaticky právě se snippety a s jejich přenosovým "JSON protokolem"
commit:
commit:
Ajaxové požadavky sviští o 106 jen se nám v každém requestu ajaxem posílá celá tabulka postů. Ale my změnili jen jeden, co kdyby se tedy posílal jen tenhle jeden spolu s flash message? Lze. Technika se nazývá
jelikož se handle zpracovává dříve než render viz , tak pokud uživatel bez JavaScriptu změnil viditelnost postu, tak už do šablony poslal seznam všech postů a render už tuto věc dělat nemusí, tak si to ošetříme.
commit:
commit:
commit:
commit:
commit:
commit:
tuto verzi najdete pod tagem