Aplikace pro přípravu a tisk štítků

24.4.2014 21:57 | Přečteno: 2505× |

Před nedávnem jsem zprovoznil můj hobby projekt www.123stitky.cz pro on-line přípravu a tisk samolepících štítků. V tomto zápisku se pokusím popsat technologické zázemí této webové aplikace. Doufám, že někoho inspiruje, případně někomu pomůže při výběru technologií pro jeho projekt.

www.123stitky.cz

Tato služba slouží pro přípravu a tisk samolepicích dopisních štítků. Zajímavé je, že tuto problematiku řeší mnoho programů (např. PC Štítky, ale nenašel jsem žádné internetové řešení. Proto jsem vytvořil jednoduchou aplikaci, od které jsem chtěl:

• Rychlé vytvoření štítků (v uvozovkách na tři kliknutí)
• Možnost generování QR a čárových EAN kódů
• Jednoduché Control+C, Control+V z jakékoli desktop aplikace
• Aplikace by si měla pamatovat poslední stav, tak aby znovuotevření v prohlížeči načetlo již (částečně) vyplněnou tabulku s adresami
• Vytvoření PDF se štítky a jeho vytisknutí rovnou z prohlížeče
• Vygenerování podacího archu pro Českou poštu s adresami, které jsou na archu se štítky

Generování štítků

Z mého pohledu byla jasná volba programovacího jazyka na server - Python 2.7. Pro generování štítků jsem pak použil modul reportlab, který dokáže přímo generovat PDF. Kolem toho vznik jednoduchý modul pro převedení vstupního Python dictionary na PDF se štítky.

Pro generování podacícho archu jsem si napsal vlastní řešení. Protože podací arch je nabízen Českou poštou volně ke stažení jako DOC, chtěl jsem jej použít jako vstup. Pro převod ideálně posloužily LibreOffice a to hned dvakrát:

• Konverze DOC na FODT. FODT proto, protože pro generování jsem chtěl mít jako vstupní soubor jediné all-in-one XML namísto ZIP archívu (což je ODT).
• Po vyplnění podacího archu v FODT převod pomocí unoconv do PDF. Unoconv je řádkové rozhraní pro LibreOffice a umožňuje konverzi mezi podporovanými souborovými formáty z příkazové řádky.

Vyplnění podacího archu je možné několika způsoby, buď klasické replace() nad řetězci, případně nad naparsovaným XML stromem. Nicméně já jsem využil šablonovací engine z web2py. Výhodou je automatické escapování symbolů jako & < a >, které se může objevit v datech od uživatele.

Tento šablonovací engine je samostatně použitelný i mimo web2py framework následujícím způsobem:

from gluon.template import render

data = {'jmeno': 'Karel', 'prijmeni': 'Novak'}
tmpl = 'Ahoj, jmenuji se {{=jmeno}} {{=prijmeni}}'
print render(content=tmpl, context=data)
Ahoj, jmenuji se Karel Novak

V tomto okamžiku máme modul, který pomocí Reportlabu vygeneruje štítky (případně včetně QR kódu nebo EAN čárového kódu) a vyplní šablonu FODT, kterou převede unoconvem do PDF. Poslední krůček je pospojování více PDF do jednoho vícestránkového pomocí pdftk.

Webová aplikace

Pro vývoj samotné webové aplikace jsem použil výše zmíněný modul pro generování štítků. Zbývalo "jen" napsat webové GUI. Protože jsem znovu nechtěl vymýšlet kolo, zapojil jsem Bootstrap, který za mě udělá všechno to CSS a i nějaký ten JavaScript.

Server běží na frameworku web2py, který mi přijde jako ideální rozšíření Pythonu, přestože některé věci by se daly z pohledu čistoty jazyka asi udělat lépe (například používání globálního namespace pro proměnné request, response, session apod.). Výborná je separace Model-View-Controller, což (mimo jiné) ztěžuje vytváření spaghetti-kódu.

Přestože web2py disponuje vlastním webovým serverem, je tento vhodný pouze pro vývoj. Pro ostré nasazení na webu jsem použil web2py propojení s Apachem pomocí mod_wsgi (dokumentace).

Pro renderování tabulky pro zadávání adres, popřípadě jiných údajů, používám Handsontable. Výhodou je možnost použití Control+C, Control+V například z MS Excel nebo z LibreOffice Calc.

Pro ukládání stavu aplikace na straně klienta je použito Web Storage podporované napříč prohlížeči. Do aplikace je tak možné dopisovat průběžně další hodnoty, tak jak přibývají a před tím, než se jde na poštu je vytisknout na štítky a na podací arch. Aplikaci je tak možné používat bez registrace, bez přihlašování a na straně serveru dokonce bez udržování session.

Databáze

Pro ukládání vygenerovaných PDF je jistě možné použít lokální filesystém serveru, ale z mého pohledu mi přišlo řádově lepší použít databázový stroj. Po kladných zkušenostech s dokumentovou databází MongoDB a jeho Pythonovským driverem pymongo jsem se rozhodl použít i modul gridfs.

Samotné GridFS je specifikace v rámci MongoDB, jak ukládat data větší než maximální velikost jednoho BSON dokumentu (16MB). Přestože generovaná PDF se do tohoto limitu vejdou, nabízí Python modul gridfs elegantní file-like rozhraní pro ukládání takových souborů do databáze.

Postup při generování dat je pak následující:

1. Vygenerování PDF štítků a podacího archu
2. Vygenerování UUID version 4 pro identifikaci PDF (ObjectId jsem zavrhl, protože při vhodném časování tvoří číselnou řadu a bez udržování session by bylo možné získat štítky druhých lidí)
3. Uložení PDF do GridFS pod UUID (pymongo transparentně řeší serializaci Python UUID objektu do databáze)
4. Předání UUID pomocí AJAXu klientské aplikaci
5. Stažení/zobrazení PDF v klientské aplikaci

Protože GridFS soubor je v Pythonu file-like objekt, je možné jej jednoduše odstreamovat přímo z web2py. V modelu si udělám připojení k databázi a instanci GridFS:

db = MongoClient(settings.db_uri).stitky123
fs = gridfs.GridFS(db, 'files')

V controlleru pak:

def download():
    id = request.args[0]

    id = uuid.UUID(id)
    db_fr = fs.get(id)

    response.headers['Content-Type'] = db_fr.content_type

    return response.stream(db_fr, 1024)

Vše dohromady

Celé zprogramováno a nainstalováno na Amazon EC2 micro instanci s Debianem. Včetně klikání na AWS, Active24, StartSSL, konfigurace micro instance, Apache, HTTPS, web2py, psaní dokumentace a testování jsou www.123stitky.cz cca 20 hodin práce. Doufám, že někomu alespoň část této reportáže bude užitečná a použije kombinaci Python+web2py+MongoDB+GridFS v některém svém projektu.        

Komentáře

[franta]

Otázka zní, zda vůbec používat webové aplikace, tz. posílat data někam...

[Jan Švec]

Ono s online službami je to obdobné jako se služebnictvem - buď jim člověk dá důvěru a něco si ulehčí, nebo nedá a vše si dělá sám. Ta volba je možná vždy.

[Jiří]

Na štítky a vizitky používám vizitkový guru. Na netu jde dohledat i starší verze, co běží jenom v Javascripu.

[Normotron]

Popravdě jsem si nejdříve pohrával s myšlenkou, že bych něco takového do budoucna potřeboval pro pripravto.cz do budoucna (hlavně do výrobní části). Jenže pak jsem zjistil, že pro mně je důležitá upravitelnost šablony výsledného výstupu.

Pěkné a zrovna to Handsometable se i docela líbí, má to integraci s HTML5 kontrolou pro input? tzn s pattern="" a type="" ? Nebo to je potřeba dodělat ručně?

[Jan Švec]

Handsontable je čistý JavaScript, takže integrace s HTML5 není. Nicméně validace se dá naprogramovat v JS, příklad.

[Filip Jirsák]

Máte ověřené, jak je to s ochranou osobních údajů, když ta vygenerovaná PDF ukládáte na serveru? Potažmo i když tam ty adresy jen zpracováváte. Já chápu, že vy jen poskytujete službu a žádné osobní údaje zpracovávat nechcete, ale ÚOOÚ by se na to mohl dívat jinak (možná, nevím, z mého pohledu se ÚOOÚ bohužel chová nepředvídatelně).

[Jan Švec]

Můj laický úsudek říká, že z pohled zákona jsou www.123stitky.cz na úrovni zpracovatele OÚ a registrace na ÚOOÚ není nutná. PDF jsou ukládána kvůli zpracování a jejich ID jsou (pseudo)náhodná (viz UUID 4), což spolu s HTTPS zamezuje jejich odposlechnutí/uhodnotí třetí stranou. Navíc jsou po 30 minutách odstraněny z databáze.

[Filip Jirsák]

Pokud byste byl "jen" zpracovatel, musel byste mít se správcem údajů uzavřenou písemnou smlouvu. To, že jsou ta PDF po půl hodině odstraněna z databáze by ÚOOÚ asi nezajímalo. Mně by jenom přišlo hloupé, kdybyste kvůli něčemu, co dáte zadarmo k dispozici ostatním, měl ještě problémy s ÚOOÚ.

[Petr Tomášek]

Kua, jaká aplikace? Nějaká blbá webová stránka