Ein den meisten (MS) Entwicklern unbekanntes HTML Tag ist das <optgroup> Element. Unter Umständen liegt dies daran, dass das Element in ASP.NET nicht direkt durch ein Server Control unterstützt wird.
Das <optgroup> Element kann innerhalb von Dropdown Listen verwendet werden, um die einzelnen Optionen zu gliedern. So lässt sich einfach eine zweistufige Hierarchie darstellen, HTML konform.

Das Markup für eine solche Dropdown Liste wird wie folgt definiert:

<select id="GameConsole" name="GameConsole">
 <option value="">Select your favorite...</option>
 <optgroup label="Microsoft">
   <option value="1">XBox</option>
   <option value="2">XBox 360</option>
 </optgroup>
 <optgroup label="Nintendo">
   <option value="3">Wii</option>
   <option value="4">Gameboy</option>
 </optgroup>
 <optgroup label="Sega">
   <option value="5">Dreamcast</option>
 </optgroup>
 <optgroup label="Sony">
   <option value="6">Playstation</option>
   <option value="7">Playstation 2</option>
   <option value="8">Playstation 3</option>
   <option value="9">PSP</option>
 </optgroup>
</select>

Ich habe eine neue HTML Helper Komponente DropDownListEx in meine Library etcetera.Mvc aufgenommen. Diese unterstützt das eben beschriebene Tag.

etcetera.Mvc DropDownListEx

Dazu habe ich auch eine Hilfsklasse OptionGroupSelectList erstellt, welche eine ähnliche Aufgabe wie die SelectList erfüllt. Die DropDownListEx erwartet im Konstruktor eine solche OptionGroupSelectList. Diese kann vom Controller wie folgt erstellt werden:

GameConsoleViewModel gcvm = new GameConsoleViewModel();
gcvm.GameConsoles = new OptionGroupSelectList<GameConsole>(gameConsoles,
                                                           x => x.Id,
                                                           x => x.Name,
                                                           x => x.Manufacturer.Name);
ViewData.Model = gcvm;

Die drei Lambda Expressions geben die jeweiligen Properties des Aufzählungstyps für das Wert und Namensfeld der Optionen, sowie das Label der Option Group an.

Im View kann der HTML Helper wie folgt aufgerufen werden:

<%= Html.DropDownListEx("GameConsole", Model.GameConsoles, "Select your favorite...") %>

Ich habe noch keinen Release erstellt, die Komponente ist bislang nur als Source Code verfügbar. Ich werde aber bald einen Release erstellen, welcher auch noch weitere Komponenten enthalten wird.

Ich mag das ASP.NET MVC Framework. Wenn ich die Wahl habe, ziehe ich ein MVC Projekt mittlerweile einem WebForms basierten vor. Die offene Architektur, Flexibilität, Testbarkeit und vor allem die Erweiterbarkeit machen es zu einer Freude Webprojekte zu entwickeln.
Wer mit dem MVC Framework beginnt, wird unweigerlich auf das MvcContrib Projekt stossen. Dieses erweitert das Framework an allen Ecken und Enden.
Gerade zu Beginn wird man die ASP.NET Server Controls vermissen. Die mitgelieferten HTML Helper sind zwar sehr komfortabel, decken aber nur das allernötigste ab. Unterstützung für komplexere GUI Elemente wie ein Grid sucht man vergebens.
Das MvcContrib Projekt enthält nebst vielen nützlichen Dingen wie alternativen ViewEngines, Controller Factories und Routing Unterstützung auch einen grossen Satz HTML Helper. Die mächtigste UI Komponente ist in meinen Augen das Grid.

In meinen MVC Projekten habe ich nach anfänglichen Rumspielen mit jQuery Plugins für tabellarische Daten ausschliesslich das MvcContrib Grid verwendet, habe aber bald begonnen, dieses so zu erweitern, dass auch AJAX basiertes Paging und ein Sortieren der Spalten in einem HTML Helper gekapselt wurden.
Das ganze hat sich zu einer kleinen Library gemausert, die ich nun auf CodePlex als Open Source Projekt veröffentlicht habe. Das Projekt nennt sich etcetera.Mvc und ist in einer ersten Version 0.1 verfügbar.

Momentan sind drei UI Komponenten enthalten:

Grid

etcetera.Mvc Grid

Das Grid basiert auf demjenigen von MvcContrib. Dazu gehört eine separate und flexibel konfigurierbare Toolbar, welche für das Paging eingesetzt werden kann. Das Grid verwendet den selben Syntax wie MvcContrib undfügt folgendes hinzu:

• Effizientes asynchrones Paging via AJAX ohne eine einzige Zeile eigenem JavaScript
• Falls der Client kein JavaScript unterstützt, werden regulare Seiten Requests ausgeführt.
• Sortierbare Spalten
• Optionaler Grid Header welcher das Grid ein- und ausfahren kann
• Toolbar für das Paging, mit Anzeige und direkter Wahl der Seitennummer
• Die Toolbar kann einfach und beliebig auch mit eigenen Buttons erweitert werden
• Konfigurierbarer Export der Grid Daten nach Excel
• Alle Labels und Tooltips können selber definiert werden

Das Grid enthält ein jQuery Plugin, die Beispiel Icons und Stylesheets des Screenshots.

Kalender

etcetera.Mvc Calendar

Der Kalender zeigt eine Monatsansicht und unterstützt die Anzeige von Einträgen wie Meetings. Die Kalender Datenstrukturen sind komplett unabhängig von eigenen Projekten. Der Kalender unterstützt folgende Einstellungen:

• Den Wochentag, an dem die Woche beginnt. In den USA ist dies z.B. der Sonntag.
• Anzeige der Tage des Vor- und Folgemonats
• Highlighting des aktuellen Tags
• Komplette Kontrolle über die Links zu Einträgen oder Daten

Wie die anderen UI Komponenten lässt sich das Aussehen komplett über Stylesheets definieren.

Progressbar

etcetera.Mvc Progressbar

Die Progressbar ist ein sehr simples Element. Ich habe es hauptsächlich dafür benötigt, um die Progressbar von jQuery-UI zu ersetzen.

Weitere Komponenten und Framework Erweiterungen werden folgen.

Wie ich bereits geschrieben habe, bin ich in den Vorbereitungen, um kleines Projekt als Open Source auf CodePlex, dem Open Source Portal von Microsoft, zu veröffentlichen. Dabei ist auch die Wahl der Lizenz ein Thema. Die CodePlex Verwaltung macht es einem hier sehr einfach, es sind schon diverse Lizenztexte vorbereitet, aus welchen man nur einen auswählen kann.

Auswahl der Lizenzen bei CodePlex

Aber welchen? Und in welchen Punkten unterscheiden sich die einzelnen Lizenzen? Eine kurze Recherche brachte etwas Licht in dieses mir bislang unbekannte Gebiet.
Die folgende Matrix zeigt die verschiedenen Lizenzen und die Punkte, in denen sie sich unterscheiden:

Open Source Lizenz Matrix

Allen Lizenzen gemeinsam ist, dass die Lizenz immer mitverbreitet werden muss, und dass von einer Software abgeleitete Arbeiten verkauft werden dürfen. Die einzelnen Lizenzen besitzen noch folgende Punkte, welche sie von anderen unterschieden.

Apache License 2.0

Die Apache Lizenz stellt sicher, dass die Software frei verfübar ist, und dass der Name der Apache Foundation nicht für das eigene Produkt verwendet werden kann. Weiter müssen Änderungen an der Software als Quelltexte veröffentlicht werden.

New BSD License

Die New BSD License ist wie die MIT License nicht allzu restriktiv, ausser dass die Namen der Kontributoren nicht für abgeleitete Software verwendet werden dürfen.

GNU General Public License (GPL)

Die GPL ist in einem Punkt restriktiv, was auch bereits zu vielen Diskussionen in der Open Source Szene geführt hat. Jede Software, welche eine GPL lizenzierte Komponente verwendet, muss ebenfalls unter der GPL vertrieben werden.

GNU Library General Public License (LGPL)

Die LGPL ist eine Version der GPL, welche sich besonders für Software Komponenten eignet. Eine Software, die eine LGPL Komponente verwendet, kann eine andere Lizenz verwenden.

MIT License

Die MIT License ist die einfachste und am wengsten restriktive Open Source Lizenz. Sie verfügt nur über zwei Teile. Der erste Teil gestattet es jedem, die MIT lizenzierte Software frei zu nutzen, zu vertreiben oder gar verkaufen (immer aber mit Quellcode). Der zweite Lizenzteil stellt schliesst eine Garantie der Software aus.

Mozilla Public License

Die MPL wird vorwiegend von der Mozilla Corporation für ihre Software verwendet.

Microsoft Public License (Ms-PL)

Die Microsoft Public License ist ähnlich wenig restriktiv wie die BSD oder MIT Lizenzen. Einzige Ausnahmen sind das Verbot der Verwendung des Namens, Logos oder von geschützten Marken (Trademark) des Lizenzgebers, sowie die freie Anwendung von Patenten, welche innerhalb der Software des Lizenzgeber verwendet werden.

Microsoft Reciprocal License (Ms-RL)

Diese Lizenz ist der Ms-Pl sehr ähnlich. Der einzige Unterschied besteht darin, dass wenn irgendwelche Dateien einer Ms-RL lizenzierten Software in eigenen Lösungen verwendet werden, diese Dateien in Quellform und mit einer Kopie der Ms-RL angeboten werden müssen.

Warnung: Für die obigen Informationen kann ich keinerlei Garantie übernehmen, die Angaben basieren auf meiner persönlichen Interpretation der Lizenztexte. Lesen Sie die entsprechenden Lizenzen gut durch, bevor Sie sich für eine entscheiden. Für juristische Beratung in diesen Belangen verweise ich Sie gerne an meinen geschätzten Partner affolter.net.

Ich bin momentan in den Vorbereitungen um eine kleine Library auf CodePlex zu publizieren. Ich will auf der Projektseite nebst dem Source Code, den man ja einfach via Subversion Client hochladen kann, auch binäre Releases zum Download anbieten.

So ein Release von meinem kleinen Projekt besteht aber immerhin aus einigen Files. Nebst dem eigentlichen Assembly wären da noch Bilddateien, Stylesheets, JavaScripts und natürlich auch die notwendigen externen Libraries, die benötigt werden. Nun wäre es doch sehr mühsam, für jeden Release alle diese Dateien immer wieder einheitlich und genau gleich zusammenzukopieren. Zum Glück lässt sich dies relativ einfach mit einer kleinen Erweiterung des Visual Studio Projektfiles erreichen.

Die Visual Studio Projektdatei ist sogar schon dafür vorbereitet. Am Ende jeder .csproj Datei (wahrscheinlich in ähnlicher Form auch bei .vbproj Files) findet man folgenden Kommentar:

<!-- To modify your build process, add your task inside one of the targets below and uncomment it.
 Other similar extension points exist, see Microsoft.Common.targets.
 <Target Name="BeforeBuild">
 </Target>
 <Target Name="AfterBuild">
 </Target>
 -->

Microsoft hat also zwei definierte Targets vorgesehen, welche für eigene Erweiterungen genutzt werden können. Wenn nun der Build beendet wird, wird das Target “AfterBuild” ausgeführt. Hier kann man also durch eigene Tasks wiederkehrende Aufgaben automatisieren lassen. Das Zusammenkopieren meiner Dateien in einen Release Ordner und Anlegen einer Zip Datei wird so zum Kinderspiel:

<PropertyGroup>
  <MSBuildCommunityTasksPath>$(MSBuildProjectDirectory)\..\..\lib\MSBuild.Community.Tasks</MSBuildCommunityTasksPath>
  <ReleasePath>$(MSBuildProjectDirectory)\..\..\Release</ReleasePath>
</PropertyGroup>

<Import Project="$(MSBuildCommunityTasksPath)\MSBuild.Community.Tasks.Targets" />

<Target Name="AfterBuild" DependsOnTargets="ClearRelease" Condition="'$(Configuration)' == 'Release'">
  <!-- Create an item collection of assemblies and other artifacts produced by the build -->
  <ItemGroup>
    <EtcDll Include="$(MSBuildProjectDirectory)\bin\Release\etcetera.Mvc.dll" />
    <MvcContrib Include="$(MSBuildProjectDirectory)\bin\Release\mvccontrib.dll" />
    <Css Include="$(MSBuildProjectDirectory)\UI\css\**\*.*" />
    <Images Include="$(MSBuildProjectDirectory)\UI\images\**\*.*" />
    <Scripts Include="$(MSBuildProjectDirectory)\UI\scripts\**\*.*" />
    <ZipFiles Include="$(MSBuildProjectDirectory)\Release\**\*.*" />
  </ItemGroup>

  <Copy SourceFiles="@(EtcDll)" DestinationFolder="$(ReleasePath)" />
  <Copy SourceFiles="@(MvcContrib)" DestinationFolder="$(ReleasePath)\Dependencies" />
  <Copy SourceFiles="@(Css)" DestinationFolder="$(ReleasePath)\css" />
  <Copy SourceFiles="@(Images)" DestinationFolder="$(ReleasePath)\images\etcetera" />
  <Copy SourceFiles="@(Scripts)" DestinationFolder="$(ReleasePath)\scripts" />

  <!-- Create a release zip file using the MSBuild Community tasks -->
  <ItemGroup>
    <ZipFiles Include="$(ReleasePath)\**\*.*" />
  </ItemGroup>
  <Zip Files="@(ZipFiles)" ZipFileName="$(ReleasePath)\etcetera.Mvc.zip" WorkingDirectory="$(ReleasePath)" />
  <Message Text="Copied all etcetera.Mvc files to folder $(MSBuildProjectDirectory)\Release" Importance="high" />
</Target>

<Target Name="ClearRelease">
  <ItemGroup>
    <OldReleaseFiles Include="$(ReleasePath)\**\*.*" />
  </ItemGroup>
  <Message Text="Clearing files in folder $(ReleasePath)" Importance="high" />
  <Delete Files="@(OldReleaseFiles)" />
</Target>

Das Zusammenstellen des Releases soll aber nur stattfinden, wenn auch die “Release” Konfiguration ausgewählt ist. Dafür kann das Target eine Condition auswerten. Zuvor sollen aber die Files des letzten Builds gelöscht werden, deshalb wird das “AfterBuild” Target vom “ClearRelease” Target abhängig gemacht. Somit wird dieses zuerst ausgeführt.

Zusätzlich zu den von Microsoft bereitgestellten Tasks (wie Copy, Delete etc.) lassen sich auch eigene oder Tasks von Dritten verwenden. Mein Beispiel verwendet den Zip Task der äusserst praktischen MSBuild Community Tasks.

Wenn ein Text im Output Fenster von Visual Studio ausgegeben werden soll, muss das “Importance” Attribut des Message Tasks auf “high” gesetzt werden.

Wenn die Projekt Datei derart angepasst wird, kann es sein, dass Visual Studio beim Laden des Projekts warnt, dass die Projektdatei erweitert wurde.