Das Kopieren von Dokumentinhalten von einem Dokument in das Andere ist ein weites und interessantes Thema im Kontext Word2007/2010 und OpenXml SDK. Hierbei können verschiedenste Abhängigkeiten eine große Rolle spielen. Werden beispielsweise Hyperlink beinhaltende Dokumentteilte kopiert, ist die Überraschung groß. Der Link verweist unter Umständen nicht nur ins Nirvana, er ist selbst vollständig dorthin gewandert. Warum das so ist und was man dagegen machen kann, möchte ich am Beispiel des Kopierens von Inhalten aus einem MainDocument zeigen.

Hyperlinks werden als eigenständiges Element w:hyperlink zwischen Paragraphen w:p und Runs w:r abgelegt. Alternativ zum w:p kann als parent Element auch häufig ein w:sdtContent, ein ContentControl, vorliegen.

Das wichtigste Attribut eines Hyperlinks ist das Attribut r:id. Dieses verweist auf eine externe Beziehung, die in dem Dokument document.xml.rels in dem Unterordner _rels innerhalb der Package Struktur hinterlegt wird.

Bei dem Attribut w:history handelt es sich um einen OnOffValue, im Prinzip einen Boolschen-Wert, durch den angezeigt wird, ob diesem Link bereits gefolgt wurde.

Öffne ich nun dasDokument document.xml.rels finde ich unter der ID 4 den folgenden Eintrag.

<Relationship
    Id="rId4"
    Type=”http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink”
    Target=”http://jcselke.blogspot.com“
    TargetMode="External" />

Damit ist auch schon geklärt, weshalb Hyperlinks verschwinden. Sie werden also als Externe Beziehung abgelegt, in der die Ziel URL des Hyperlinks hinterlegt ist. Diese werden natürlich nicht durch einfaches Kopieren von Inhalten aus dem Dokument übernommen und gehen daher verloren.

Gut, das bloße Kopieren der Inhalte reicht also nicht aus. Was kann aber getan werden? Eine Lösung kann es sein, durch alle HyperlinkRelationships des Mainparts zu iterieren und diese Stück für Stück in das Zieldokument zu übertragen. Dazu werden Ausgangs- und Zieldokument geöffnet und die Inhalte, in diesem Fall durch Zuweisen des InnerXml, kopiert.

public void ImportContent()
{
    using (var package = WordprocessingDocument.Open("c:\\test\\hyperlink.docx", true))
    {
        var mainDocumentPartSource = package.MainDocumentPart;
        var documentSource = mainDocumentPartSource.Document;
        using (var packageTarget = WordprocessingDocument.Open("c:\\test\\hyperlink_target.docx", true))
        {
            var mainDocumentPartTarget = packageTarget.MainDocumentPart;
            mainDocumentPartTarget.Document.InnerXml = documentSource.InnerXml;
            this.TransferHyperlinks(mainDocumentPartSource, mainDocumentPartTarget);
            mainDocumentPartTarget.Document.Save();
        }
    }
}

Im Anschluss wird in der Methode TransferHyperlinks() eine neue HyperlinkRelationship erzeugt und die alten Werte des zu kopierenden Hyperlinks werden übernommen. Dann wird im Zieldokument das Hyperlink anhand der bisherigen Id identifiziert und die alte Id durch die der neuen HyperlinkRelationship ersetzt.

private void TransferHyperlinks(OpenXmlPartContainer openXmlPartContainer, MainDocumentPart mainDocumentPartTarget)
{
    foreach (var hyperlinkRel in openXmlPartContainer.HyperlinkRelationships)
    {
        var newHyperLinkRel = mainDocumentPartTarget.AddHyperlinkRelationship(hyperlinkRel.Uri, hyperlinkRel.IsExternal);
        var relationship = hyperlinkRel;
        var importedHyperlink = mainDocumentPartTarget
            .Document.Descendants<Hyperlink>()
            .Where(x => x.Id == relationship.Id).First();
        importedHyperlink.Id = newHyperLinkRel.Id;
    }
}

So lässt sich natürlich auch mit allen anderen Parts verfahren, die Hyperlinks enthalten können. Da wären vor allem aber nicht ausschließlich Header- und FooterParts zu nennen.

Bewusst, dynamisch und abhängig von der gerade aufgerufenen Seite. Aber dazu später mehr.
Der Meta-Tag robots ist eines der wertvollsten Werkzeuge im Umgang mit Suchmaschinen, wird aber oft, gerade in der deutschen .NET Blogosphäre, sträflich vernachlässigt. Die meisten Blogs verwenden den robots-Tag mit den Werten index, follow in jeder Seite ihres Blog. Viele Blogs verwenden den Tag gar nicht, was den vorherigen Werten gleich kommt. Manches Blog, ich will hier keine Namen nennen, verwendet den Tag gleich mehrfach in einer Seite, erst mit noindex, nofollow und drei Zeilen weiter mit index, follow.
Wie man an diesen Beispielen bereits sehen kann, machen sich die wenigsten Blogbetreiber Gedanken darüber, wie eine Suchmaschine mit dem Inhalt des Blog umgehen soll. Frei nach dem Motto: Google, Yahoo, Bing und wie sie nicht alle heißen, werden es schon richten.
Das tun sie auch, aber bestimmt anders als der Blogbetreiber vielleicht will.

Was macht so ein Spider, oder auch Crawler genannt, mit unseren Blogs?
Er ist hungrig nach Futter und seine Lieblingsspeise ist nun mal Text. Der erste Kontakt mit einem Blog ist meist die Startseite. Hier sind in typischer Manier die letzten Artikel, entweder als Teaser oder manchmal als kompletter Artikel, aufgeführt. Für den Crawler ist das schon eine ganze Menge. Ein hat mehrere Überschriften mit H1 oder H2 Tags und einiges an zugehörigem Text. Wenn sich jetzt im Teaser unter der jeweiligen Überschrift einige Wörter aus eben dieser Überschrift wiederfinden, ist der Crawler schon glücklich. Wird in der Startseite auch noch der robots-Tag mir index, follow verwendet, hat er was er will. Die Startseite landet im Index.
Bei Webseiten, die oftmals sehr viel Wert auf die Startseite legen, mag dieses Verhalten ja gewünscht sein. Ich spreche hier aber von einem Blog. Ich will nicht meine Startseite im Index einer Suchmaschine sehen, sondern meine Artikel.
Nehmen wir an, der Crawler folgt von der Startseite aus dem Link zum Artikel. Er analysiert diesen Artikel und stellt fest, dass Teile des Inhalts bereits im Index vorhanden sind. Was soll ihn nun dazu bewegen diese Artikelseite ebenfalls in den Index mit aufzunehmen? Er hat doch bereits auf der Startseite gefunden was er wollte.

Nun gut, dieses Szenario ist wahrscheinlich stark überzeichnet. In Wirklichkeit sind noch ganz andere Faktoren von Bedeutung. Welche genau weiß ich nicht, denn ich bin kein SEO-Fachmann. Nichtsdestotrotz sagt mir der gesunde Menschenverstand, dass der oben geschilderte Fall sich ziemlich sicher so verhält. Was also tun?

Kurz und knapp, ein radikaler Schnitt. Alle Übersichtsseiten, dazu gehört auch die Startseite, werden mit den Werten noindex, follow im Meta-Tag robots versehen. Klingt schmerzhaft? Ist es für den Moment auch.
Ich habe mich vor ca. drei Monaten getraut diesen Schritt zu tun. Anfangs fiel die Anzahl der indizierten Seiten meines Blog ins Bodenlose. Aber nach und nach zeigte sich der gewünschte Effekt. Mittlerweile sind die verschiedenen Artikel im Index und ranken auf den vorderen Plätzen in den SERPs.
Bei einer Suche zu den Begriffen shared memory .net in Google wird mein Blog auf der ersten Seite gelistet. Wenn diese Suche auf Seiten aus Deutschland begrenzt wird, werden sogar zwei Artikel meines Blog auf der ersten Seite gelistet. Die gleiche Suche bei Bing, listet mich auf die beiden ersten Plätze. Auch mit dem Begriff Web Slice wird mein Blog sowohl bei Google als auch bei Bing auf der ersten Seite gelistet; und das bei 13 Millionen Ergebnissen bei Bing und über 15 Millionen bei Google. Ich bin mit diesem Ergebnis mehr als zufrieden.

Programmtechnisch ist die dynamische Verwendung des robots-Tag nicht schwer umzusetzen.
Da BlogEngine.NET nur einen ContentPlaceHolder in der MasterPage des jeweiligen Theme verwendet, ist der Weg über den Head-Bereich im Markup verbaut. Eine rein codebasierende Variante ist allerdings auch nicht schwerer zu verwirklichen.
Da auf die einzelnen Meta-Tags im Header über einen ControlCollection zugegriffen werden kann, ist der robots-Tag einfach zu finden. Wenn der Meta-Tag gefunden wurde, wird der entsprechende Wert gesetzt. Sollte er nicht gefunden werden, wird der Tag mit dem entsprechenden Wert der ControlCollection hinzugefügt.
In eine Methode verpackt, muss dieser Methode nur noch der gewünschte Wert mitgegeben werden. Um Code-Redundanz zu vermeiden, wird die Methode als statische Methode in einer Hilfsklasse verwendet, der als zweiter Parameter die aktuelle Page-Instanz mitgegeben wird.

public static void AddMetaRobots(string metaContent, Page page)
{
    HtmlMeta tag = null;

    foreach (Control ctrl in page.Header.Controls)
    {
        if (ctrl is HtmlMeta
            && ((HtmlMeta)ctrl).Name.ToLowerInvariant() == "robots")
        {
            tag = (HtmlMeta)ctrl;
            tag.Content = metaContent;
            break;
        }
    }

    if (tag == null)
    {
        var meta = new HtmlMeta();
        meta.Name = "robots";
        meta.Content = metaContent;

        page.Header.Controls.Add(meta);
    }
}

So kann nun einfach in jeder Seite des Blog der richtige Wert für den robots-Tag gesetzt werden. In der Startseite, dem Archiv, im Web Slice Container und der Übersichtsseite für Artikelserien wird der Wert noindex, follow gesetzt. Im Page_Load Ereignis der jeweiligen Seite braucht nur ein Aufruf der obigen Methode zu erfolgen:

BlogUtils.AddMetaRobots("noindex, follow", this.Page);

In den Artikel- und statischen Seiten wird dementsprechend index, follow gesetzt.

BlogUtils.AddMetaRobots("index, follow", base.Page);

Fazit:

Wenn mir als Blogbetreiber von den einschlägigen Suchmaschinen ein Werkzeug zur Steuerung der Suchmaschinenbots zur Verfügung gestellt wird, warum sollte ich es dann nicht nutzen?
In der heutigen Zeit, mit über 180 Millionen Seiten im Internet, ist die Auswahl an Informationen nahezu unüberschaubar. Die Anzahl der SERPs jeder Suchanfrage steigen ständig. Wie soll unter diesen Voraussetzungen ein Artikel meines Blog überhaupt gefunden werden? Wenn ich nichts dafür tue, mit Sicherheit gar nicht.

Ich versuche seit ein paar Tagen die cmd.exe durch die PowerShell abzulösen. Ist so einiges anders, aber dies ist hier nicht das Thema.

Dabei bin ich auf zwei Skripte für die PowerShell gestoßen mit denen man sich a) den Status eine Git-Repositories als Command-Prompt anzeigen lassen kann, sowie b) git ein wenig Tab-Completion beibringt (Befehle und Repositories).

Ich habe es ein wenig refakttorisiert, zusammengefasst, für mich verbessert und auch noch Mercurial Support eingebaut. Es sind meine erste Schritte in der PowerShell, also hab nachsicht ;).

So schaut es aus.

Sofern es in Hg oder Git Repository ist so wird dies in der Titel-Leiste angezeigt, dort ist auch der vollständige Pfad zu sehen, während im Prompt nur der aktuelle Verzeichnisname steht.

Zwischen den Klammern sind dann die Repository Informationen, der Name des aktuellen Branches (in Rot wenn es nicht erfasste Dateien gibt), danach folgen Zahlen die mit +, ~ und - als Vorzeichen. + bedeuten hingefügte Dateien, ~ die geänderten und – gibt die gelöschten Dateien an.

An ein paar Stellen wo bei git und hg die Befehle stehen oder wo Namen von Branches und Remotes gebraucht werden können die mit Tab-Completion durchgetabt werden.

Das ganze ist sicher noch nicht vollständig oder optimal, aber es ist ein Anfang.

Hiermit stelle ich es der Allgemeinheit zu Verfügung und hoffe dass es sich ein wenig weiterentwickelt.

http://github.com/DerAlbertCom/GitHgPowerShell

Um diese zu verwenden einfach die beiden Skripte nach

%USERPROFILE%\My Documents\WindowsPowerShell

kopieren (getestet unter Windows 7). Wenn schon eine profile.ps1 vorhanden ist muss natürlich aufgepasst werden und das ganze Integriert werden.

Viel Spaß damit und forkt fleißig um das ganze zu verbessern ;)

… dass das die RTM des ASP.NET MVC 2.0 für .NET 3.5 und Visual Studio 2008 draußen ist. Das haben andere bereits zur Genüge getan.
(Und wahrscheinlich werden es im Laufe des Tage noch einige mehr tun.)

Hier eine kleine Auswahl:

Alexander Zeitler:
ASP.NET MVC 2 RTM – für .NET Framework 3.5 SP 1 / Visual Studio 2008

Robert Mühsig:
ASP.NET MVC 2 ist RTM (für VS2008)

Scott Guthrie:
ASP.NET MVC 2 Released

Scott Hanselmann:
ASP.NET MVC 2 Released

Phil Haak:
ASP.NET MVC 2 Released!

Shiju Varghese:
ASP.NET MVC 2 RTM Released !

ASP.NET:
http://www.asp.net/mvc/

Außerdem gibt es Unterstützung für die Installation von ASP.NET MVC (per Web Plattform Installer), Anleitungen zur Migration von Version 1 nach Version 2. Die aktuellen Sourcen sind ebenfalls verfügbar unter codeplex.com (siehe obige Links)

In den letzten 5 Einträgen meines Blogs habe ich über verschiedene Möglichkeiten geschrieben Ajax in einer ASP.NET Webforms zu implementieren.

Angefangen mit dem manuellen Weg über das XmlHttpRequest Objekt ging es weiter zu Client Callbacks, dem Updatepanel, dem ASP.NET Ajax Framework sowie jQuery.

Der Fokus meiner Beiträge lag darauf nicht nur einfach zu zeigen welche Möglichkeiten es gibt, sondern zusätzlich auch zu zeigen, welche Datenmengen über die Leitung gehen und ob bzw. welche Teile des ASP.NET Page Life Cycles durchlaufen werden.

Ich hoffe dass ich bei dem ein oder anderen Leser für manchen Aha Effekt sorgen konnte. Zumindest ging es mir persönlich bei der ersten detaillierten Auseinandersetzung mit dem Thema so. Schließlich ist man als ASP.NET Webforms Entwickler traditionell doch eher auf dem Server zu Hause und realisiert vorerst garnicht welchen Overhead Client Callbacks oder das Updatepanel mit sich bringen.

Mein persönliches Fazit ist, dass Updatepanel und Client Callbacks korrekt eingesetzt in einigen Fällen vielleicht berechtigte Alternativen sind, in den meisten Fällen jedoch zum Ajax Framework oder jQuery gegriffen werden sollte.

Meine zurzeit favorisierte Lösung ist - ähnlich wie bei vielen anderen sicherlich auch - der Einsatz von jQuery.

Da mein letztes Beispiel noch ein wenig aufgebläht war, möchte ich an dieser Stelle zwei kurze Tipps geben, die die Arbeit mit jQuery und Ajax ein wenig erleichtern.

Der erste Punkt beschäftigt sich mit der großen Redundanz zwischen den verschiedenen Ajax Aufrufen:

$("#StaticFileLink").click(function(e) {
    e.preventDefault();
    $.ajax({
        type: "POST",
        url: "Teil5.aspx/ReadStaticFile",
        data: "{}",
        contentType: "application/json; charset=utf-8",
        dataType: "json",
        success: function(msg) {
            $("#content").html(msg.d);
        }
    });
});

$("#HelloWorldLink").click(function(e) {
    e.preventDefault();
    $.ajax({
        type: "POST",
        url: "AjaxDemoService.asmx/HelloWorld",
        data: "{}",
        contentType: "application/json; charset=utf-8",
        dataType: "json",
        success: function(msg) {
            $("#content").html(msg.d);
        }
    });
});

$("#EchoLink").click(function(e) {
    e.preventDefault();
    var number = $("#EchoTextBox").val();
    var jsonData = "{ 'number' : '" + number + "'}";
    $.ajax({
        type: "POST",
        url: "AjaxDemoService.asmx/Echo",
        data: jsonData,
        contentType: "application/json; charset=utf-8",
        dataType: "json",
        success: function(msg) {
            $("#content").html(msg.d);
        }
    });
});

Bereits beim ersten Blick auf den Quellcode fällt auf, dass die Werte einiger Parameter statisch zu sein scheinen. So haben folgende Parameter stets einen fixen Wert:

• type
• contentType
• dataType

Außerdem ist zumindest in den ersten beiden Aufrufen auch der Eintrag für data gleich.

Ein Weg um diese Redundanz herum zu kommen wäre eine eigene Funktion, die nur die Variablen Parameter entgegen nimmt.

Standardwerte setzen

Eine andere Alternative besteht darin, Standardwerte für jQuery Ajax Aufrufe zu setzen. Dies sähe dann so aus:

<script type="text/javascript">
    $(document).ready(function() {
        $.ajaxSetup({
            type: "POST",
            data: "{}",
            contentType: "application/json; charset=utf-8",
            dataType: "json"
        });
        $("#StaticFileLink").click(function(e) {
            e.preventDefault();
            $.ajax({
                url: "Teil6.aspx/ReadStaticFile",
                success: function(msg) {
                    $("#content").html(msg.d);
                }
            });
        });

        $("#HelloWorldLink").click(function(e) {
            e.preventDefault();
            $.ajax({
                url: "AjaxDemoService.asmx/HelloWorld",
                success: function(msg) {
                    $("#content").html(msg.d);
                }
            });
        });

        $("#EchoLink").click(function(e) {
            e.preventDefault();
            var number = $("#EchoTextBox").val();
            var jsonData = "{ 'number' : '" + number + "'}";
            $.ajax({
                url: "AjaxDemoService.asmx/Echo",
                data: jsonData,
                success: function(msg) {
                    $("#content").html(msg.d);
                }
            });
        });
    });
</script>

Neu hinzugekommen sind die Zeilen 2 - 8. Diese setzen Standardwerte für alle folgenden Ajax Aufrufe. Diese Variante kann einiges an Code sparen, ist allerdings mit Vorsicht zu genießen. Sollte nämlich zum Beispiel ein jQuery Plug-In auf der Seite genutzt werden, dass auch die $.ajax Funktion nutzt, könnte es zu Seiteneffekten kommen. Konkret wäre dies der Fall, wenn einer der per .ajaxSetup gesetzten Parameter nicht überschrieben, aber mit einem anderen Wert erwartet wäre. Typischerweise würde dies für den contentType oder oder dataType geschehen.

Serialisieren - einfach gemacht

Eine weitere Unschönheit des gezeigten Quellcodes besteht darin, dass die String Variante des in JSON notierten Objekts data von Hand zusammen gebaut wurde. Dies ist natürlich nicht sonderlich schick. Abhilfe schafft die Funktion stringify des Objekts JSON. Einige Browser wie Firefox ab Version 3.5 oder IE ab der Version 8 haben bereits ein eingebautes Objekt JSON. Für alle anderen gibt es unter http://www.json.org/js.html eine JavaScript Library zum Download, die entsprechenden Support nachrüstet, falls noch nicht vorhanden.

Konkret sähe dies dann wie folgt aus:

<scripthttp://feedproxy.google.com src="scripts/json2.js" type="text/javascript"></script>

[ ... ]


$("#EchoLink").click(function(e) {
    e.preventDefault();
    var number = $("#EchoTextBox").val();
    var jsonData = { 'number': number };
    var jsonString = JSON.stringify(jsonData);
    $.ajax({
        url: "AjaxDemoService.asmx/Echo",
        data: jsonString,
        success: function(msg) {
            $("#content").html(msg.d);
        }
    });

Wie man sieht, wird nun in Zeile 9 zuerst ein JavaScript Objekt jsonData in JSON Notation erzeugt. Dies wird anschließend über JSON.stringify in Zeile 10 in einen String konvertiert. Bei diesem konkreten Beispiel mag der Vorteil noch nicht auf der Hand liegen, spätestens bei komplexen Objekten lernt man die Funktion stringify jedoch schnell zu schätzen.

Bei der Recherche zu den Beiträgen dieser Serie bin ich übrigens auf einen sehr gut geschriebenen Eintrag von Roberto Bez gestolpert. Roberto stellt in seinem Blog Post die verschiedenen Varianten kompakt gegenüber. Die Lektüre des Artikels kann ich jedem Ajax interessierten Webforms Entwickler wärmstens empfehlen.

Weiter hat René Drescher-Hackel in einem Kommentar zu meinem letzen Beitrag, dass mit Ajax.NET Professional (AJAX.PRO) eine weitere effiziente Alternative zur Verfügung steht. Ich muss gestehen, dass mir die Existenz dieses Frameworks bis jetzt vollkommen entgangen ist. Gelobe allerdings Besserung und werde es mir gerne ansehen und mein Beispiel damit umsetzen.

Eigentlich altbekannt, trotzdem bin ich gerade mal wieder darauf hereingefallen und schreibe des deshalb hier auf:

Ich wollte in einer ASP.NET Webforms Anwendung ein Servercontrol serverseitig über

meinControl.Visible = false;

ausblenden, um es nach einer Nutzeraktion auf dem Client wieder einzublenden:

$(Id$="MeinControl").show();

Leider funktioniert das allerdings nicht, da ein serverseitiges Visible = false dafür sorgte, dass das Control erst garnicht gerendert wurde und somit auf dem Client nicht verfügbar war.

Die simple Lösung im Codebehind:

meinControl.Style.Add(HtmlTextWriterStyle.Display, "none");

Dann klappts auch mit dem Einblenden ;-)

War dieser Beitrag hilfreich? Dann kick ihn doch bitte.

ASP.NET MVC 2 für das .NET Framework 3.5 SP1 / Visual Studio 2008  ist seit gestern RTM und steht hier zum Download bereit.

Just nach der Basta hat es mich erwischt. Beim Badminton, nach einem zugegebenermaßen nicht gerade lehrbuchhaften Abwehrschlag von der Grundlinie, hat sich meine Achillessehne verabschiedet. Glatter Abriss. Inzwischen ist es wieder zusammen genäht worden (sieht aus, wie der zugenähte Bauch einer ausgestopften Weihnachtsgans ;-))

Irgendwo habe ich gelesen, dass eine solche Achillessehne bei einem erwachsenen Menschen bis zu einer Tonne Zugkraft aushält.  Da kann man mal sehen, was Hebel so alles bewirken. Jedenfalls bin ich in den nächsten 6..7 Wochen sehr immobil.

Ab nächste Woche werde ich dann aber wieder etwas mehr zum neuen VSTO schreiben, sowohl hier für den Blog als auch für einen neuen Artikel im dotNet Magazin.

Ich werde versuchen, alle Fragen, die in den letzten 3 Wochen eingegangen sind, bald zu beantworten.

Das ist übrigens die neueste Fussmode für Achillessehnengeschädigte. Das Gute daran ist, es ersetzt den sonst üblichen Gips vollständig und kann bei Bedarf abgenommen werden. Die Aussicht, damit 8 Wochen auskommen zu müssen, ist allerdings weniger erfreulich.