Re: Konverze do PDF
Ano, aplikace je připojena k internetu, ale není možné předávat dokumenty službě provozované třetí stranou. V úvahu by tak připadal pouze vlastní centrální server pro konverzi do PDF. David Mach Dne 8.10.2013 12:29, Petr Šrajer napsal(a): Pěkný den. A je aplikace připojena k internetu? Aby mohla použít jinde běžící server? S pozdravem Petr Šrajer 8. 10. 2013 v 10:56, David Mach: Ahoj všichni, hledám Java komponentu pro konverzi různých dokumentů (nejčastěji z MS Office a Open/LibreOffice, ale i z dalších) do PDF, aniž by byla daná aplikace (Office) nainstalovaná. Ideálně multiplatformní, ale není podmínkou. Neměli byste tip? David Mach
Konverze do PDF
Ahoj všichni, hledám Java komponentu pro konverzi různých dokumentů (nejčastěji z MS Office a Open/LibreOffice, ale i z dalších) do PDF, aniž by byla daná aplikace (Office) nainstalovaná. Ideálně multiplatformní, ale není podmínkou. Neměli byste tip? David Mach
Re: content-type a JSP stranka
Dost často bývá zdrojem tohoto problému ten fakt, že samotný HTML soubor je uložen v kódování Win-1250. Nastav si to v editoru. David Dne 7.9.2010 1:09, ivo_m napsal(a): Já mám trochu podobný problém. Jednoduchá stránka xx.html: Pokus 2 ěščřžýáíéúůťň ĚŠČŘŽÝÁÍÉÚŮŤŇ se mi ve Firefoxu (v. 3.6.8) vždy zobrazí v kódování windows-1250 a musím ji pokaždé ručně přepnout na utf-8, aby byla čitelná. V IE8 to funguje správně. Jak mám přemluvit Firefox, aby to zobrazoval správně? WinXP, Apache 2.2 (localhost) Díky ivo
Re: Modulární aplikace
Ahoj, porušení normální formy databáze by nemělo být dogma - už kolikrát jsem musel volit nutné zlo v podobě redundance dat místo toho, abych omezoval uživatele zbytečně pomalou službou. Každopádně díky za moc cenné zkušenosti a dobré vodítko pro naši další práci! David Mach Dne 2.9.2010 7:29, Ing. Jan Novotný napsal(a): Ahoj, my jedeme na modulárním systému asi 2 roky (s tím rozdílem, že nemáme OSGI, ale jen zřetězené aplikační konexty Springu na stejné classpath - nicméně už to k zavedení modulárnosti stačí). Řešili jsme stejný problém a obávám se, že neexistuje ideální řešení. Základní pravidlo spočívá ve správném "řezu" modulů - každý by měl mít jednoznačnou odpovědnost a funkci. Moduly by se měly vzájemně doplňovat spíš než ve funkcionalitách překrývat. Prostě příliš malé moduly nejsou dobré, protože mají potom mnoho závislostí ven, velké moduly také nejsou dobré, protože se tím zase snižuje jejich použitelnost. Na správném řezu funkcionalitou prostě záleží hodně. Pokud by jeden modul sahal do dat jiného modulu přímo a nikoliv přes jeho API povede toto porušení zapouzdřenosti k: svázanosti (couplingu) těchto dvou modulů, zhoršení testovatelnosti, problém se samostatným rozvojem modulů (vždy se na ně bude muset pohlížet jako na nějaký provázaný celek). My jsme došli ke dvěma možným technikám v těchto případech (naštěstí těch případů není zase až tak moc). 1) obětování výkonu - tj. každý modul udržuje pouze svá data a pokud z nějakého důvodu potřebuje vrátit či pracovat s daty jiného modulu, jde přes jeho API - tím se ale samozřejmě nedá využít JOINů a platíme výkonem. Tyto mezimodulové "dotazy" se alespoň snažíme optimalizovat na metodách API tím, že tam máme metody pro hromadné načítání dat - např. List getDataById(Integer... id), která může všechna potřebná data načít jednorázově přes WHERE id in (...) 2) porušením normální formy db - kromě přímého volání mezi moduly na úrovni API máme ještě jednu formu komunikace postavenou na "observer patternu", která vychází ze Springu, tj. moduly v důležitých okamžicích své funkcionality publikují tzv. eventy do systému, na které pak mohou reagovat listenery v jiných modulech. Tímto způsobem je možné distribuovat některá důležitá (i agregovaná) data do zbytku systému. Uvedu příklad - máme tzv. hodnotící modul, který umožňuje hodnotit libovolný obsah kdekoliv (např. ve formě hvězdiček na nějaké škále), tento modul samozřejmě o obsahu samotném nic neví - naopak jiný modul, který spravuje daný obsah (třeba články) chce při vracení článku vracet aktuální hodnotu průměrného hodnocení. Hodnotící modul vždy po přepočtení aktuálního hodnotícího čísla po daný obsah vyhodí událost do systému, na kterou může kterýkoliv jiný modul naslouchat. Modul starající se o články tuto událost odchytí a k článku si uloží dodatečný údaj o aktuálním hodnocení (již vypočtený, hotový k zobrazení). Tímto způsobem je porušena normální forma - jeden údaj je v DB uložen 2x, nicméně data jsou potom již hezky po ruce (bez výkonnostní penalizace) a nedochází k narušení zapouzdřenosti modulů - jeden může bez problému fungovat bez druhého, pokud běží oba - spolupracují. Pokud existuje ještě nějaký jiný způsob komunikace rád se jej dozvím. Jak říkám, ani jedna z výše uvedených praktik není úplně ideální, ale na nic lepšího jsme za ty roky nepřišli :(. Honza -- -- Ing. Jan Novotný @@ http://blog.novoj.net Myšlenky dne otce Fura ------ 2010/9/1 David Mach mailto:m...@alis.cz>> Zdravím všechny! V naší firmě jsme doposud vyvíjeli klasické aplikace na jedné classpath (typu "vidím vše, volám vše, využívám vše", čili občas pěkná prasárna). Nyní vyvíjíme novou modulární aplikaci postavenou na OSGi, přičemž naše původní vize byla ta, že jednotlivé moduly mezi sebou budou komunikovat výhradně prostřednictvím API. To by ale například znamenalo, že pro získání dat z modulu A (která potřebuji pro SQL dotaz v modulu B) budu muset nejprve volat nějakou metodu z API modulu A, získat ta data a teprve posléze budu moci složit SQL dotaz v modulu B. Z této představy ovšem vstávají některým kolegům hrůzou vlasy na hlavě a horují pro to, abychom se drželi klasické cesty, kdy data z tabulek náležejících k modulu A budeme získávat pomocí JOINů. Chci se tedy zeptat přítomných zkušenějších vývojářů na to, zda je původní vize správná a také na zkušenosti z implementace. Zajímá mě také rozdíl ve výkonu aplikace při použití API vs JOIN... Vřelé díky předem! David Mach
Modulární aplikace
Zdravím všechny! V naší firmě jsme doposud vyvíjeli klasické aplikace na jedné classpath (typu "vidím vše, volám vše, využívám vše", čili občas pěkná prasárna). Nyní vyvíjíme novou modulární aplikaci postavenou na OSGi, přičemž naše původní vize byla ta, že jednotlivé moduly mezi sebou budou komunikovat výhradně prostřednictvím API. To by ale například znamenalo, že pro získání dat z modulu A (která potřebuji pro SQL dotaz v modulu B) budu muset nejprve volat nějakou metodu z API modulu A, získat ta data a teprve posléze budu moci složit SQL dotaz v modulu B. Z této představy ovšem vstávají některým kolegům hrůzou vlasy na hlavě a horují pro to, abychom se drželi klasické cesty, kdy data z tabulek náležejících k modulu A budeme získávat pomocí JOINů. Chci se tedy zeptat přítomných zkušenějších vývojářů na to, zda je původní vize správná a také na zkušenosti z implementace. Zajímá mě také rozdíl ve výkonu aplikace při použití API vs JOIN... Vřelé díky předem! David Mach
Re: Eclipse RCP client + Spring backend
Hezký jarní den! Platforma Eclipse v chystané verzi e4 umožňuje právě deklarativní popis UI včetně runtime manipulace s ním, dále podporu stylů a možnost renderovat výstup na několik způsobů. Jelikož mám k webovým aplikacím hodně blízko, tak se mi právě nová verze e4 hodně líbí. Na druhou stranu mám dilema, jestli naši aplikaci vyvíjet v osvědčené trojkové verzi (ke které existuje řada informačních zdrojů a která bude údajně ještě řadu let podporovaná) nebo rovnou využít možností nové verze s tím, že až půjde naše aplikace na trh, tak už to bude stabilní technologie... P.S. Programování je pořád fun, ale s léty máme víc starostí... ;-) David Mach Dne 22.3.2010 9:46, Karel Tejnora napsal(a): Jediné co mně na Eclipse RCP mrzí je to, že v roce 2010 bych očekával deklarativní přístup (nebo jak se to jmenuje). To jest popsaný interface v xml, groovy atp. Tak aby se rozložení komponent dalo měnit za běhu, často i před očima zákazníka. U Eclipse se mně zdá, že se soustředí hodně na věci nízké vrstvy (často je výběr i z více než 2 možností - Teneo, EclipseLink atp). Chápu, že eclipse je už více méně určitá technologická platforma nebo jak to nazvat a zároveň že programování low end věcí je much more fun(tm). Tady na tu věc poukazuje jedno slavné video Python vs. Java (C++), kde se autor vrací až k tcl/tk. Bohužel jsem zjistil, že než aby Java šla k Pythonu, tak všichni ostatní jdou k Javě (Python-Zope-Plone a PHP 6 se taky snaží). Nepříjde Vám, že programování se změnilo za posledních pár let? Od fun to no fun :-)
Re: Eclipse RCP client + Spring backend
Souhlasím, že je Eclipse platforma docela velké sousto a tak si nejsem jistý, jestli se v tuto chvíli máme zabývat ještě použitím EMF. V naší firmě se používá Enterprise Architect, ale čistě pro analytické potřeby - nemáme z něj žádné výstupy v podobě Java kódu apod. Kdyby však byl přínos EMF zásadní, tak bychom to mohli ještě zvážit - např. tento tutoriál (http://www.vogella.de/articles/EclipseEMF/article.html) je velmi inspirativní... Díky za odezvu! David Mach Dne 12.3.2010 10:16, Karel Tejnora napsal(a): Vec co jsem zapomel, ale v knize to asi bude: jako prvni nejdulezitejsi vec si nastudovat Runtime Configuration. Tak ten editor je hodne dobra vecicka. Velmi rychle vygeneruje GUI pro editaci modelu a je mozne si overit jeho funkcnost. Eclipse je obrovsky. Pak je tam treba jeste Accelo - tam se daji napsat templates, podle kterych se bude generovat kod (treba Spring services). Co se tyce 3.5 tak nosna technologie je OSGi. Jediny problem co jsem mel oproti springu je, ze napriklad start se popisuje v pluginu rekneme dolnim a ne hornim. Tj. ve springu nastavite dependency, zajistite knihovnu a v centralnim XML reknete toto jsou parametry pripojeni do db a startuje se to takhle. V eclipse si vytvorite jeste jeden plugin a u toho kontretniho vyresite nastaveni spojeni do db a reknete startuj se startem aplikace. Co se tyce toho background engine u EMF a spojenych technologii tak je asi nejvic ve predu o proti ostatnim opensource - MDA.
Re: Eclipse RCP client + Spring backend
Zdravím též a díky za odpověď! Jak moc "tlustý" byl pak ten Eclipse RCP klient, když jste na něm měli také použitý Spring? My chceme pro komunikaci použít Hessian, tudíž bychom se na straně klienta mohli bez Springu obejít. Hlavně proto, že by to měl být co nejvíce tenký "tlustý" klient... David Mach Dne 11.3.2010 11:23, Tomas Vitek napsal(a): Zdravím, uvednou kombinaci jsme v bývalé firmě používali. Backend byl v Spring a Hibernate, klient v Eclipse RCP spolu se Springem. Pro komunikaci jsme používali Spring http invoker. Spring jsme na klientovi používali i pro dependency injection a konfiguraci jednotlivých view, commandu atd. Je to schůdná cesta, ale jak už tady někdo psal Eclipse RCP je velký framework a je dobré ho dopředu dobře nastudovat. Hodně štěstí, tomáš
Re: Eclipse RCP client + Spring backend
Dobrý den, díky za odezvu! Kromě těch zajímavých knížek jsem na Amazonu narazil ještě na jednu, která je na rozdíl od ostatních pouze jeden rok stará a podle obsahu to vypadá na přesně ten druh materiálu, který potřebujeme: http://www.amazon.com/Practical-Eclipse-Client-Platform-Projects/dp/1430218274/ Navíc se na květen chystá druhé vydání této knížky: http://www.amazon.com/Eclipse-Rich-Client-Platform-Applications/dp/0321603788/ O SWT/JFace widgetech přehled máme - bylo nutné se s jejich možnostmi seznámit před tím, než jsme udělali rozhodnutí o RCP. UniAnalyzer jsem si stáhl, bude co studovat... :-) Díky! David Mach Dne 11.3.2010 10:39, Lukáš Záruba napsal(a): K SWT bych ještě dodal tento link, velmi dobrý pomocník... http://www.eclipse.org/swt/widgets/ A ještě jednou zdůrazním nápověda, která je v eclipse IDE obsahuje kompletní dokumentaci i k platformě (ext. points, contributions, etc) a k swt i jface (moc milá věc, nejenom MVC, ale hlavně rychle vyrobené open/save dialogy, prompty atd) __ Lukáš Záruba (Lukas Zaruba) Chief Technical Officer MEDIA SOLUTIONS EUROPE Lisabonská 4 Praha 9 190 00 Czech Republic phone: +420 721 879 363 Rastislav Rehak napsal(a): Ahoj raz sme robili jednu velku vec na Eclipse RCP so Springovym zadkom. Komunikacia bola cez Spring RPC. Perzistencia Hibernate. Rozhodne je to schodna cesta. Velky doraz bol kladeny na vykon.Bohuzial publikovat to moc nemozeme. V podstate vzdy ked sa zacinal Eclipse RCP projekt tak si ludia precitali tutorial od Eclipsu a existoval jeden clovek co to uz vedel a mohol ich zaskolit. Dalsia vec na ktoru si treba davat pozor je skutocne komplexnost Eclipsu. Su tam vlastne tri oblastni ktore musite zvladnut: - SWT , uplne iny toolkit oproti swingu, vyhoda je ak poznate win32 API . - Eclipse RCP - pluginy, extension pointy atd - JFaces - high level komponenty nieco ako MVC framework Pokial sa dobre pamatam, tak na Eclipsovych strankach su aj priklady. R
Eclipse RCP client + Spring backend
Zdravím, najde se v českých luzích a hájích někdo s praktickými zkušenostmi s vývojem klientské aplikace na bázi Eclipse RCP? Ideálně připojené na serverový backend postavený na Springu... Rád bych pár věcí před startem projektu konzultoval, ale budu vděčný i za každý odkaz na tutoriál nebo (open source) projekt. Díky předem! David Mach
