pátek 2. července 2004

Editorial:standardy pro webové aplikace

Webové aplikace dneška mají ze střednědobé perspektivy odzvoněno. Současné webové aplikace se dostaly za hranu možností, které nabízí technologie prezentovaná současnými prohlížeči.

Všeobecně se předpokládá, že budoucnost leží v RIA (Rich Internet Application), které by měly za použití budoucí technologie bořit bariéry, které se zdály za použití HTML, DOM, CSS a klientského skriptování nepřekonatelné.

Výše uvedené řádky nejsou ničím novým a posloužily jako letmé uvedení do problematiky. V současnosti tu jsou tlaky na RIA, ale neexistuje žádný standard, který by umožnil jejich tvorbu.

Tam kde nejsou pevně dané mantinely, je i prostor kde lze, kulantně řečeno, manévrovat. Jednu z možností jak tvořit lepší webové aplikace nabízí značkovací jazyk XUL, který představil projekt Mozilla. Další možnosti by měl přinést jazyk XAML jako součást připravovaného OS Longhorn. O své slovo se rovněž přihlásila technologie Flex firmy Macromedia.

Opět nic nového pod sluncem, existují tu řekněme tři hlavní proudy a několik dalších pramínků jako např. General Interface Objects. Je patrné, že ani jedno z výše uvedeného není "průmyslovým" standardem a proto vydat se po proudu jednoho či druhého může v konečném důsledku znamenat problémy.

Hledání standardů

Předešlé řádky mohou navozovat pocit menší deziluze, ale naštěstí si všichni velcí hráči uvědomují nebo alespoň jejich většina, že je třeba hledat kompromisu a umožnit tvorbu webových aplikací další generace standardizovanou cestou.

Webové aplikace proto vzalo pod svá křídla konsorcium W3C a uspořádalo W3C Workshop on Web Applications and Compound Documents. Za zmínku stojí určitě postoje jednotlivých účastníků, hlasování a summary.

Příznivou zprávou je, že se začaly ledy hýbat viz. workshop. Těžko v současnosti vyslovovat prognózy, uvidíme jak bude toto úsilí pokračovat. Jednou jsem byl již v tomto směru velkým optimistou a předpovídal jsem budoucnost technologii Flex, kterou nakonec, dle mého skromného názoru, firma Macromedia zazdila.

Související články

středa 30. června 2004

Sun Multi-Schema XML Validator a kompilace schématu

V projektu, na kterém právě pracuji, potřebujeme validátor XML schémat, který bude sloužit k validaci XML dat na vstupu aplikačního serveru. Řekl jsem si no problem a šel jsem na to. Samozřejmě jsem netušil, že příští den a půl strávím hledáním hloupé chyby.

Moje pouť začala u Sun Multi-Schema XML Validator, který implementuje obecné programové rozhraní JARV určené pro validátory. Diky tomuto rozhraní je možné programově pracovat s validátorem. Více na JARV User's Guide.

JARV mi nabídl ideální možnost, jak uschovat validátor do komponenty, kterou bude využívat aplikační vrstva. Těch několik schémat, která budeme používat, máme uloženy v rámci aplikačního serveru a proto jsem zvolil jejich kompilaci v init metodě validační komponenty.

Kompilace schématu je proces kdy se schéma převádí na objektovou podobu. V chytré příručce je ukázka Schema schema = factory.compileSchema("http://www.example.org/test.xsd");

Převedeno do kontextu aplikačního serveru, schéma mám jako resource(*.xsd soubory) webové aplikace. Předběžná kontrola API objektu VerifierFactory a metody compileSchema, vybírám compileSchema(java.io.InputStream stream).

Výše uvedené dalo vzniknout následujícímu kódu (pouze to nejdůležitější)

 
   factory = VerifierFactory.newInstance("http://www.w3.org/2001/XMLSchema");              
   .
   .
   InputStream is = context.getResource("foo.xsd").getInputStream();
   Schema schema = factory.compileSchema(is);
 

Připravuji testovací objekt, který má validační komponentu vyzkoušet. Pouštím test a ejhle inicializační metoda, kde je výše uvedený kód, vylítne na výjimku. Letmý pohled na stack trace, kde je text, který se mi na den a půl vryje do paměti

com.sun.msv.verifier.jarv.FactoryImpl$WrapperException: java.lang.NullPointerException (celý stack trace)

Po dni prošpikovaném debuggováním, hledáním alespoň nějaké stopy via. Google a zkoušením všeho možného a nemožného docházím k závěru, že to postě nejde a přemýšlím kde udělali soudruzi z NDR chybu. Procházím ještě jednou příklady a říkám si, safra nějak to přece musí jít a zkouším po vzoru několika příkladů podstrkovat místo InputStream přímo File compileSchema(java.io.File f) a WOW ono to funguje!

To není možné, přece nemají chyby v metodě compileSchema(java.io.InputStream stream) snažím se sám sebe přesvědčit a koukám ještě do API objektu VerifierFactory a vidím něco čeho jsem si nevšiml, dvě metody s InputStreamem, compileSchema(java.io.InputStream stream) a compileSchema(java.io.InputStream stream, java.lang.String systemId). Ta druhá má jako argument systemId (systémová identifikátor schématu např. foo.xsd), hloubám v paměti na co to padalo... ic.systemId.equals(url) v objektu com.sun.msv.reader.GrammarReader metoda switchSource( InputSource source, State newState ).

Teď už mi to dochází, ic je InclusionContext privátní třída v com.sun.msv.reader.GrammarReader, to jsem již vyzkoumal při pročítání kódu GrammarReader. Sepnuto, systemId na ic bylo null (to jsem již věděl) a ten důvod byl prostý.

InclusionContext (jak jsem vyzkoumal) vzniká skrze compileSchema a protože některá schémata mají externí entity např. import typů vznikne i odpovídající InclusionContext pro tyto entity. Chudák validátor se pak snaží InclusionContext identifikovat podle jejich systemId viz. ic.systemId.equals(url) a protože jsem použil compileSchema(java.io.InputStream stream) bez systemId s odkazem na externí entitu, tak to skončilo tím NullPointerem. Pokud bych měl zrovna štěstí a předhodil soubor bez externích entit, tak by vše proběhlo v pořádku neboť by vznikl pouze jeden InclusionContext.

Stačila málá úprava kódu a vše běželo podle očekávání

 
   factory = VerifierFactory.newInstance("http://www.w3.org/2001/XMLSchema");              
   .
   .
   InputStream is = context.getResource("foo.xsd").getInputStream();
   Schema schema = factory.compileSchema(is,"foo.xsd");
 

Z výše uvedeného plyne, hned několik ponaučení a chyb. Za prvé, dokumentace (JavaDoc) k rozhraní JARV je nedostatečná. V JavaDocu neni o něčem takovém ani zmínka, všechny metody compileSchema mají stejný dokumentační komentář, nelze tedy určit která by se měla v tom či onom případě použít.

Opět se mi potvrdilo, že ti co hlásají, že dostupnost zdroj. kódu je k ničemu, nemají pravdu. Bez zdrojáků bych byl, nejen v tomhle případě, ztracen nebo v lepší variantě zasekán několik dalších hodin.

úterý 29. června 2004

JavaOne:J2SE 5.0 (Tiger), J2SE6.0 (Mustang) a J2SE 7.0 (Dolphin)

Právě probíhající konference JavaOne přináší vždy plno novinek a trendů, kterými se bude ubírat budoucnost platformy Java.

Tiger:J2SE 5.0 a další verze

Mezi vůbec první informace v přednášce Looking into the Tiger's eye mluvil Ed Ort o blízké budoucnosti Javy. Mohli jsme se tak dozvědět, že Java 1.5 s kódovým označením Tiger už neponese tradiční verzování 1.x, ale bude označena číslem 5.0.

Tiger zahrnuje téměř 100 nových vlastnosti skrze Java Specification Request, a mnohé další úpravy. Jedná se tak o největší změnu od verze 1.0, proto bylo zvoleno i nové číslovaní. Finální uvolnění J2SE 5.0 je plánováno na 30 září 2004.

Připravovaná J2EE 1.5 bude ctít nově zavedené číslovaní, tedy 5.0 a je plánována na druhou polovinu roku 2005. Další verze budou číslovány v pořadí 6.0 a 7.0, dokonce už jsou známy jejich kódová označení a plánované termíny jejich uvedení.

Tiger bude následován Mustangem J2SE 6.0 začátkem roku 2006 a ten Dolphinem J2SE 7.0 v druhé polivině roku 2007. Verze 6.0 a 7.0 by měly pokračovat v nastoleném trendu usnadnění vývoje. Mezi další vlastnosti by měla patřit příma podpora XML, webových služeb, monitoring and management

Mezi další témata přednášky patřily J2ME a především desktop, který uhání Jave mílovými kroky.

Zdroje

pondělí 28. června 2004

Eclipse 3.0 venku

Už je to uděláno, už je to hotovo. Poslední produkční verze vývojového prostředí Eclipse 2.1 datovaná na 28. březen 2003 je minulostí přátelé! Po dlouhé, téměř rok a půl dlouhé cestě, vydlážděné několika milestone verzemi, dosáhl Eclipse finální verze 3.0.

Verze 3.0 je přelomová, přelomová v tom, že Eclipse přidal i tu poslední funkčnost, kterou nabízely konkurenční vývojová prostředí a sám dotáhl téměř k dokonalosti vlastnosti, které nabízel v předešlých verzích.

Pokud se podíváme na pouhý výčet všech vylepšení v oficiálním resumé Eclipse 3.0 - New and Notewhorthy, tak zjistíme, že bylo zapracováno takřka na všech základních částech vývojového prostředí počínaje uživatelským rozhraním a debug perspektivou konče.

Verze 3.0 přináší velký posun oproti 2.1, to ukazovaly v plné kráse milestone (M) verze, které jsem mohl otestovat. Pro uživatele 2.1 vřele doporučuji přechod na 3.0 a troufám si tvrdit, že bude plynulý z hlediska návyku na nové vlastnosti. Menší problémy by mohly nastat v případě starších plug-inu, které nemusí pod 3.0 fungovat korektně.

Obliba a volba Eclipse, jako hlavního vývojového prostředí pro Javu, neustále rostla a můžeme očekávat, že verze 3.0 tomu jen pomůže. Není pochyb, že konkurence dostala šach, a že od matu ji drží pouze opravdu specifická funkčnost, kterou nebyli schopni vývojáři plug-inu dodat na potřebné úrovni.

Nechť začne nová doba, doba zatmění slunce...

Související články