PHP: plnění šablony a její tisk

25.6.2008 14:51 | Přečteno: 2852× | Linux

Takže, tohle není žádný objevný příspěvek, ale dotaz. Důvod proč je to tady a ne v poradně je, jak jinak, ten, že nechci aby mi to nějaký béčko zamknulo s tím, že se nejedná o Linuxový problém.

Co bych potřeboval: mám prodejní systém napsaný v PHP a SAPu jako backendu. K tomu hromada JavaScriptu. Do systému se zadávají klienti, různé údaje ohledně jejich koupě atd. Ve výsledku se tyto údaje mají použít k naplnění šablony smlouvy a následně se tato vyplněná šablona vytiskne.

V současné době to řeším tak, že šablonu ve Wordu, kterou mi připraví prodejkyně, převedu (Uložit jako...) do HTML kódu. Tento HTML kód naplním trochou PHP, které si ze SAPu nasosá data a následně celé toto vyplněné HTML pošle jakože RTF dokument. Ten, jakožto zasociovaný s Wordem se v tomto otevře, prodejkyně má možnost případně něco doupravit, a následně jej vytiskne. V čem je problém s tímto (ne)dokonalým přístupem? V tom, že jelikož je to celé v podstatě HTML stránka, formátování je nevalné. Ono jde v de facto jen o mezeru sem, mezeru tam, ale pokud má být něco zarovnáno do sloupečku a někde mezírka chybí, zvlášt na smlouvě za pár mega to nevypadá dobře.

Tudíž potřebuji poradit. Neměl někdy někdo stejný problém, jak plnit šablonu daty v PHP systému tak, aby byla následně ready-to-print? Další můj nápad byl ten, že bych šablonu napsal v TeXu a data do toho doplnil na způsob preg_replace atd. Tím bych se zbavil problému s nekvalitním výstupem, na druhou stranu šablony se mění cca 4x do roka, každá má řádově 20 stran a prodejkyně to neumí, tudíž bych to musel dělat já. Což dělat nebudu. Pokud má někdo nějakou radu, sem s ní prosím.

       

Komentáře

[Jan Včelák]

Nevim, jak moc jsou ty sablony krkolomny a slozity, ale jeste se jenom jedna o nejaka policka, ktera se museji vyplnit + nejake doprovodne texty, tak by nemusel byt problem si napsat v PHP takovej jednoduchej editor na ty formulare. Pridej policko, odeber policko, posun policko. Napada me si sablonu formulare jako takovou ukladat jako pole s nejakym vlastnim formatem a pomoci serializace si to pak ukladat kam chcete. S tim polem se pracuje relativne pohodlne.

No a pak z toho muzou lezt treba PDF.

[pasmen]

Šablony jsou právě celkem hodně složité, nejjednodušším případem je rezervační smlouva na byt. Ta má sice jen pět stran, ale obsahuje sakra hodně údajů, které se tahají (výměry bytu, ceny, výpis z OR, ...). Nejhorší je hlavička, kde se vyplňují budoucí kupující s údaji typu jméno, adresa, datum narození, bankovní spojení atd. Přičemž počet klientů je proměnlivý.

[Chocolate Bear]

Důvod proč je to tady a ne v poradně je, jak jinak, ten, že nechci aby mi to nějaký béčko zamknulo s tím, že se nejedná o Linuxový problém.

OMG, prosím řekni, že jméno tvého blogu nemá nic společného s touhle Elliot.

[pasmen]

Kdeže, má to spojitost s tímto, a to zcela vážně.

[Jiří Veselský]

My máme něco podobného vyřešeno nikoliv přes Word -> HTML -> Word -> RTF nebo jak to bylo , ale pomocí OpenOffice.

V OO jsou udělané šablony, na místech, kde se cosi kdesi doplňuje jsou dohodnuté sekvence (např. #JMENO#). Příslušné šablony jsou nahrané na serveru a využívá se toho, že OO ukládá defacto v zazipovaném XML. Takže PHP skript si šablonu odzipuje, udělá potřebné preg_replacy, respektive dogeneruje XML kódy různých tabulek a podobně, výsledné XML zase zazipuje a nabídne uživateli jako OO dokument.

Výhodou oproti tomu vašemu řešení je, že se "formátování" neřeší v HTML nýbrž v nativní OO formátu, takže je to bezproblémové. Nevýhodou je, že byla skutečně nezanedbatelná onanie vyladit manipulaci s tím XML formátem. Nicméně, když se to jednou udělalo, dají se ty šablony (v rozumné míře) modifikovat, aniž by se muselo sahat do výkonného kódu.

[pasmen]

To zní dobře, s OO bych pracoval daleko raději než s Wordem. Můžu se jen zeptat, kde jsi čerpal informace o formátu OO pro tyhle účely? Když nic tak to vygooglím (snad), ale pokud nebudu muset objevovat kolo, bylo by to fajn

[vatoz]

Příloha:

• objednavky.zip (16755 bytů)

U nás v práci máme podobný systém řešený pomocí Smarty - do zdrojového open office souboru jsme normálně ve Writeru doplnili smarty syntaxí výpis polí Pak jsme oo soubor přejmenovali na zip, v souboru content.xml opravili několik málo znaků které v xml být nemůžou ale smarty je potřebuje ( snad ampersand a uvozovky). Soubor pak prochází skrz smarty na základě aktuálních dat. Na závěr pak soubor vzniklý projetím smarty sbalíme do zipu spolu se všemi soubory z původního zipu a posíláme se správným mime typem. Funguje to hezky, dokonce nstejným způsobem do některých souborů dáváme i obrázky a pak není problém vyplivnout i třeba 300 MB velký OO soubor.

Jako přílohu posílám původní odt soubor (přejmenovaný na zip, protože abclinuxu nějak nemá rádo správný mimetyp). Dá se otevřít jak jako zip, tak jako odt (když se přejmenuje zpátky)

[pasmen]

Super, díky moc. Vůbec jsem nevěděl, že ODT je v podstatě zazipovaný obsah... Blbec já V každém případě ještě jednou díky, tohle vypadá moc hezky.

[Messa]

MS Office by měly mít nějaké API, přes které by mělo jít přidat do wordového dokumentu cokoliv. Snad nějaké COM nebo tak něco, nevím, nedělám v tom. Možná to půjde i v PHP. Taky si pamatuji, že se v officech dá nějak skriptovat (VB?), takže by si to ty údaje mohlo vytáhnout samo. Nebo dokonce, když už je (nebo bude, nesleduji) teď ten wordovský formát standardizovaný a otevřený, pokusit se zasáhnout přímo do jeho zdrojáku

Nebo naučit prodejkyni TeX, třeba se jí to bude i líbit a smlouva za pár mega bude konečně i dobře vypadat (pls no flame, některým lidem by nevadila ani smlouva vysázená v Comic Sans, jiné naopak chyba v mikrometrech praští do oka na první pohled).

[pasmen]

Do Wordu lze pomocí COM rozhraní zapisovat, to ano. Problém je, že v tom případě by musel Apache + PHP běžet na Windows. Nebo se pletu? A to akceptovat nehodlám VB skript by byl fajn, ale pochybuju, že existuje VB konektor pro SAP. I když, je možné že jo. Nicméně nejde jen o získání obsahu políčka. Jde o to, že na základě těch dat musím být schopen přidat popř. odebrat i celý kus textu, např. odstavec. Nevím jak bych takhle pochodil s VB. TeX bych jí nenaučil. Ne že by byla blbá, v tomhle případě naopak. Problém je v tom, že řekne (a poprávu), že tohle není její práce a že je placená za něco jiného. Opět, má pravdu. A ano, rozhozené formátování vadí, viděl jsem exoty kteří jsou schopni na základě takovýhle blbosti neuzavřít koupi za třeba deset milionů.

[Daniel Kvasnička ml.]

IMHO neni co resit. Z databaze pujde XML, XSLT sablona z toho udela content.xml a ten se s predpripravenym zbytkem zazipuje do ODT. Popripade muzes ty data do sablony dostat jinak nez XSLT, ale tohle mi pripadne jako nejlepsi.

Pokud na druhe strane nechteji pouzivat OOo, muzes zkusit http://odf-converter.sourceforge.net/

Dokumentaci ti budiz specka ODF a volne dostupna e-kniha OASIS OpenDocument Essentials.

Kdyby na druhe strane vylozene nechteli ODF, poradil bych ti jeste OOXML a nejaky plugin pro nej do starsiho Wordu. Nicmene vzhledem k soucasnemu nejistemu postoji samotneho MS vuci OOXML (tedy alespon navenek...) si nejsem jisty, jak moc perspektivni reseni by to bylo.

[Daniel Kvasnička ml.]

Kdyz tu nekdo doporucoval Smarty, tak ja doporucim jeste PHPTAL (klon Zope TAL pro PHP), ktery na rozdil od XSLT nevyzaduje vstup jako XML a tim setri nejaky cas pri zpracovani, ale zaroven stejne jako XSLT zajisti validitu XML vystupu (na rozdil od Smarty).

[pasmen]

Moc díky. O XML a XSLT toho vím minimum a času na dokončení o nic víc. Zkusím se na to podívat, ale spíš bych to viděl, že teď to udělám prostě nějak (kouknu na strukturu ODT, jak by tam šlo data alespoň nějak dostat) a pořádně až budou useři ve fázi beta testování. V každém případě se zdá, že mám směr a můžu jít bádat Dík.

[YYY]

Boze to je prispevek za vsechny prachy ;) Nu jinak doporucuji vygenerovani do pdf. Alespon to ty kancelarske krysy nebudou moci modifikovat :P

[pasmen]

Za všechny prachy a hlavně s nulovou hodnotou je spíš tenhle příspěvek... Jinak, buď jsi to nečetl nebo nepochopil, ale o to, aby výsledek před tiskem mohli modifikovat, jde

[YYY]

Pochopil jsem to dobre. Zkus si muj prispevek precist s trochou nadhledu, treba to potom pujde

[Dejv]

Jeste jsem si vzpomnel na tenhle clanecek. Je to sice export do "XML-excelu" (soubor .xlsx), ale v diskuzi jsou i nejake odkazy, treba to nekam povede.

Dejv

[Daniel Kvasnička ml.]

Tem vysokourovnovym knihovnam pro zapis dokumentu se snazim vyhybat. Pokud clovek nepotrebuje neco opravdu jednoducheho (a to IMHO neni pripad autora blogpostu), tak vzdycky narazi na limity te knihovny a pak to obchazet znamena zabit vic casu nez to generovat "rucne"...

[pasmen]

Souhlas. Návrhy ohledně rozzipování ODT a následné úpravy obsahu za pomoci šablonovacích systémů se mi jeví jako přesně to, co potřebuji. Zbývá mi se to naučit

[Ladicek]

Generování XML z textového šablonovacího systému je ZLO (TM) a všechny lidi, kteří něco takového provozují, bych s radostí sprovodil z IT světa. Teda všechny ne, jenom ty, od nichž taková "XML" dostávám a musím jim pak vysvětlovat, že kódování textu uvedené v prologu je opravdu třeba dodržovat, že menšítka, většítka, ampersandy a já nevím co je opravdu potřeba psát v podobě znakových entit, že HTML je potřeba nacpat do CDATA a někdy i že dokument opravdu musí být well-formed. A kdybych přemýšlel dýl, vzpomněl bych si asi i na další problémy. Ne, díky, ksindl.

Tedy ne že by na šablonování bylo něco špatného, chraň bůh, taky generujeme dokumenty z vzorového ODT souboru. Ale generátor tomu formátu rozumí!

[Daniel Kvasnička ml.]

A kvuli cemu myslis, ze jsem o par komentaru vyse psal o XSLT a PHPTAL a upozornoval na to, ze Smarty nezajisti validni XML vystup?

[Ladicek]

Mmm, jakmile někde vidím napsáno XSLT, utíkám pryč, takže jsem to lehce minul

Ale ten TAL vypadá dostatečně úchylně na to, aby se to mohlo být dobré.

[Daniel Kvasnička ml.]

Mmm, jakmile někde vidím napsáno XSLT, utíkám pryč, takže jsem to lehce minul

:-P

TAL je genialnost! Pro PHP jsem nic lepsiho nenasel a kdyby ty dve existujici implementace pro Javu nebyly mrtve, byla by to jedina vec, kterou bych byl ochoten pouzivat misto JSP (jakoze ne, ze bych mi JSP nejak nevyhovovaly -- az na svou tesnou vazbu na request-response cyklus).

[Ladicek]

Taky jsem koukal po těch javovských implementacích, ale ne tak do hloubky, abych zjistil, že jsou to mrtvé projekty. Škoda

Svůj (negativní) názor na JSP už jsem tady vyjádřil, nebudeme s tím začínat znova

[beko]

Celkom by ma zaujimalo akym sposobom pristupujte z PHP do SAP?