Marek Olšavský: blog

StAX, neboli Streaming API for XML, nenahrazuje na Java platformě SAX, ani DOM, má trochu z obojího a je příjemně jednoduchý. Pro většinu práce, kterou s XML potřebuji udělat je dostatečný, vůči SAXu má výhodu, že umí data zapisovat do souboru (nebo jsem dokumentaci SAXu špatně četl), proti DOMu je podstatně méně komplexní a nedokážete se StAXem dělat operace, jako při použití DOMu.

Pro svého partnera, se kterým spolupracuji na e-shopu www.babyprofi.cz potřebuji program pro zpracování dat. Shop jede, alespoň zatím, na platformě ZenCart a pokud bude slíbený pokrok ZenCart 2 tak výrazný, jak je slibováno, zůstane i nadále na tomto řešení, pokud ne, vlastní řešení eShopu již mám napsané. Ceníky od výrobců dostáváme ve formátu MS Excelu, používáme ekonomický systém Pohoda od Stormware a pro hromadný import dat mám v ZenCartu rozšíření Easy Populate, které pracuje s CSV soubory.

Zatím máme veškeré podklady v Excelovské tabulce, ze které si snadno udělám CSV, které zpracuji do správné podoby pro import pomocí Easy Populate i pro můj engine. Bohužel občas z toho vyplývají nemalé problémy, protože nikdy nevíte, kdo má poslední verzi tabulky. Proto jsem se rozhodl veškerá data přemístit na můj domácí testovací server, do PostgreSQL databáze a zároveň vyřešit klientskou aplikaci, která umožní prohlížení i editaci dat (popisy, kategorie), nastavení cenových hladin pro jednotlivé dodavatele, synchronizaci ceníků s ekonomickým systémem Pohoda a generování importních souborů pro e-shopové enginy.

Volba platformy pro klienta padla na Javu, protože já používám na nefiremních PC téměř výhradně GNU/Linux, ale kolega je uživatel MS Windows XP. Platforma NET připadala také v úvahu, ale nejsem si zcela jist rozumnou měrou kompatibility mezi .NETem a Monem. Najít Javovské knihovny pro práci se soubory ve formátu Excelu i Accessu (v Accessu ukládá data Pohoda) byla otázka chvíle (snad o nich ještě napíšu), spolupráce s PostgreSQL je vcelku triviální záležitost a teď jde jen o patřičné napsání požadované funkcionality.

Hned první problém, který jsem potřeboval vyřešit, bylo ukládání konfigurace, ideálně do triviálního textového souboru, který budu v případě potřeby umět upravit ručně. Sice vzpomínám na ini soubory, které se daly triviálně používat v Delphi, respektive na platformě MS Windows, a vím, že by se daly využít i pro Java platformu (viz.: ini4j), ale XML mi přišlo jako podstatně čistší a logičtější řešení. Problém tedy nastal v tom, jak číst a zapisovat XML soubor.

SAX, neboli „Simple API for XML“ (užasné, v akronymu jsou další akronymy) je jednoduchý přístup pro čtení XML, podpora SAXu je v knihovnách, nikoliv nutně ve standardních, snad všech v současnosti používaných jazyků, zcela samozřejmě i na platformách .NET a Java, které pro svou práci využívám. SAX lze popsat jako malého souputníka DOMu, protože v řadě případů není nutné mít v paměti celou objektovou strukturu XML, ale postačí pouze data načítat v proudu, pochopitelně, že SAX je velmi triviální na používání v programovacích jazycích a snadnost implementace StAXu je naprosto srovnatelná (řekl bych že dokonce totožná).

SAX je použitelný, pokud chcete data číst ze souboru, nebo přes nějaký request, prostě pokud máte zdroj již hotového XML. Pokud jej potřebujete vytvořit, je SAX mimo hru. Pokud potřebujete XML vytvořit a uložit, je nejhorší metodou pouhé zapisování řetězců (snadno byste spáchali nevalidní XML), zde nastupuje DOM, neboli Document Object Model, či StAX.

DOM je velmi komplexní řešení a opravdu fantasticky fungující, jen dost náročné na paměť. V DOMu se můžete po XML pohybovat všemy směry, můžete měnit data libovolných uzlů a pak vše uložit do souboru, nebo odeslal po síti klientovi. Díky velké komplexnosti a rozsáhlé funkčnosti má DOM však velmi velké paměťové nároky, v učebnici Pavla Herouta „Java a XML“ jsem viděl údaj, že pro zpracování 100 MB velkého XML je potřeba 1 GB volné paměti (je jedno zda systémové, nebo virtuální).

Pokud ale není potřeba vytvářet složité XML, upravovat/mazat data v již existujícím XML a pro čtení stačí běžný proud dat, jako u SAXu, je možné použít mnohem jednodnušší StAX, než JDOM. StAX byl v Javě 5 ještě mimo platformu Java a bylo nutné si přidat potřebné knihovny k projektu (v mém oblíbeném IDE jde o otázku několika kliknutí a NetBeans se postarají o zbytek), Java 6 už nese StAX s sebou, jen se musíte smířit s tím, že uživatelé JRE 5 aplikaci nespustí. Pokud chcete mít knihovny pod svobodnou licencí můžete využít projekt Woodstox, který má stejnou funkčnost, jako implementace StAXu od SUN Microsystems (původní, referenční StAX je dílem Codehaus), já upřednostňuji řešení přímo implementované v JVM.

StAX vidím jako velmi vhodný přístup ke XML na Java platformě, pokud mi postačují pouze základní operace s XML souborem. Zvládá sekvenční čtení i sekvenční zápis, což je vše co většinou v programech potřebuji, jelikož XML používám jen pro uložení konfigurace/nastavení parametrů programu, pro komunikaci s portálem veřejné správy (odesílání ELDP a ONZ).

Jak využívat StAX nebudu na tomto blogu popisovat, odkáži na „An Introduction to StAX„, jenž vyšel na webu XML.com, případně na již zmíněnou učebnici Pavla Herouta.

Protože se postupně vracím k psaní i na Java platformě a za 5 let od odchodu z Unicornu jsem leccos zapoměl, budou se občas na tomto blogu objevovat i nějaké moje poznámky o problémech které jsem řešil a jaké řešení jsem nalezl, ale neslibuji, že tu budu přesně rozepisovat jak se co implementuje, na to mají knihovny/projekty dokumentaci.

Tento článeček by snad mohl nasměrovat alespoň jednoho programátora ke snadnější práci s XML, pokud jej nepotřebuje moc složitě zpracovávat.

Tak toto byl takový oddechovější článek a příští týden snad zase potkám nějaké rozumnější a vážnější téma.