pátek 20. srpna 2004

Jak správně odkazovat na nadnárodní firmy?

Jak správně odkazovat na nadnárodní firmy? Tahle otázka mě vždycky napadne, když píšu příspěvek, který se týká firem jako Microsoft, Sun, Oracle, IBM atd. Měl bych uvádět odkaz na jejich "základní" stránky (microsoft.com, sun.com, oracle.com) nebo použít odkaz na jejich lokální stránky tedy (microsoft.cz, sun.cz, oracle.cz)? Vrtá mi to hlavou už delší dobu.

Já osobně bych preferoval odkaz na jejich lokální stránky (české zastoupení). Nemám sice pro a proti, ale přijde mi přirozenější dostat se na lokální stránky. Informace, které nejsou lokalizovány a vedou na mateřský web, bývají většinou označeny. Nehrozí tak situace, že by čtenář přehlédnul nějaké důležité informace.

čtvrtek 19. srpna 2004

ECMAScript for XML (E4X) kladivo na nedokonalost DOMu

Ač považuji specifikaci DOM za velice přínosnou, tak jsem byl v praxi mnohokrát vystaven její nedokonalosti či nedokonalosti její implementace. DOM je navržen tak obecně, aby s ním šla zpracovat jakákoliv obecná struktura dokumentu.

Snad nejvíce se s "nedokonalostí" DOM setkávám při práci s částí HTML dokumentu. Pokud nemají elementy jednoznačné identifikátory (atribut id), je iterování přes kolekce uzlů noční můrou. K tomu musíme připočíst, že Mozilla a Internet Explorer jinak nakládá s bílými znaky. Psát v takové situaci přenosné skripty je spíše dílem testování než efektivní práce.

Jak často jsem žehral, na absenci jazyku XPath nebo jeho obdoby. Příjemnou novinkou byl pro mě článek Petra Cimpricha Akta X 0407, ve kterém je řeč o rozšíření specifikace ECMAScriptu o podporu XML. Cílem tohoto rozšíření je usnadnit práci v oblastech kde DOM a XSLT nepostačuje.

Rozšíření je koncipováno především s ohledem na současné "javascriptové pisálky" tedy programátory. Tvůrci nás nechtěli evidentně zatěžovat novými technologiemi, ale vsadili na přímou integraci, která by měla usnadnit vstřebání tohoto rozšíření. E4X vypadá opravdu velice zajímavě, pokud se povedejeho integrace do jinak nepodajného Internet Exploreru, můžeme se těšit na efektivnější práci.

středa 18. srpna 2004

Na prohlížeči záleží

Dokument Bezpečnost Mozilly a odvozených prohlížečů, který byl přeložen na serveru Czilla z originálu Security and Mozilla browsers, dobře vypovídá o odlišných přístupech k bezpečnosti dnešních prohlížečů.

O bezpečnosti prohlížečů, především Internet Exploreru, ve světle posledních bezpečnostních problému, toho bylo napsáno hodně. Situace už je tak daleko, že se doporučuje všem uživatelům Internet Exploreru přejít na jiný prohlížeč. Ač se jedná o dokument "spřátelený" s prohlížečem Mozilla zcela jasně, srozumitelně a nezaujatě dává laikovi nahlédnout pod roušku bezpečnosti dnešních prohlížečů.

Žádný prohlížeč nemůže poskytnout 100% ochranu, zrovna tak jako nemůže být 100% účinná žádná sada zámků a klíčů od našich domovů. Ale návrh a provedení prohlížeče může vytvořit obrovský rozdíl v úrovni ochrany uživatelů.

ADF Faces - GUI JSF komponenty od Oraclu

Mladá technologie Java Server Faces je obdoba WebForms platformy .NET. Cílem JSF je poskytnout znovupoužitelné komponenty pro tvorbu view vrstvy. Před příchodem JSF bylo nutné vytvářet proprietární knihovny vlastních komponent, které se dále používali v aplikaci.

Vzhledem k tomu, že se jedná o mladou technologie, existovalo poskromnu implementací. ADF Faces představené firmou Oracle vypadají opravdu zajímavě. Sumář taglibrary i se screenshoty komponent namátkou kalendář, záložky, tlačítka atd. dávají zapomenout na ošklivě vypadající referenční implementaci firmy Sun.

Související odkazy

úterý 17. srpna 2004

I18N pro webové aplikace

Hledání frameworku pro tiskový výstup jsem trochu odsunul na vedlejší kolej a zaměřil jsem na další palčivý problém, který se týká internacionalizace (I18N) webových aplikací v rámci JSP.

Snažím se najít nejschůdnější cestu především pro textové překlady. Vzhledem k tomu, že používáme Struts, tak se přímo nabízí jeho podpora Internationalized Messages. Na druhou stranu bych se nerad svazoval s proprietárními leč výbornými Struts.

Standardní cesta, která se mi zdá nejpřirozenější, je použití JavaServer Pages Standard Tag Library (JSTL) lépe řečeno referenční implementaci Taglibs. JSTL standardizuje podporu pro I18N a tak to vypadá, že vyzkouším I18N Tag Library.

Existuje ještě něco dalšího, co by stálo za pozornost a prozkoumání?

neděle 15. srpna 2004

Kdo pomůže webovým formulářům

Ačkoliv má specifikace XForms pod křídly konsorcia W3C status doporučení a honosí se přívlastkem The Next Generation of Web Forms, k jejímu širšímu rozšíření prozatím nedošlo.

O důvodech "úspěšnosti" XForms, můžeme polemizovat, ale podle mého názoru je zde opět klíčová pozice lépe řečeno absence největšího hráče (Microsoft) na poli webových prohlížečů. Na druhou stranu, v pracovní skupině XForms jsou například zástupci Oraclu, Novellu, IBM a Sunu.

Právě Novell a IBM ve spolupráci s Mozilla Foundation oznamili otevření XForms projektu. Pro IBM nejsou XForms půdou nedotčenou, Velká Modrá má již vlastní projekt IBM XML Forms Package.

Současná aktivita kolem XForms a webových aplikací jasně naznačuje, že existuje poměrně silná vůle pohnout se současnou situací s ohledem do budoucnosti. Velkým strašákem je dle mého názoru OS Longhorn s novým Internet Explorerem, který bude umožňovat díky jazyku XAML a renderovacímu jádru Avalon velké věci.

Java:konvecne pro psaní kódu

Většina programovacích jazyků si postupem času vytvoří určité konvence pro zápis zdrojového kódu. Konvence jsou formální a neformální, ty neformální většinou vznikají přirozenou evolucí a tím jak probíhá migrace mezi jednotlivými programovacími jazyky.

Tomáš Kouba ve spotu Jak psát identifikátory v Javě a C# poukazuje na základní konvence při psaní identifikátorů. Tomáš se zabývá myšlenkou použití diakritických znaků v názvech identifikátoru. Já osobně bych "české" znaky nepoužil, na druhou stanu je dobře pokud ta možnost existuje, uritě se najdou programátoři, kteří ji využijí.

Nepodceňujte konvence

Pokud se vrátím k Jave, pak existují formální pravidla nejen pro identifikátory. Dokument Java Code Conventions popisuje například formátování komentářů, jména souborů a jejich organizaci, odsazování nebo deklaraci bloků.

Java Code Conventions jsou uceleným dokumentem, který by si měl alespoň jednou za čas projít každý javovský vývojař. Největší přínos code conventions spatřuji při psaní lépe řečeno sdílení kódu v rámci vývojového týmu. Pokud si všichni členové týmu zažijí jednotná pravidla, pak je výsledná efektivita při práci značná.

Dokonce může dojít i k drobným odchylkám od Java Code Conventions, díky kterým mohou vzniknout obecné neformální konvence a formální v rámci vývojového týmu. Mezi takové neformální konvence pak může patřit například pojmenování všech rozhraní s prefixem I (IOsoba) nebo naopak všech implementací rozhraní se sufixem Impl (OsobaImpl).