Vzdáleně generovaný XUL

25.4.2008 23:07 | Přečteno: 1403× | | poslední úprava: 27.4.2008 08:33

V posledních pár týdnech jsem svoji pozornost zaměřil na XUL - jazyk založený na XML sloužící k popisu uživatelského rozhraní, který využívájí především projekty založené na Gecku. Rád bych zde shrnul pár svých postřehů.

Pokud svůj projekt vybavíte webovým rozhraním, pravděpodobně nakonec narazíte na hranice dané tím, že uživatelské rozhraní je zobrazováno webovým prohlížečem, který si např. přivlastní některé klávesové zkratky, bývá poměrně pomalý a realizace některých základních prvků, které grafická uživatelská rozhraní mají už od plínek (kontextová menu, oddělovače apod.) se zde realizují jen značně komplikovaně. Konec konců, HTML stránky původně vznikly pro zobrazování hypertextových dokumentů a nikoliv pro tvorbu uživatelských rozhraní. Na druhou stranu nabízí dynamicky generované HTML stránky značnou flexibilitu a platformní či licenční nezávislost, kterou naopak můžete postrádat u různých GUI toolkitů.

XUL svým způsobem umožňuje zkombinovat to nejlepší ze světa webových a nativních rozhraní. Nedaří se mu to úplně dokonale a samozřejmě i on má své limity a úskalí, ale pro celou řadu projektů se jedná o rozumnou volbu.

XUL definuje uživatelské rozhraní, které je pak zobrazováno uživatelům speciálním renderovacím jádrem v s pokud možno takovým vzhledem a ovládáním, na jaké je u své platformy nativně zvyklý. O vlastní aplikační logiku se musí starat někdo jiný. Často se jedná o nativní kód propojený se zobrazováním GUI přes speciální rozhraní (XPCOM). To je vhodné především pro samostatné lokální aplikace. Další dnes velmi oblíbenou možností uplatňovanou především u rozšíření Firefoxu je napsat celou logiku pomocí JavaScriptu

Mě zajímala hlavně třetí možnost - vzdálené generování XUL přenášeného přes HTTP podobně jako u HTML stránek. Tato varianta je výhodná především pro intranetové aplikace, má ale některá nepříjemná omezení (viz dále).

SeasideXUL

Mým cílem bylo umožnit generování XUL kódu ze smalltalkovského webového frameworku Seaside a vyřešit si tak věčnou otázku nativního smalltalkovského rozhraní se standardním "Look&Feel". Samozřejmě lze podobně postupovat i na jiných platformách. Pokud Vás Smalltalk vyloženě nezajímá, tuto kapitolku můžete přeskočit. Seaside je komponentový kontinuační webový framework, který velice zdařile umožňuje vytvářet webové aplikace přirozeným způsobem tak, že je jejich tvorba velmi podobná tvorbě aplikací s nativním GUI. Přímo se proto vybízí Seaside k tomuto cíli využít přímo.

Seaside nepoužívá primárně žádný šablonovací systém a jde raději cestou skládání jednoduchých univerzálních komponent. HTML kód je generován přímo ze Smalltalku pomocí Canvasu s využítím bloků. Hlavním úkolem tedy bylo vytvořit speciální canvas, který místo HTML kódu bude produkovat XUL. Tvorb uživatelského rozhraní pak vypadá např. nějak takto:

    xul groupBox flex: 1; with: [
        xul caption label: 'orientation'.
        xul vBox with: [
            xul description value: 'some text'.
            xul checkbox label: 'Left'.
            xul separator flex: 1.
            xml button flex: 1; label: 'Submit'. ]].

Seaside je navržena pro HTML, kdy se při zaslání požadavku klientem generuje celá stránka a značnou část svého know how věnuje tomu, aby tím programátor byl obtěžován co nejméně. Pro XUL je tento přístup ale krajně nevhodný a překreslovat celé uživatelské rozhraní vždy, když uživatel udělá nějakou výraznější změnu, je nesmyl. Proto musela přijít ke slovu komunikace prostřednictvím XMLHttpRequestů. Ty se sice v Seaside také používají, nicméně ne pro operace jako volání komponent, kde by už implementace byla dost problematická.

Víceméně jsem musel nad Seaside postavit vrstvu, která veškerou komunikaci zprostředkovává přes Ajax. Bylo tedy nutné ve XUL kódu vymezit komponenty (nechápu, proč v definici XULu není žádný element pro vymezení logické oblasti dokumentu bez vlivu na zobrazní), aby s nimi šlo samostatně pracovat, a dále se postarat o zpracování volání kompoennt přes XMLHttpRequesty. O co konkrétně jde, si ukážeme na příkladě:

    xul button
        label: 'login';
        onCommand: (xul ajax callback: [
            |  user |
            user := self call: LoginComponent new.
            self call: (UserInfoComponent new user: user) ]).

V tomto příkladě jsme na komponentu umístili tlačítko, na které když uživatel klikne, objeví se místo původní komponenty komponenta se zadáním přihlašovacích údajů. Po jejich vyplnění se místo přihlašovací komponenty objeví jiná, která zobrazí informace o uživateli.

Samotné dočasné nahrazení jedné komponenty jinou se řeší jednoduše pomocí dekorátoru, který deleguje prováděné operace a zobrazování na nahrazující komponentu. Složitější je to s řízením toku, protože při zaválání komponenty se musí aktuální výpočet přerušit (počkat na výsledek volání), zaslat klientovi příkaz zobrazení volané komponenty a v okamžiku, kdy volaná komponenta na uživatelův popud vrátí řízení zpět, pustit výpočet dále, ovšem s tím, že nyní již reagujeme na jiný požadavek klienta (generujeme odpověď na jiný XMLHttpRequest). Naštěstí i toto šlo nakonec s pomocí výjimek a kontinuací vyřešit doslova na pár řádcích. Pro to, aby bylo možné pracovat jednoduše s více vstupními elementy zároveň, bylo nutné zavést i jistou alternativu k HTML formulářům.

Omezení vzdáleného XUL

Nejjednodušší možnost, jak zobrazovat vzdáleně generovaný XUL, je použít přímo Firefox. Ten si ovšem podobně jako v případě HTML stránek zabírá některé klávesové zkratky apod. Nicméně se jedná o nejvhodnější možnost v průběhu vývoje, protože je možné použít např. rozšíření Firebug.

Druhá možnost je použít samostantý XULRunner, kdy pro aplikaci nejdříve vytvoříme sadu pár konfiguračních souborů, viz (http://developer.mozilla.org/en/docs/Getting_started_with_XULRunner). XULRunner zatím není ve finální verzi. Malá perlička z natáčení - když jsem chtěl otestovat nejnovější night-build XULRunneru pro Windows, při startu hlásil velice nekonkrétní a podivnou chybu. Když jsem ji předhodil googlu, vypadlo mi z něj, že se jedná o chybu, kterou hlásí programy vytvořené v nových Express verzích VisualStudia, když běží na strojích, kde VisualStudio není nainstalované.

Třetí možností je nový Firefox 3 zavolat s parametrem -app, kdy mu předáme odkaz na ini soubor aplikace. Jak pro XULRunner tak pro Firefox 3 stačí uvést URL do souboru prefs.js, např.:

pref("toolkit.defaultChromeURI", "http://localhost:8888/seaside/SeasideXUL%20Periodic%20Table/");

Takto pouštěný XUL má ovšem silná bezpečnostní omezení. Hodně limitující je např. nefunkční XUL element editor, což je krajně nepříjemné zejména z toho důvodu, že víceřádkový textbox je téměř nepoužitelný.

Mozilla nabízí tři možnosti, jak si kýžená vyšší bezpečnostní oprávnění zajistit, což je celkem dost, bohužel prakticky použitelné není ani jedno.

První možností je používat podepsané skripty a jiné zdrojové soubory, které jsou umístěny do jar archivu. Tato varianta je prakticky nepoužitelná, protože je vyžadován certifikát od uznávané certifikační autority, které vám ho jen pro dobrý pocit nevydají. Navíc takto samozřejmě nelze podepisovat dynamicky generovaný obsah. Dále se uvažuje, že tato možnost bude v budoucnu zcela zrušena.

Druhou možností je vytvořit konfigurační soubory aplikace a zdrojové soubory zaregistrovat do chrome. To by byla pro distribuci schůdná varianta, kdyby do chrome nešly registrovat jen lokální soubory (file:///).

Třetí doporučovaná a jediná plně podporovaná varianta je vytvořit si vlastní rozšíření, které bude se vzdáleným serverem přímo spolupracovat. K tomu bych dodal ještě pár slov, z nichž by ale ani jedno nebylo použitelné ve slušné společnosti, tak raději budu mlčet.

Nakonec jsem přišel ještě na jednu cestu, jak dosáhnut požadovaného cíle, ovšem nedokážu se ubránit dojmu, že se jedná o nevzhledný hack, který v příštích verzích už nemusí fungovat. Nezbývá než doufat, že pokud se tak stane, dají nám vývojáři z Mozilly nějakou rozumně použitelnou alternativu.

Do souboru chrome.mainfest se zapíše odkaz na lokální soubory a vytvoří se overlay odkazující na server, např.

content myapp file:content/
overlay	chrome://myapp/content/main.xul	http://localhost:8888/seaside/SeasideXUL

Dále se do v lokálních souborech vytvoří XUL soubor main.xul, který vytvoří hlavní okno bez obsahu - nadefinuje pouze titulek a velikost okna. Nakonec se tento soubor definuje jako vstupní pro aplikaci v souboru prefs.js

pref("toolkit.defaultChromeURI", "chrome://myapp/content/main.xul");

XUL je velice zajímavá a slibná technologie, ale ještě nevyrostla z dětských nemocí. Jistě by doznala většího rozšíření, kdyby vývojářům neházela zbytečně klacky pod nohy.

       

Komentáře

[KS]

No ja jsem vždycky tvrdil, že dělat rozhraní třeba pro nějaký informační systém je lepší v XULu, vždyť toho Firefoxa si může každý zadarmo nainstalovat na libovolnou platformu a výsledek potom podle mě stojí za to.

[Marek 'marx' Grác]

Bohužiaľ to je presne tak ako je uvedené v závere. Nikdy nevieš kedy ti to rozbijú :) a občas sa im to fakt zadarí na miestach, kde to nikto nečaká.

[KS]

No to je blbe, ale kdyz clovek dela webove aplikace s XHTML a CSS, tak to taky neni zadny med. Optimalizace pro ruzne prohlizece a delani slozitejsich ovladacich prvku je mnohdy dost opruz.

[Robert Krátký]

Zajímavý zápisek, díky.

[Chocolate Bear]

V čem je praktický přínos, že se bude rozhraní generovat, oproti tomu, kdyby se vytvořilo dopředu spolu s nějakou tenkou vrstvou a server by posílal jenom přežvýkaná data?

[Pavel Křivánek]

To závisí hodně na druhu aplikace. Generování je rozhodně flexibilnější. Ne vždy dopředu víte, jak GUI bude vypadat (např. smalltalkovské IDE).

[hikikomori82]

ja mam prakticku skusenost s xul taku ze da sa, ale treba sa vys*at na template a rdf datasety ktore su v xul a namiesto toho pouzivat javascript+xmlhttprequest a data vkladat do komponentov v prehliadaci