jarda jirava .net - stránky věnované .net technologii, vývoji software s pomocí .net frameworku, návrhu software a architektuře řešení

Typická situace ve firmě. Máte systém, který je poměrně úspěšný a prodejný, na něj máte napojeny i interní procesy. Vše funguje skvěle, všichni jsou spokojení a nic Vás netrápí. Naprosto ideální situace, teď si říkáte utopie, no skoro. Ten systém se jmenuje InFis a již jsem se tu o něm několikráte zmiňoval.

Jaký mám ale důvod zmiňovat InFis, jak se to slučuje s doplňkem pro Outlook. Ta situace, kterou jsem popisoval výše je báječná a skutečně to tak funguje, jenže do té chvíle, než poznáte všechny výhody InFisu. Najednou zjišťujete, že jej můžete využít ještě více, jenže nastává problém, přichází Vám i od partnerů a klientů několik emailů, které chcete zařadit mezi úkoly, případně si chcete naplánovat schůzku a dalších několik věcí zařídit rovnou z otevřeného emailu. Jenže co teď, jste v Outlooku a přepínat se na prohlížeč a vyplňovat, kopírovat, hledat?

Možná ještě než budu pokračovat v dalším psaní, musím zmínit, že Exchange skutečně nepoužíváme a ani nevidíme důvod, proč ji používat, neboť vlastní systém splňuje naše požadavky a pro několik oblastí, či spíše modulů neexistuje v Exchange podpora.

Použijeme Web služby a .NET Framework 2.0

InFis je intranetová/internetová aplikace, která skýtá široký potenciál pro využití právě webových služeb. Proto jsem vytvořil na straně serveru jednoduché rozhraní, ke kterému je možné se připojit a využívat tak několik služeb, které InFis poskytuje. Poté začal vývoj samotného doplňku. Stažení VSTO, doinstalování podpory pro programování Office aplikací v .NET Frameworku.

Vznik a strasti při vývoji Add-inu

Založit nový projekt typu Outlook add-in v novém VS.NET 2005 je jednoduché. Pak už jenom stačilo doplnit kód do metod ThisApplication_Startup a ThisApplication_Shutdown. Tady jsem prvně zatápal, najít správnou obsluhu události pro odchycení vytváření nového Inspectoru. Nakonec se vše podařilo a já přidal CommandBar na to správné místo, tedy do správného okna.

Aplikace se spustila a vše se zdálo být krásné. V okně zprávy se zobrazilo tlačítko, po jehož kliknutí vyskočil mě známý dialog a došlo k uložení informací přes web service. Tudíž správná chvíle, publikovat pro kolegy tento doplňek. Při svých toulkách po poznávání programování pro Office, jsem narazil taktéž na odkaz Creating an Outlook Business Contact Assistant Add-in with Visual Studio Tools for Office, který mi pomohl v doplnění Custom actions do setup projectu.

Instalace Add-inu

Přichází asi nejstrastiplnější cesta, kterou jsem zatím podstoupil. Vytvoření instalačního balíčku proběhlo v pořádku a přišlo první nasazení. Instalace .NET Frameworku 2.0 a následná instalace mého balíčku. A překvapený údiv nad tím, že tlačítko, které se mělo zobrazit se nezobrazuje. Nastalo pátrání, následný dotaz do diskuze a stále bez výsledku. Jelikož to příliš nehořelo, nechal jsem to chvíli uležet, než jsem začal bádat a zkoušet dále. Pak jsem si uvědomil, že by mohl být problém s PIAs. Došlo tedy k jejich instalaci a stále nic. Tak ještě doinstalovat podporu pro programování pomocí .NETu. Nepomohlo, já už fakt nevím, sklonil jsem hlavu a pomalu odcházel na své místo. Když si kolega všiml, že v odkazu na doplňek v nástrojích Outlooku je cesta, kterou na svém počítači nemá.

Asi tušíte, co to se mnou udělalo, údiv, překvapení, mírný vztek. Jak je tohle možný, vždyť došlo k úspěšné instalaci, všechno by přeci mělo být instalováno, tak co tam jenom chybí. Začal jsem tedy prohledávat internet a hledal jsem AddInLoader.dll a zjistil, že ten se nachází v instalaci VSTOR. Download, install, funguje. Doplňek se v pořádku nahrál a je funkční. Je vyhráno, ale proč se tohle nezahrne do instalačního balíčku? A zmínka o tom téměř nikde. To téměř zmiňuji proto, že jsem nakonec, poté co jsem věděl co hledat našel odpověď (ta poslední).

Rekapitulace

Pokud se rozhodnete nasadit Add-in pro Office 2003 napsaný za pomoci .NET Frameworku 2.0 a VSTO, zkontrolujte si, že na klientovi je:

• správně nastavena CAS policy pro adresář se soubory s doplňkem a manifestem na Execution a samotné dll má nastaveno FullTrust oprávnění
• provedena registrace doplňku v registrech jejíž popis najdete v odkazu výše
• přítomen AddInLoader.dll, který se nachází v instalaci VSTOR

Tento příspěvek měl být prvním, ovšem jak už to tak bývá, ne vše se podaří jak má a tak se na první přehled zdrojů podívám až nyní.

Pro začátek jsem vybral zdroje, které pocházejí přímo od Microsoftu. Pojďme se na ně podívat. Asi prvním bohatým zdrojem, popisujícím veškeré dostupné Providery je ASP.NET 2.0 Provider Model: Introduction to the Provider Model. Stránka, kde doporučuji se zastavit a přečíst při svém prvním seznamování se. (Teda pokud jako první nenavštívíte tyto stránky :-).) Když už jsem se v prvním příspěvku zmínil o SiteMap provideru, určitě Vás bude zajímat i jeho implementace v podání Jeff Prosise. Ano vzal jsem si inspiraci a upravil několik věcí, které se mi na tomto provideru nelíbili.

Dále určitě stojí za pozornost dva články od Rob Howard Provider Model Design Pattern and Specification, Part 1 a Provider Design Pattern, Part 2, jež jsou poněkud staršího data, přesto stále aktuální, a já v nich měl inspiraci již pro projekty postavené na .NET 1.1.

Ale vrátím se od pouhého čtení k něčemu, co některým (snad skutečně jen výjimkám) udělá radost. Jsou to Sample Access Providers Starter Kit implementace pro Membership, Role Manager, Profile a Web Parts personalization s využitím Microsoft Access databáze. Dle mého názoru je toto pouze okrajové a nouzové řešení, neboť bych raději použil SQL Server 2005 Express Edition.

A když už jsem u toho kódu, který se dá použít, i když ne tak úplně souvisí s provider patterny v ASP.NET 2.0, nedá mi to abych je nezmínil. Jistě si někteří z Vás oblíbili Enterprise Library. Tato knihovna se již blíží do finálního release i pro .NET Framework 2.0 a usnadní nám práci díky těmto aplikačním blokům:

• Caching Application Block
• Cryptography Application Block
• Logging & Instrumentation Application Block
• Exception Handling Application Block
• Security Application Block
• Data Access Application Block
• Configuration Application Block

Toť pro dnešek vše, další informace budou v průběhu zítřejšího dne ... vzhledem k pracovnímu vytížení, spíše večera.

Součástí instalace ASP.NET 2.0 je několik providerů. Tyto se dělí do několika oblastí, pro které zprostředkovávají rozhraní. Mezi ně patří i rozhraní pro mapu webu, neboli SiteMap Provider. Ovšem, když se podíváte důkladněji po tomto provideru, zjistíte, že co nabízí ve své základní instalaci, je pouze XmlSiteMapProvider.

XmlSiteMapProvider je vhodný v okamžiku, kdy hodláte vytvořit mapu webu pomocí xml souboru. Ovšem jsou situace, kdy toto není plně vhodné. Já osobně dávám přednost raději SQL databázi, ve které je definována struktura stránek. A tak nezbývá než napsat nového providera, a tohoto začlenit do svého projektu.

Začínáme vytvářet vlastní provider - analýza

Celý princip provider patternu je důkladně popsán na těchto stránkách. A důkladněji se mu budu věnovat v dalším příspěvku. Důležité je vědět, že pro náš SiteMap provider můžeme vycházet ze dvou abstraktních výchozích tříd. První z nich SiteMapProvider je skutečnou výchozí třídou, ze které můžeme odvozovat vlastní providery. Ovšem, pokud nechceme psát příliš mnoho kódu, a který vývojář by tomu tak chtěl, můžeme použít druhou abstraktní třídu StaticSiteMapProvider. Tato, také abstraktní, třída implementuje několik metod, které bychom museli stejně napsat a usnadňuje nám tedy množství práce. Zároveň z této třídy vychází také náš MsSqlSiteMapProvider.

Dostáváme se k vlastnímu provideru

Vlastní provider je pak už jenom implementováním několika abstraktních metod. A navržením datové struktury tabulky, ve které budou obsaženy informace o struktuře webu.

Pro návrh databázové tabulky si vezmeme inspiraci z atributů, které můžeme zapsat do xml souboru a rozšíříme je o několik nutných položek. Tabulka se tak bude sestávat z těchto sloupců:

• SMID
- primární klíč tabulky, zároveň slouží jako atribut key objektu SiteMapNode
• SMParentID
- je odkazem na nadřazenou úroveň, např. v rámci tohoto webu je na nulté úrovni název Providers na první úrovni pak seznam všech výchozích providerů.
• NodeOrder
- je pořadí příslušného nodu v dané úrovni. Tento atribut slouží pouze pro seřazení struktury na výstup.
• Title
- je titulek, který se zobrazí uživateli a je mapován na stejně znějící atribut.
• Url
- představuje odkaz na stránku v rámci webu.
• Description
- jak už název napovídá, slouží pro popis odkazu. Pokud je tento popisek vyplněn, zobrazí se jako vyskakovací nápověda po najetí na odkaz.
• Roles
- tento atribut je použit v případě nastavení property atributu SecurityTrimmingEnabled na hodnotu true. A umožňuje řízení oprávnění přístupu k webu.
• ResourceKey
- nebyl by to pořádný web, který by nesloužil pouze pro jednu zemi. Takže toto je možnost, jak i menu lokalizovat.
• Obsolete
- a samozřejmě můj oblíbený sloupec, který používám snad ve všech tabulkách. Nikdy totiž nevíte, jestli nebudete chtít příslušný záznam "schovat" před ostatními a přitom jej ponechat v databázi.

Takže strukturu databáze máme, přejdeme k napsání vlastního provideru. Jelikož jsem se rozhodl použít za výchozí třídu StaticSiteMapProvider, mám již spoustu kódu napsánu a tak mi zbývá implementovat jen několik málo metod.

Hned první je metoda Initialize(string name, NameValueCollection config). Zde doplníme kód pro získání připojovacího řetězce pro připojení k databázi, ve které se nachází výše zmíněná tabulka, pojmenovaná [SiteMap]. Další metodou, jejíž implementaci je nutné dopsat je SiteMapNode BuildSiteMap(), vracející kořenový nod našeho webu, většinou tedy default.aspx. Tato metoda načte strukturu webu z tabulky databáze a vytvoří příslušný strom, tak jak bude zobrazen na straně klienta. A to je vlastně téměř vše co musíme napsat, abychom získali vlastní SiteMapProvider.

Používáme vlastní SiteMapProvider

Napsali jsme vlastní provider, ale jak jej použít? Je to celkem jednoduché, chvilku se budeme zabývat souborem web.config. V jeho sekci přidáme definici pro náš vlastní provider. Ta může vypadat následovně

V připadě, že jsme předtím používali například XmlSiteMapProvider na svých stránkách, máme hotovo a struktura webu se nám rázem, samozřejmě po uložení souboru, bude načítat z nového úložiště. Jestliže začínáme psát nový web, pak musíme pro zobrazení nového menu použít příslušné ovládací prvky. Ale to si nechám zase na příště.

Asi se divíte proč je nadpis takový, jaký jsem zvolil. Je to tak, ten podnět přišel opět z konference VS-NET. Jenže teď měl trošku jinou příchuť, příspěvek jsem četl, ale nepřišlo mi, že bych musel reagovat. Souběh událostí ovšem tomu chtěl a tak jsem se dostal do příjemné restaurace na fotbal - jak jinak než fandit našim proti Norům. Nešel jsem sám, ale s několika kolegy z práce. A tak se stalo, že jsem se potkal s Richardem, bývalým to kolegou mého současného spolupracovníka.

Tak nějak v rámci oslav jsme se v rámci hovoru dostali až k programování a jeho problému. Přestože jsem tvrdil, že to co požaduje jde udělat jednoduše a bez velké námahy, příliš mi nevěřil. A tak jsem se rozhodl, že jej přesvědčím. Jen doufám, že jsem jeho záměr pochopil správně - přeci jen nálada po vítězství nebyla pro analýzu problému vhodná. Raději přejdu k popisu samotného prvku ....

Uživatelský prvek PagerControl

Účelem tohoto prvku je vykreslit na stránku dle zadaných vlastností řadu LinkButtonů, které představují počet datových stránek a na základě kliknutí na některý z nich, předají zpracovávající stránce o tomto informaci. Veškeré důležité informace jsou uchovány ve ViewState tohoto prvku.

Rozhraní tohoto prvku tedy tvoří:

Vlastnosti:
• TotalPages: počet datových stránek, které se mají zobrazit
• CurrentPage: aktuální datová stránka
• PagingType: možnost výběru stánkování, na výběr je mezi seznamem všech datových stránek, nebo možnost procházet vpřed a vzad

Událost:
• PageSelected: vyvolaná v okamžiku, kdy dojde ke změně datové stránky kliknutím na LinkButton

Jak je vidět z popisu rozhraní, jedná se o poměrně jednoduchý prvek, který je možné dále rozšířit o případné další vlastnosti. Co mě napadá je přidání vlastností pro hezčí zobrazení prvku na stránce. To ovšem považuji za poměrně jednoduchý krok a důležitější bylo ukázat, jak zajistit funkcionalitu takového prvku.

Snad Ti tedy, Richarde, přinese prvek PagerControl vyřešení problému a udělá radost stejně velkou, jakou udělali čeští fotbalisté radost fotbalovému národu [no dobrá, tak velká asi nebude, ale přeci jen ...].

Když jsem se někdy v únoru letošního roku prvně dozvěděl o AJAXu (nejspíš z nějakého blogu), tak jsem se okamžitě dostal na stránky Michaela Schwarze a na jeho snad prvním(?) AJAX chatu jsem s ním prohodil několik slov o této technologii. Od té doby se toho v této oblasti událo mnoho. Ale teď se nechci příliš přeceňovat či chválit, nebylo to mé první setkání s touto technologií.

Již když jsem nastoupil do SinTe a podílel se na jednom z prvních větších projektů, intranetovém řešení podnikového informačního systému pro Sintex, použil jsem téměř nevědomky AJAX. Je to už poměrně dlouho, celé čtyři roku tomu jsou, a to byl .NET ještě v plenkách, tedy vlastně v jeho druhé Beta verzi. Takže celé řešení bylo postaveno na ASP 3.0. Jak už jsem říkal výše, bylo to intranetové řešení, a tak jsme měli možnost definovat, že systém bude využívat pouze IE 5.5 případně vyšší. A nebyl tak problém využívat Microsoft.XMLHTTP.

A jak to všechno souvisí s AJAX? Snažili jsme se o co nejsnadnější ovládání a tak některé stránky obsahují kód, velice blízký současnému asynchronními zpracování pomocí XmlHttpRequestu. Ano, využívali jsme k přenosu dat mezi serverem a klientem XML a pro zobrazování přijatých dat pak XSL. Řešení se mě osobně velice zalíbilo, a tak jsem jej využil ještě jednou (v ASP) a to v několika modulech intranetového informačního firemního systému InFis.

Přišel .NET a něco málo se změnilo

Po příchodu .NETu se mé myšlení přesunulo úplně jiným směrem. Ale poznal jsem, že dobré věci se neopouštějí a jejich čas se vrací. A tak teprve před nějakým rokem a půl jsem se vrátil k asynchronnímu zpracování. A opět to byl intranetový informační systém, který mě k tomu přivedl. Požadavky na data, jejich objem a hlavně interaktivita stránek, mě donutili přemýšlet jak to vše skloubit. Vzpoměl jsem si tak na, v té době již nepodporovaný soubor, webservice.htc. A proč jsem použil právě webové služby? Odpověď je celkem prostá, neboť celý systém byl navržen na použití se servisní vrstvou, jen její volání bylo v rámci formulářů. Tudíž přepsání na webové metody nestálo příliš úsilí, zato snadnost ovládání a zadávání dat se zjednodušilo mnohonásobně.

Když nyní porovnám přenášené objemy dat pro některé opravdu komplexní stránky, nedovedu si představit, že by tato data byla navíc zapouzdřena také jejich grafickou prezentací. Tato vizualizace dat se, jak jsem zmínil výše, odehrává na straně klienta a šetří tak, nejen, uživatelův čas.

A co dál ... Atlas

Celkem se těším, až přijde ostrá verze Atlasu. Postavená taktéž na webových službách, ovšem s webcontroly, které by měli ještě více usnadnit vývoj webových aplikací. Pěkné vysvětlení jak vše zapadá do sebe má, jak jinak, Nikhil Kothari.

Současné aplikace se určitě jenom tak přepisovat nebudou, jenom z důvodu, aby využívali poslední technologie. Vlastně ani nemusí, jak se zdá, podařilo se mi udržet krok a vykročit podobným ne-li stejným směrem, kterým se vývoj bude dále ubírat. Musím říci, že mě velice potěšilo toto zjištění, a i když jsem se o něm rozhodl napsat až nyní, není to pro mě taková neznámá, jak se dalo v úvodu tohoto příspěvku předpokládat.

Začínalo právě léto, když jsem se začal účastnit nového projektu. Stejně jako vysvitlo sluníčko a ohřálo vzduch, i mě se ukázaly nové možnosti. Projekt na který jsem se těšil a chtěl ovlivnit jeho výsledné zpracování. A to i přesto, že veškeré zadání přicházelo z poměrně vzdálené a malé země, z Islandu.

Vlastně tímto projektem začalo (v tu chvíli zatím jen pro mě) partnerství mezi společností SinTe a CreditInfo Group. Toto partnerství jistě přinese nové příležitosti nejen firmě, ale také mě :-)

Proč mít rád NHibernate?!

S příchodem do nového projektu jsem se musel přizpůsobit zvyklostem a novému frameworku, na kterém byla postavena současná řešení CIGu. Pro přístup k datům byl použit NHibernate. Jelikož mám jistou averzi proti O/R mapovacím frameworkům, byl jsem nedůvěřivý i zde. Je pravdou, že vytvořit tak rychle přístup k datům je fajn. Ovšem tato výhoda se občas negativně promítla do situací, které se tak musely řešit možná složitěji než jsem čekal. Nebylo to ovšem jen o NHibernate. Takže se postupně vytvořil mapovací modul pro externí data s přístupy pomocí webových služeb jakož i služby pro dávkové zpracování dat. Potrápil jsem se s XSD schématy podobně jako Jónas. Abychom se dostali až do fáze testování a vylaďování výkonu všech modulů.

Léto bylo také ve znamení sportu

Celé léto jsem si užíval nejen prací, ale také sportem. Pokud to jen šlo, byl jsem na písku a hrál beachvolejbal. Lehce sportovně laděná byla i naše dovolená. Tu jsme strávili na chorvatských ostrovech, na krásné lodi Aloha, která nás dopravovala z jednoho ostrova na druhý. Scénář byl jasný, po probuzení a snídani jsme sedli na kola a vyjeli jsme po ostrově směrem k dalšímu přístavu. Tam už na nás čekala přesunuvší se Aloha. Většinou po příjezdu do přistavu jsme stihli ještě projít městečko a pak už hurá na palubu pro výbornou večeři. Po večeři jsme pak ochutnali tamní víno - zde patří pochvala pro české víno, které je určitě lahodnější než chorvatské.

A co poslední dny?

Rozrůstáme se, a tak bylo potřeba najít větší prostory. Naše vedení se nakonec rozhodlo pro nově zrekonstruovaný Office Park Meteor na Sokolovské ulici. Stěhování do nových pěkných prostor proběhlo včera (pátek) a pro oddělení vývoje byl vybrán největší prostor typu "open space". Jen je škoda, že moje tříměsíční alokace na CIG projektu a tudíž nepřítomnost v SinTe zapříčinily, že jsem nemohl být přítomen při rozdělování míst. Zatím můžu posoudit podle prvního dojmu, ale na oblíbený klid a přitom kontakt s ostatními v týmu to nevypadá (a to ať už na "přiděleném" místě, a nebo nabízeném "odloučeném"). Snad si zvyknu.

Dny a týdny následující

Už jen samá pozitiva, dalo by se říci. Ale to se teprve uvidí. Jen doufám, že bude více času přispívat do tohoto logu. A to nejen díky tomu, že přijde nový .NET Framework 2.0, ale i díky novým projektům, které mi poskytnou nové příležitosti a záludnosti, se kterými se určitě podělím.