Open killua-eu opened 6 years ago
Q: co se tyce adres, chces aby to vybiralo okruh, ze stranek ketre sledujeme? nebo ze vsech co existujou, ktere nesledujeme? ANO Q: Ty okruhy adres, to chces taky ukladat jako trvale stahovani? ANO. To zadání adresy je tam nejen na stránky, ale i na events které budou na stránce pražské firmy která udělá na brněnské adrese event. Otázkou je, zda to dokážeme vytáhnout. Q: Můžeš napsat víc k bodu 1 editace? Při editaci bys měl vidět odkdy (dokdy) sleduješ,.. Pokud přerušíš tak být to měl vidět jako víc datových rozsahu. Měl bys mít možnost si zadat rozptyl od do co stáhnout, abys mohla stáhnout i minule eventy
Mělo by jít pripadne moct upravit popis eventu, také potrebujeme, aby s kazdou aktualizaci se u dat zobrazovalo co se zmenilo aby si to uživatel-editor mohl projit a rozhodnout co s tím. Některá data bude mozne autoaktualizovat bez editora, ale jeste nevime jak to ted zakomponovat do UI, takze to nechame na pozdeji. Půjde napr. o to, ze pokud nekdo nastavi/zmeni na eventu link na prodej vstupenek, pak by se mel automaticky prenastavit i glued zaznam).
Q: ty zmeny to bude komplikovane. protoze treba od vcerejsi aktualizace se nic nezmenilo, ale od predvcerejsi jo. a kdyz se neco zmeni mezi 4 a 5 a mezi 7 a 8 a ty jsi na 9, tak ktere vsechny zmeny chces videt? A: rozhodne datum je datum kdy eventu uzivatel priradi tag. ten tag urci, ze s tim eventem budeme dale pracovat takze to nam da prvni okamzik.
K situaci popisovane v otazce: rekneme, ze data mame z okamziku 4 ptvrzena editorem jako platna. mezitim se ulozilo 5,6,7,8,9. automaticky nabidneme editorovi 9 u vsech datovych polich. ale bylo by fajn, kdybychom meli treba postahovany 3 ruzny obrazky, ejden z verze dokumentu 4, jeden z 6 a jeden z 9, tak se nabidne sice 9ka, ale bude mozne u toho obrazku napr. klikanim na jedno tlaciko prorotovavat vsechny stazene obrazky ( tak vybrat ten, ktery se ma zobrazovat ). ty zmeny/verze bychom ted meli pripravit na backendu (tedy stahujme ta data). jak s nimi pracovat na frontendu bychom meli vybrat podle toho, jak eventy opravdu zobrazime v html, at prilist netrapime nasi predstavivost. prvni proof-of-concept pro predstavu jak bychom to treba na frontendu mohli udelat je mit u kazdeho eventu:
Se stazenymi daty budeme cilit na 3 cilove pouziti:
a] rezim agregace haldy fb eventu na web b] rezim history tracking eventu nejakych stranek c] rezim parovani s ukoly naplanovanymi v nasem pixel modulu
a] budem tam muset jeste asi jeste doplnit k eventu tlacitko publish s vyberem kam se ma publikovat. publikaci je mysleno to, ze se fb data zkopiruji do nasi datove struktury v pixel json dokumentu. nasledne pak pixel eventy s nastavenou vlakou published a id/kanalem ve kterem se ma publikovat ... pod nejakou api adresou, napr. glued.com/api/pixel/events/list/channel=$channelid&date=upcomming&limit= to pak napriklad vypise nami strukturovany json se vsemi eventy zverejenymi do daneho kanalu. ty json data pak vezme nejaky kousek javascriptu a udela z toho html vystup. takto si bude moct n spolupracujicich organizaci dat spolecny eventkalendar na web b] ditto, jen bude v tom prehledu v parametru date=20170101-20171231 a pridame tam treba prametr &fmt=html a vypise to jednoduchem nestylovanem html data, kter muze uzivatel snadno copy and pastnout do zaverecne zpravy kdyz musi vykazovat aktivitu za rok treba kvuli firemni politice, dotacim, atp. c] prolinkovani eventu s nasimi issues
event-id, event-name, start-time, location a ideálně i pořadatelé.
V tabulce všech eventů i v tabulce eventů stránky umožni zobrazit více informací. minimálně chceme vidět header fotku, počet lidí, popis akce. prima je videt vše (předpokládám, že ukládáš celý json z fb a neomezuješ ho a z něj jen zobrazuješ části, nebo ukladas ta data, co jsme si odsouhlasili pred par mesici) - tedy např. zobrazit prettyprint celého jsonu. pro toto bych zvolil zobrazovaní typu harmonika, napr. na výsku 5, 6 radkku tak, aby to slo rozkliknout na první dobrou.
Dále budeme chtít zvýraznit změny v termínu konání, popisu, názvu eventu a místu, resime tedy verzovani. Staci mit asi jen aktualni verzi proti verzi přijaté editorem.
Dále budem chtít ukládat edge data o tom, kdo byl na jakém eventu (pokud to api dovolí). Takovým způsobem, aby v případě, že se toto FB rozhodne zabít, glued neprepsal posledni platny guest list prazdnou hodnotou.
Workflow užívání by měl být následující:
Z této tabulky se pak budou data zobrazovat přes api. Api endpoint bude vracet json se všemi eventy s nějakým limitem. Zobrazí se pouze anonymizovaná data (tzn. nesmí tam být vidět např. edge data kdo se účastní čeho).
ad 2) pokud neni v dotazu uvedeno limit=cislo bere se limit jako 25. dalsi stranku lze nacist dvema zpusoby: 1. pokud stranku jedna ziskame z response takto: $feedEdge = $response->getGraphEdge(); tak stranku 2 ziskame takto $nextFeed = $fb->next($feedEdge); pokud uz tam zadne dalsi polozky nejsou, vrati to null
jako limit u dalsi stranky se pouzije bud 25, nebo zadany limit u prvni stranky.
2. zjistime si sami z edge hodnotu dalsiho kurzoru $hodnota = $feedEdge->getNextCursor(); pokud to vrati cokoliv mimo null, jsou tam dalsi stranky a muzeme ho pouzit pro konstrukci dotazu pro nacteni dalsi stranky. (nebo muzeme udelat to next(), nebo si to muzeme ulozit pro pozdeji nacteni. ale pak uz nepujde udelat next, jen zkonstruovat novy dotaz)
krome kurzoroveho strankovani existuje jeste time based strankovani a offset based strankovani (zalezi na konstrukci puvodniho dotazu) , ktere ale nejdou pouzit na vsechny edge. tam je mozne se na dalsi stranku dostat jen tim next() z prvniho prikladu.
Integrate fb events into our calendar solution. https://developers.facebook.com/docs/graph-api/reference/page/events/
[edit] On hold due to Cambridge Analytica scandal. See: