pátek 27. srpna 2004

Články na víkend

Články na tento víkend jsou všehochutí co mě zaujalo. Práce s windows console, ve které ukazuje Petr Lazecky opravdová kouzla, prolomení hašovací funkce MD5 nebo Java Virtual Machine pro .NET.

středa 25. srpna 2004

Java - dokumentace v hrsti

Dokumentace k API (J2SE, J2EE, J2ME), se kterým se běžně setkává vývojář Javy je součástí SDK. Problém nastává v případě různých frameworků a komponent třetí strany, bez kterých se vývojář neobejde. Ve většině případů se používá binární distribuce ve formě jaru, která se přidá na classpath. Díky tomu nám IDE může nabídnout službu ve formě code assistent.

Problém nastane ve chvíli, kdy potřebujeme dokumentaci tzv. JavaDoc k samotnému API, které využíváme. V takovém případě máme dvě možnosti. Stáhnout si zdrojové soubory, které umí zpracovat IDE a Javadoc nabídnout nebo dokumentaci najít a stáhnout přímo od "výrobce".

Ani jedna z možností není ideální nebo alespoň ne pro mě. Velice mě proto potěšila aktivita serveru Javalobby, který nastartoval online shromaždiště javovských API JDocs. K dnešku je na JDocs zařazeno a indexováno celkem 106 API, které je možné online prohledávat.

Tato zpráva je sama o sobě potěšující. Bohužel se objevil problém s dokumentací k J2SE, J2EE, J2ME, na které si dělá výhradní právo Sun. Sun sice požádal o stažení dokumentace, ale k dnešku je tato dokumentace stále dostupná. Více o tomto problému na serveru TheServerSide JDocs.com: Sun protects itself, Javalobby wants to move on

Pro uživatele Eclipse je tato zpráva ještě potěšující. Existuje plugin, díky kterému je možné prohledávat API na JDocs z pohodlí IDE.

Popis instalace pluginu

Help >> Software Updates >> Find and Install >> Search for new features to install >> New remote Site >> Name:JDocs Search plugin, URL:http://www.jdocs.com/plugins/eclipse/ >> ok >> vybrat JDocs Search plugin >> next >> vybrat >> next >> install

Dagblog související články

úterý 24. srpna 2004

Tomcat a kódování externích souborů

Včera jsem narazil na problém s kódováním externích souborů (javascript). JavaScript měl kódování utf-8 stejně tak i stránka jejíž byl součástí. Bohužel webový server Tomcat standardně servíruje externí součásti stránky s kódováním ISO-8859-1.

Naštěstí se mi podařilo nalézt celkem elegantní řešení v podobě konfigurace serveru. Konfigurace servletu dovoluje definovat mapování mime typů, pak stačilo najít v souboru %TOMCAT_HOME%/conf tradiční soubor web.xml a najít řádku

 <mime-mapping>
        <extension>js</extension> 
        <mime-type>text/javascript</mime-type>
 </mime-mapping>

a přidat informaci o kódování, která je webovým serverem zasílána v HTTP hlavičce odpovědi.

 <mime-mapping>
        <extension>js</extension> 
        <mime-type>text/javascript; charset="utf-8"</mime-type>
 </mime-mapping>

Na místě je ještě poděkování nástroji IEWatch, který nám (moje maličkost a Nkd) umožnil velice konfortně sledovat jednotlivé hlavičky.

pondělí 23. srpna 2004

Mozilla a Document.all, ve jménu rozšíření

Staré pravdy neplatí, prohlížeče postavené na jádru Gecko budou v blízké budoucnosti podporovat propritární rozšíření document.all. Neoficiální tiskovou zprávu připravil server Czilla v článku Document.all - omezená podpora v Mozille s podtitulem a proč je použití document.all na Internetu špatné.

Zveřejnění této informace vyvolalo ohlas, ale nepodařilo se mi najít žádný relevantní komentář k této události. Zkusím Vám nabídnout dva pohledy na tuto událost.

Uživatelské hledisko

Ač si projekt Mozilla klade za cíl technickou evangelizaci, tím nejdůležitějším jsou pro něj spokojení uživatelé. Těžko si lze v dnešní době představit situaci, kdy bude striktní dodržování pravidel (standardů) znamenat přímou úměru k úspěšnosti prohlížeče, první bohužel. Úspěšnost a neúspěšnost prohlížeče se dnes především hodnotí podle toho, kolik jej používá uživatelů, druhé bohužel.

Tato "úspěšnost" kolísá u prohlížečů mimo rodinu Internet Exploreru, též hanlivě nazývaných alternativní, podle schopnosti poradit si s proprietárním rozšířením DHTML, které ve jménu pokroku přinesl právě Internet Explorer. V zájmu spokojených uživatelů, tedy i mě samotného, přinese podpora document.all samá pozitiva. Množina stránek, které dříve nefungovaly korektně, se zúží a přibude nových uživatelů.

Z pohledu uživatele velká jednička.

Aplikační hledisko

Pokud jsem z pohledu uživatele chválil, tak z aplikačního hlediska budu hanit. Pokud se partička kolem Brendna Eicha rozhodla zpřístupnit document.all, měla to udělat pořádně. Document.all v Mozille se nechová stejně jako v Internet Exploreru!

Chápu, že tento "hack" byl proveden se zacílením na koncového uživatele, ale implementace document.all mohla jít více do hloubky. Takhle jsme dostali do rukou něco co nefunguje pořádně, a je lhostejno že by se to nemělo používat. Desítky, stovky nezkušených vývojářů budou vystaveni kruté realitě při zkoumání přístupného, ale ne zcela funkčního document.all.

Chcete dva příklady, které vykazují rozdílné chování? Zkoušeno v Mozille 1.8.3 alfa a IE 5.0 SP3

 	
	function foo(){
		alert(document.all["first"].length);
	}
         
	.
	.
	.
	<div id="first">xyz</div>
	<div id="first">xyz</div>
 
 
   	function foo(){
		alert(document.all.length);
	}
         
	.
	.
	.
	<div id="first">xyz</div>
	<div name="second">xyz</div>
 

Jsem přesvědčen, že bychom našli i mnohem záludnější případy, ale cílem nebylo postihnout všechny nekompatibility. Chtěl jsem ukázat, že to co vypadá jako velice užitečné, se může ve výsledku obrátit a stát se pěkně záludným. Samozřejmě můžeme namítat, že document.all je pouze obezlička, která se nebude používat.Tak či onak, stará pravda, že document.all nefunguje v Mozille neplatí. Nyní musíme hledat cesty jak rozpoznat nekompatibility a včas na ně upozornit.

Související články

Dagblog - související