Closed zabak closed 8 years ago
Tohle je chyba API - uz dlouho. Neni tam cislo, ale pole s cislem. Deje se to v pripadech, kde je nazev ohranicen hranatyma zavorkama. Hranate zavorky nesouvisi s typem stran, ale v knihovnickem svete to znamena: Tento udaj nelze jiste potvrdit - vychazi to ze starych metodik katalogizace, kdy se vyznam (take interpunkce, oddelovace a dalsi znaky ktere davaly (polo)strukturovanym datum formu) cpal pres znaky do obsahu.
Tohle je spatne reseni, ale data v modernejsich formatech jsou generovana z tech starych (navic nove formaty stale maji dost spatnych navyku). Takze se budes setkavat s nazvy, ktere zacinaji a konci (nebo jen zacinaji) hranatou zavorkou. Na jmeno autora koncici carkou (nebo jinym intrpunkcim znamenkem, v zavislosti na dalsich udajich o autorovi) a dalsim balasten, ktery ve strukturovanem datovem formatu nema co delat.
Nektere veci (jako prave ty zavorky u cisel stranek) jsem ve webovem klientovi urezel, protoze tohle uzivatele nezajima a vypada to blbe.
Kazdopadne .... chyba je na strane API pri generovni JSONu. Spravne to ma byt vzdy string. Klient ale nesmi spadnout, i kdyz je chyba na strane serveru/API - v tomto pripade obsah title, pageNumber apod. ber vzdy jako string, pokud to string neni, tak obsah pretypuj, at je to string reprezentace objektu: 1 -> "1" "1" -> "1" [1] -> "[1]"
A taky je asi bezpecnejsi brat cislo (nazev) stranky z title a ne details.pageNumber v pripade requestu na children. Tam je tento problem taky a dokonce casteji, napr. http://kramerius.mzk.cz/search/api/v5.0/item/uuid:659318fc-03cb-40ac-b7b8-319909211fb2/children Tady je pageNumber vzdy string a title je strng i pole. Ale ma vetsi nadeji na opravu a zatim to proste resit tak, ze obsah beres jao string, at je tam cokoli.
Jinak tusim, ze @MartinRumanek rikal neco o tom, ze to opravil, ale ze to muze pokazit fungovani prave iOS klienta a domluvili jsem se, ze se to i presto opravi.
@honza-rychtar My jsme se o tomhle s @MartinRumanek bavili, ze stejny balast chodil i v Title. Osetrim chovani aplikace, aby byla pripravena i na tyhle nekonzistentni data...
Vsechno je to popsano v issue, ktere zminuje Hona Rychtar, ale jeste se k tomu vyjadrim.
Ano, toto se uz resi hrozne dlouho, bylo to nahlasene v tomto issue https://github.com/ceskaexpedice/kramerius/issues/211
Tato zmena neni pritomna v aktualnim releasu, pouze v upstreamu (=aktualnich zdrojacich). Chtel jsem to nasadit, ale zjistili jsme, ze tou opravou pravdepodobne rozbili Remote API, viz issue https://github.com/ceskaexpedice/kramerius/issues/324 (ktere je pro nas taky dulezite). Proto jsme to nasazeni odlozili.
Opraveno, je pripraveno k testovani v nejnovejsim buildu.
Aplikace spadne, kdyz dostane od serveru zmatenou (nebo pro me zmatenou) response, vcera jsem nasel zrovna tento request http://kramerius.mzk.cz/search/api/v5.0/item/uuid:b74f33ce-9dfe-11e0-a742-0050569d679d/children V responsi jsou: details.pagenumber kdy nekdy podle druhu stranky jsou jina data v pagenumber - jednou je to string a po druhe zase cislo... Mohl by nekdo objasnit, co je spravne? Jestli mam podle details.type rozlisovat, jestli ma dana stranka cislo nebo retezec? Nebo zda to nema byt nejak jednotne? Diky za odpoved.