čtvrtek 27. ledna 2005

jTDS JDBC Driver 1.0

Alin Sinpalean oznámil release verze 1.0 projektu jTDS. jTDS je open source JDBC driver pro SQL Server a Sybase. Důležitou vlastností tohoto driveru je to, že kromě MSSQL 2000 podporuje i MSSQL 7.0. V několika projektech používáme jTDS k naprosté spokojenosti, což j v kontrastu se zkušenostmi s oficiálním MS driverem, který navíc podporuje pouze MSSQL 2000.

The jTDS Project has released version 1.0 of the jTDS JDBC driver for SQL Server and Sybase. After 3 1/2 years of development, 21 releases and 100K downloads, jTDS is finally considered stable enough and JDBC feature complete to grant the first official production release.

All important bugs fixed, jTDS is still the most performant JDBC driver for SQL Server and Sybase. It passes the J2EE 1.3 certification and Hibernate test suites and is the preferred SQL Server/Sybase driver for JBoss, Hibernate, Atlassian JIRA and Confluence, DbVisualizer and ComPiere.

Související články

středa 26. ledna 2005

XML-RPC a možná cesta pro bohatší webové aplikace

V poslední době poměrně často diskutuje s Michalem o problematice bohatšího grafického rozhraní webových aplikací. V podstatě se bavíme o současných možnostech (html, css, ECMAScript) a spekulujeme nad jednotlivými aspekty té či oné techniky, která by připadala v úvahu. V první řadě je třeba poznamenat, že diskutujeme multiplatformní řešení, které poběží na současných prohlížečích, bez nutnosti instalace jakéhokoliv rozšíření.

Díky tomuto omezení jsme přišly o silné kandidáty postavené na Flash playeru a také o XUL. Osobně vidím počátky RIA postavené právě na Fals playeru, kde se již dnes nabízí komerční Flex (Macromedia) tak open-source Lazslo. Dejme tomu, že bychom chtěli našim klientů poskytnout bohatší GUI, které by nabízelo uživateli větší komfort. Co k tomu budeme potřebovat?

Komponenty - v jednotě je síla

Pokud chceme sjednotit jednotlivé části webových aplikací, umožnit sdílení kódu a nastavit určité obecné chování (například skinovatelnost), pak se neobejdeme bez komponentního přístupu. Budeme muset nadefinovat základní sadu komponent, které poskytnou základní stavební materiál. Jaké komponenty by to měly být? Namátkou se jedná o button, input, combo box, tree, table, calendar, pane, tabbed pane. Celkově by se jednalo o zhruba deset až patnáct komponent.

Jedna věc je mít nadefinované statické komponenty a druhá je jejich oživení. Oživení komponent se mi jeví jako celkem problematické. Jednak budeme ovladače komponent na straně klienta a za druhé budeme potřebovat ovladače na straně serveru. Klientské ovladače by se měly starat o interakci s lokálním kontextem stránky např. uživatel stisknul tlačítko, je potřeba zavolat specifikovanou funkci (submit, validace). Ovladače komponent na serveru slouží k tomu, aby bylo možné držet stavy (rozbalený stromeček, vybrané datum v kalendáři) jednotlivých komponent přes requesty.

Takže máme jednotlivé komponenty a definovaná rozhraní pro jejich ovládání na klientské a serverové straně. Pokud chceme uživateli usnadnit práci, nebylo by na škodu pohrát si s request/response modelem. V podstatě se jedná o to, že jakákoliv dílčí změna na straně klienta, u které je nutný přenos dat na server, otravuje uživatele prodlevou při přenačtení celé stránky. Ve vztahu k našim komponentám jde o to, jak umožnit komponentám co nejefektivnější komunikaci.

Frame, iframe, object, xml-rpc?

Pomocí klientského skriptování můžeme celkem snadno využít "stand alone" prvky, které nabízí samotné HTML, jedná se především o rámce. Jednoduchým skriptem, který bude nastavovat URL pro daný frame lze vyvolávat GET požadavky bez nutnosti přenačtení celé stránky. Samozřejmě možností jak využít frame je daleko více. Nevýhodou framu je z mého pohledu těžkopádnost z hlediska volání serveru a zpracování odpovědi ve formě xml/html dat. Zvažme případ kdy na serveru vznikla nějaká chyba, komponenta bude muset vrácená data celkem složitě vyhodnotit.

Z mého pohledu se jeví jako vhodnější kandidát pro komunikaci komponent protokol XML-RPC. XML-RPC je protokol, který definuje jednoduchá pravidla pro vzdálené volání metod formou výměny XML dat s pevnou strukturou. Díky XML-RPC není problém zavolat jakýkoliv objekt vystavený přes XML-RPC. Existuje celá řada XML-RPC klientů, kteří umožňují komunikaci tímto protokolem, najdete je snad pro většinu dnešních platforem či jazyků (Java, .NET, Delphi, PHP atd.). V dnešních prohlížečích sice XML-RPC klient není přímo integrován, ale implementace není nijak složitá. Navíc bude existovat i volně dostupná implementace.

Výhodou XML-RPC je to, že lze přímo volat service vrstvu vystavenou přes XML-RPC. Nejsme tak nuceni definovat facade vrstvu, která musí v případě použití rámců explicitně mapovat jednotlivé GET/POST požadavky na volání service vrstvy. Následující jednoduché schéma ukazuje celý model komunikace klientských komponent s aplikační logikou prezentovanou service vrstvou.

Schéma ukazující komunikace přes XML-RPC.

Ukázka použití XML-RPC v JavaScriptu bez jakéhokoliv javascriptového frameworku

 
function getUserInfo(){
  var xml = "";
  xml +="<?xml version=\"1.0\"?>\n";
  xml +="<methodCall>\n";
  xml +="<methodName>MyService.getUserInfo</methodName>\n";
  xml +="<params>\n";
  xml +="<param><value><string>Roman</string></value></param>\n";
  xml +="<param><value><string>Pichlík</string></value></param>\n";
  xml +="</params>\n";
  xml +="</methodCall>\n";

netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");

  httpRequest = new XMLHttpRequest();      
  httpRequest.open("POST","http://myserver/xmlrpc");      
  httpRequest.send(xml);      	
  httpRequest.onload = onHttpResponse;              	            
}

function onHttpResponse(){
  xml = httpRequest.responseText;     
  alert(xml);
}
 

Do pranice: Dokumentační systém

Čas od času se na mě někdo obrátí s prosbou o drobnou konzultaci. Nejinak tomu bylo v případě hledání ideálního dokumentačního systému, se kterým se na mě obrátil Róbert Gál.

Prave mame problem, ze musime akunte najst dokumentovaci system, ktory by splnal tieto poziadavky:

  • tymova pouziti - vice lidi editovat soucacne
  • snadna editace - rychlost, dostupnost
  • snadne vyhledavani-fulltext, wildcards
  • exporty do html, pdf
  • podpora cvs - moznost uprav mimo pracoviste (offline)
  • krizove odkazy
  • rozsiritelnost, podpora

jednie co sme nasli je docbook, ale to je vsak prosty zaklad, plus k tomu nejaky opens. editor a cvs. Neni to nic moc... Nevedel by si nieco doporucit? Co vy tam pouzivate? Este som nasiel twiki, co splna vsetky vyssie uvedene poziadavky, ale uklada (ako kazde wiki) data do databaze(xml by bol lepsi).

Uvazovali sme o wiki systemoch (napr. twiki), ktore splnali nase poziadavky, avsak nenasiel som system na baze xml. Kazde wiki si uklada data do dbs, vacsinou pouzivaju nejaky vlastny format. Tak sme sa spolocne zhodli na docbooku, podobne ako Vy. Budeme sa synchronizovat cez cvs. Akurat su tu este 2 dalsie problemy, ktore musime vyriesit:

Snadne vyhledavani-fulltext, wildcard

toto asi budeme riesit tak, ze server vygeneruje html subory z docbooku v nejakom pravidelnom intervale (30min?). To sa da velmi pohodlne napr. s Mavenom (plugin sdocbook...). Potom, zda sa, ze pouzijeme Eclipse-help system k vytvoreniu pekneho helpu z tych html suborov, ktory by potom vypadal ako na adrese http://help.eclipse.org/help30/index.jsp (viz dalsiu adresu: http://www-106.ibm.com/developerworks/opensource/library/os-echelp/)

Vygenerovanu dokumentaciu v ecli.help.systeme by sa dalo dokonca lahko integrovat do eclipsy. Vyvojar by sa mohol pozriet na firemnu dokumentaciu priamo v eclipse. Ale, pravdepodobnejsie je, ze spristupnime dokumnenty na nejakej lokalnej url adrese.

Snadna editace - rychlost, dostupnost

Na druhy problem existuje viac rieseni: k editaciu docbooku pouzijeme nejaky open-source wysiwyg editor. (na meno si uz nespomninam), alebo openofficy. Skoda, ze NEEXISUTJE gui plugin docbooku do eclipsy. To ma prekvapilo. Keby si mal nejake napady, na rychlu editaciu doc-bookov, aby mal co nejnizsie 'learning-curve' pre cely tym

Myslím si, že s CVS a Docbookem není co řešit. Menší nevýhodou Docbooku je větší 'learning-curve' pro většinu jeho uživatelů, tedy pokud se nejedná o HTML/XML kodery. Na druhou stranu pro psáni 80% dokumentace stačí několik málo elementu (odstavec, seznam, nadpis+kapitola, obrázek, odkaz, citace ...), které je schopný absorbovat každý. Spíše jde o obecný konsensus celého týmu v přijmutí Docbooku jako nástroje pro psaní dokumentace.

U nás ve firmě je Docbook standardem pro dokumentaci k IS. Všichni metodici museli přejit z Wordu na Docbook. Samozřejmě jim byla poskytnuta podpora ve formě školení a v v upraveném editoru pro psaní dokumentace. Editor má nastavenou, formou spouštění batch dávek, validaci, kontrolu pravopisu a generovaní výstupní dokumentace. Zmíněný editor je EditPlus, tedy žádný wysiwyg editor. Dále jsou k dispozici interní materiály pro psaní v Docbooku, v podstatě help.

Ještě bych se vrátil k tomu editoru, podle mě je problém sehnat kvalitní a cenově dostupný wysiwyg editor Docbooku. Alespoň to bylo v době kdy jsme na Docbook přecházeli. Pokud jsem teď koukal na podporu v OpenOffice, tak mi jeho podpora wysiwyg přijde absolutně v kontrastu s mou představou o wysiwyg. V případě OpemOffice mi přijde, že daný pisatel dokumentace bude muset tak či onak znát strukturu Docbooku, aby dokument vůbec vytvořil.

Vlastní generovaní dokumentace pomocí Mavenu se mi zamlouvá, jakákoliv automatizace je přínos. Moje idea je vyčlenit jeden produkční server s dokumentací a na něm mít cely proces zautomatizovaný (stažení, generování, packaging, publikování). K vyhledávaní se přímo nabízí Google Desktop Search. Na produkčním serveru dokumentace bych nainstaloval GDS, který by poskytoval vyhledávání komukoliv . Nevýhodou GDS je to, že běží pouze na Windows, pro jiné platformy bych volil například Lucene k čemuž mě inspiroval Dion Almaer článkem I love Lucene.

Související články