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

Ráno jsem si přečetl příspěvek Tomáše o jeho problémech s MS SQL Server Management Studiem pro SQL Server 2008.

Ač jsem reagoval již v komentáři, neodpustím si ještě několik poznámek, které si zaslouží maličko více rozvést a najít řešení, které z Management Studia vytvoří plnohodnotný nástroj pro databázového administrátora.

Výroky a postesky nad tímto problémem:

Nepodařilo se mi ho přesvědčit, aby přesunulo sloupce v tabulce tak jak potřebuji. Po této operaci, kterou Designer tabulky viditelně umí, dojde při uložení změn v tabulce k chybě, která se hlásí jako "Název změněné tabulky".

obdobně jako tímto:

Velmi často při uložení změn v tabulce dojde k chybě ukládání. Netuším o jakou chybu jde, protože se hlásí stejně jako chyba předchozí.

jsou způsobeny pouze tím, jak se Management studio chová k ukládání databázových objektů. Tyto "problémy" jsou způsobeny tím, že se Management studio snaží při takovýchto změnách provést drop objektu a jeho znovuvytvoření, tak jak je popsáno na tomto místě. Je zde i návod, jak docílit změny a být, takříkajíc, spokojený, postačující je odškrnout volbu v menu Tools->Options->Designers->Table and Database designers->Prevent saving changes that require table re-creation.

Na Subversion je ovšem lepší ukládat textové soubory a to rozhodně záloha MS SQL serverů není. Textový soubor si tedy vyrábím v Management Studiu pomocí Generate Scripts. Jsem rád, že to Microsoft umí. Bohužel průvodce neumím zkrátit a nastavené volby si nepamatuje. Je to velmi zdlouhavé, zdržující a protivé.

Jak jsem se již zmínil v komentáři pod článkem, toto je asi lepší vyřešit pomocí Powershell scriptu. Samozřejmě, nesmí se zapomenout doinstalovat SQL Server PowerShell snapin pomocí příkazu sqlps. Poté je již možné vyscriptovat jakýkoli databázový objekt. Pro tabulky je to například příkazem:

PS SQLSERVER:\> sl SQLSERVER:\SQL\[server]\[instance]\Databases\[catalog]\Tables; gci| %{$_.Script()} > c:\tables.txt

Kde je potřeba zaměnit správné hodnoty za placeholdry [server], [instance] - zadat název default v případě, že se jedná o default instanci a samozřejmě [catalog] je název samotné databáze.

Myslím, že jednodušeji to snad jít ani nemůže. ;-)

Před pár minutami se mi povedlo uveřejnit na serveru CodePlex.com první alpha release verzi asp.net MVC prvků.

Fieldset

V tomto úvodním release je zahrnut pouze prvek Fieldset, který je inspirován prvekem Grid z projektu MVCContrib. Tento prvek jsem původně vytvořil pro webové stránky zpracovávané v soutěži na serveru vbnet.cz. Ona myšlenka takovéhoto prvku, který zabezpečí jednotný vzhled a ucelený přístup k tvorbě formulářů na web stránkách, se mi zalíbil a proto jsem jej rozvedl a maličko vylepšil.

Již nyní mám v hlavě další vylepšení a možný rozvoj. Jsem však přesvědčen, že je takovýto prvek lepší publikovat co nejdříve a inspirovat se názory komunity. Budu proto rád, pokud mi napíšete možná vylepšení nebo připomínky.

Proč simple

V čem by měl být smysl takto vytvořeného prvku před samostatným tvořením vstupního formuláře? Prvním impulzem, k tvotbě tohoto ovládacího prvku pro mě bylo neustálé zapisování HTML kódu, který se pro každý prvek formuláře opakoval. Dalším podnětem pak byla náchylnost k chybám při zápisu. S release verzí asp.net MVC Beta přibyla možnost validací prvků, avšak pro tyto prvky bylo třeba uvést shodný název, jaký je uveden v tzv. ModelState. Vznikla tak potřeba pro každý validovaný prvek tento název zapsat dvakrát, což už vede k možným chybám.

Z těchto důvodů jsem se rozhodl vytvořit takovou formu zápisu, která by vývojáře odstínila od těchto potřeb a nabídla mu přímou a jednoduchou cestu k cíli. Ukázku možného zápisu jsem prezentoval na oficiálních stránkách simple asp.net MVC Controls.

Doufám, že se mi cíl vytvoření jednoduchých prvků pro asp.net MVC podařil a bude na čem stavět pro další verze.

Je to tak, po delším čekání se konečně dostalo na Silverlight 2.0 a jeho oficiální vypuštění na web.

Byť o této horké novince jistě každý ví, neboť se to obdobnými příspěvky na blozích jen hemží, ani já si neodpustím několik málo postřehů. Nejdříve těch formálních:

• ke stažení na stránkách Microsoftu
• v případě, že máte nainstalovánu předchozí Betu, update se provede automaticky
• velikost instalace cca 4.5 MB
• možnosti instalace do prohlížečů IE 7, IE6, Firefox 1.5, Firefox 2 a FireFox 3, pokud používáte systém MAC OS ve verzi 10.4.8 a vyšší na Intelu, tak i pro Safari.
• nepovedlo se mi rozšířit si Chromium - Google chrome

Samozřejmě nesmí chybět nějaké ty informace pro vývojáře. Takže pokud jste příznivci RIA aplikací, určitě vás možnosti, které přináší Silverlight ve verzi 2.0 potěší. Mezi ty základní prvky patří

• ovládací prvky jako jsou DataGrid, ListBox, Slider, ScrollViewer, Calendar a další, které se budou objevovat na stránkách CodePlex (součástí by měl být třeba WrapPanel, DockPanel, ViewBox, Label, Expander, TreeView a další)
• pokud se zabýváte tvorbou WPF aplikací, bude vám blízké skinování a použití templates.
• podpora volání webových služeb - a to jak provázáností na WCF tak také možnost komunikovat přes REST, SOAP nebo standardní HTTP komunikaci
• podporu hned několika programovacích jazyků - takže Silverlight aplikace můžete psát nejen v C# nebo VB.NET, ale také v dynamických jazycích jako je JavaScript nebo IronPython či IronRuby. A nepochybně se najdou i další portace, třeba pro PHP

Co určitě potěší je skutečnost, že se připravují Express nástroje, takže každý si bude moci vyzkoušet jak vytvořit Silverlight aplikaci. A pokud přeci jen nejste tak úplně zastánci MS a oblíbili jste si vývojový nástroj Eclipse, tak můžete vyzkoušet Eclipse for Silverlight.

Pro ty z vás, které jsem nalákal, ještě možnost stažení SDK a v případě, že používáte Expression Blend 2, tak je vydán Service pack.

Přeji příjemnou zábavu při vytváření lepších a hezčích aplikací.

Pomalu se dostáváme do finální části, kdy již máme vše připraveno a stačí nám jednotlivé produkty (knihy) vypublikovat na web.

XSL jako šablona - zavrženo

Jak jsem se již zmínil v prvních krocích, kdy jsem vytvářel doménové objekty a ty naplnil vstupními daty, xsl pro prezentaci dat bylo zavrženo. Přitom by se dalo říct, že jako šablonový systém, kdy na vstupní straně je xml, je toto řešení přímo ideální a též jsem jej v první chvíli doporučoval.

Jenže jak se říká, zákazník je náš pán a já jsem si svoji práci nechtěl ulehčit tím, že bych xsl použil. Přitom jsem chtěl nabídnout takové možnosti, aby bylo jednoduché vkládat statické texty okolo dynamických polí a to vše s možností plně ovlivnit výstupní HTML.

Chvíli jsem nad tím přemýšlel a uvažoval jsem jak něco tak jednoduchého zabezpečit, když v tom mě to napadlo, jednu takovou věc již používám a její implementace nebude náročná. Stejně tak věřím, že by nebylo náročné pro zkušenějšího uživatele znalého HTML syntaxe naučit se i těch několik málo příkazů. Navíc se tím vyvaruji i dalšího strašáka a to je použití PHP, které bylo taktéž zavrženo.

NVelocity

Přesně tak, onou spásnou knihovnou se stala NVelocity a to po úpravách z projektu Castle. Domnívám se totiž, že je to velice jednoduše uchopitelný šablonovací systém, přesně splňující základní potřeby pro publikaci potřebných informací a v případě potřeby též snadno rozšiřitelný.

Jelikož mám tuto knihovnu použitou například na tomto webu, kde si pomocí ní generuji emailové notifikace, nebyl problém ji vzít a použít i v tomto systému.

Právě z tohoto důvodu jsem se také v prvních krocích ujal vytvářet doménový model, protože objekty a především jejich vlastnosti jsou základním předpokladem a pomocí nich se zobrazují získaná data.

Jak tedy potom vypadá vygenerování výstupu z takové šablony je vidět na ukázce níže:

IPathLocatorService pathLocatorService = new DesktopPathLocatorService();
ITemplateProcessor templateProcessor = new NVelocityTemplateProcessor(pathLocatorService);
Hashtable data = new Hashtable();
data["book"] = book;
post.description = templateProcessor.RenderView("description", data);

kdy právě instance třídy Book je předána jako parametr s názvem book do transformační metody a za pomocí definice šablony je vytvořen na výstupu HTML kód.

Šablona

Definování šablony je potom již otázkou vkusu a zručnosti. V mém případě tedy otázkou trošku delší, ale věřím, že pro schopného html kodéra by tato práce nebyla vůbec těžká. Já se rozhodl pro jednoduchý výpis informací a v případě generování description jsem použil následující:

<div class="book">
    <h4>Authors:</h4>
    <ul>
#foreach ($author in $book.Authors)
    <li>$author.FullName</li>
#end
    </ul>
    <dl class="metainfo">
        <dt>ISBN</dt>
        <dd>$book.ISBN</dd>
        <dt>Pages</dt>
        <dd>$book.NumberOfPages</dd>
        <dt>Publication date</dt>
        <dd>$book.PublicationDate.ToString("dd.MM.yyyy")</dd>
    </dl>
</div>

Samozřejmě není nutné, aby výstupem transformace byl HTML kód, ale v tomto případě je to očekávané.

Jak by to probíhalo

Zde již opět přichází na řadu součinnost s případným zadavatelem zakázky. Záleží na tom, zda by měl již připravené HTML šablony, do kterých by se umisťovali jednotlivé atributy nebo by si šablony chtěl tvořit sám. V případě prvním bych nejspíše zasedl a začal jednu šablonu za druhou přepisovat a doplňovat řídící značky. V případě druhém by potom došlo k vysvětlení významu jednotlivých řídících značek a popsání doménového modelu.

Časový odhad

Vzhledem k tomu, že jsem měl připraveno a zaobaleno volání NVelocity v samostatné assembly bylo napojení do systému velice rychlé. Určitě delší čas jsem strávil nad tím, jak vhodně vygenerovat výstup a jaké informace zobrazit a předat do kterého vstupního pole třídy Post - viz napojení na WordPress pomocí XML-RPC. Celkový čas pro tento krok tedy byl 40 minut. Zde musím upozornit, že v případě předání šablon pro Petru by především definice šablon a jejich úprava mohla zabrat nepoměrně delší dobu.

V tuto chvíli by se mohlo zdát, že naše aplikace je hotova. Postačující bude ji jen poskládat a předat k užívání.

Aktualizace dat

Co je však třeba si uvědomit, že toto nemá sloužit jako jednorázové naplnění webu a bude třeba přidávat nové produkty, případně si maličko pohrát s rozvržením a úpravou statických textů, které budou přidávány ke každému produktu.

Je tedy nutné zajistit, aby se nové položky do publikačního systému vložily a položky již jednou vložené pouze aktualizovaly. Pro zajištění tohoto úkolu jsem si vybral lokální datový soubor a využil jsem tak možností SQL Server Compact Edition v. 3.5. Za atributy, které je nutné sledovat jsem si stanovil Id, které je každému příspěvku přiděleno publikačním systémem WordPress a také ASIN, který představuje identifikátor na straně vstupních dat. Dále jsem se rozhodl též ukládat si atribut Title a Publisher a pro informaci též datum vystavení (publikace).

Tyto všechny atributy se mi vešly do jedné tabulky, kterou jsem nadefinoval z prostředí Visual Studio. Pro přístup a manipulaci s daty jsem si potom vybral LINQ to SQL, který dokáže pracovat právě i s touto lokální databází. Podpora v designeru Visual Studia však v současné chvíli chybí a tak je třeba použít nástroje sqlmetal.exe. Mě se v těchto případech osvědčilo použití .bat souboru, který obsahuje následující definice:

"c:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\sqlmetal.exe" /dbml:ArchiveModel.dbml ArchiveDb.sdf
"c:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\sqlmetal.exe" /namespace:Vyzva.Data.Archive /serialization:Unidirectional /context:ArchiveDataContext /language:csharp /pluralize /code:ArchiveModel.cs /map:ArchiveModel.config ArchiveModel.dbml

Samozřejmě můžete vynechat vytvoření mapovacího souboru, osobně však tomu dávám přednost mít jej vygenerovaný znovu a s koncovou .config

Takto vygenerované soubory tedy postačuje vložit do projektu, u .config souboru, kde jsou uloženy mapovací informace nastavit jeho Build type na Embedded resource, tak aby došlo ke vložení souboru do assembly a začít používat DataContext objekt. V tomto případě, kdy se negenerují atributy nad třídou a vlastnotmi, je třeba při vytváření instance DataContextu předat též odkaz na mapovací schéma a connection string.

if (_mappingSource == null) {
  using (Stream st = Assembly.GetExecutingAssembly().GetManifestResourceStream("Vyzva.Data.Archive.ArchiveModel.config")) {
    _mappingSource = XmlMappingSource.FromStream(st);
  }
}
string conn = ConfigurationManager.ConnectionStrings["DbMainConn"].ConnectionString;
context = new ArchivDataContext(conn, _mappingSource);

Proměnnou _mappingSource mám v tomto případě definovanou v mé Factory třídě jako statickou, neboť není nutné při každém požadavku na DataContext vytvářet a parsovat znovu mapovací schéma.

Tímto mám zaručenu základní funkcionalitu a umožněnu práci s lokální databází.

Jak by to probíhalo

Ani tento krok se zdá, že by nemusel být učiněn v součinnosti s Petřinými požadavky. Co by však stálo za úvahu je definovat si seznam atributů, které budou v této lokální databázi uchovávány a případně další požadavky. Docela dobře si dokáži představit, že by mohl být učiněn požadavek na změnu kategorie, případně její hromadné doplnění k vybraným produktům, případně jiná úprava, která nelze zajistit v exportu xml souboru.

Časový odhad

Definice struktury databáze, vygenerování souborů pomocí sqlmetal.exe a práce s tím spojené zabrali přibližně 30 minut. Ani zde, obdobně jako v předchozím kroku se nedají očekávat nějaká větší časová zdržení.

Pro toho, kdo si píše svůj blog a používá k tomu některý z offline klientů, jako třeba Windows Live Writer tomu nemůže být cizí, že každý rozumný publikační systém má svoje API rozhraní.

Publikační API rozhraní

Většina API rozhraní, která se v současné době používají u publikačních systémů je založena na XML-RPC volání. Těchto API je definováno hned několik a není výjimkou, že se i vzájemně doplňují. Mezi ty známější tak patří:

• blogger API
• MovableType API
• MetaWeblog API
• a samozřejmě, své API má i WordPress, který rozšiřuje možnosti MetaWeblog API o definici svých metod

XML-RPC v .net

.net framework neobsahuje ve svých assembly třídu, která by umožňovala volání pomocí specifikace XML-RPC. To ovšem nevadí v případě, že znáte knihovnu XML-RPC.net. Tato knihovna umožňuje velice elegantně a rychle vytvořit nejen klienta, ale také server pro vzdálená volání.

V mém případě bylo plně dostačující vytvoření klienta služby a napojení se na vytvořený účet. A že vytvoření klienta je velice jednoduché může demonstrovat následující postup.

Zároveň se stažením knihovny získáváte i zdrojové kódy a to nejen pro samotnou assembly, ale také s definovanými interface pro výše zmíněné publikační API a to i s definicí struktur parametrů.

Po nareferencování knihovny CookComputing.XmlRpcV2.dll jsem tak do projektu přidal i definici interface pro MetaWeblog API a rozšíril jsem jej o implementaci interface IXmlRpcProxy, tak abych mohl vytvořit proxy klienta. Jelikož jsem však potřeboval ještě vytvářet nové kategorie, bylo potřebné doplnit definici metody pro vytvoření nové kategorie. Na stránkách WordPressu jsem v dokumentaci pro vývojáře zjistil, jaký předpis má takové volání a doplnil strukturu a interface metody.

[XmlRpcMethod("wp.newCategory", Description = "Create a new category.")]
object newCategory(string blogid, string username, string password, Category category);

public struct Category
{
  public string name;
  public string slug;
  public int parent_id;
  public string description;
}

Poté již stačí jen vytvořit instanci proxy třídy, a nastavit ji správně Url adresu na servisní stranu publikačního systému. Tím jsme hotovy a můžeme volat vzdálené metody a publikovat tak naše produkty, v mém případě knihy.

IMetaWeblog proxy = XmlRpcProxyGen.Create<IMetaWeblog>();
proxy.Url = URL;
// zde již následuje volání metod nad proxy

Jak by to probíhalo

Tento krok je plně v mé režii. Co vás případně může zaskočit a co je dobré vědět, že jednotlivá volání je možné trasovat. Což pomohlo i mě, kdy definice pro kategorie nebyla přesná a bylo ji třeba upravit dle skutečného stavu, který posílal nainstalovaný WordPress. Jak zajistit možnost odladit jednotlivá volání:

RequestResponseLogger logger = new RequestResponseLogger();
logger.Attach(proxy);

Poté bude již veškerá komunikace logována do samostatných souborů.

Časový odhad

V případě že víte, kam "sáhnout" a nemusíte znovu vynalézat kolo, potom je zprovoznění XML-RPC volání velice jednoduché a rychlé. Mě proklikání se k dokumentaci WordPressu pro jeho rozšířené API, dodefinování metody a odladění volání zabralo asi 35 minut.