Ich beschäftige mich gerade mal etwas intensiver mit dem AJAX-Framework - eigentlich ja schon ein alter Hut. Dabei habe ich ein DotNetNuke-Modul, dass zu einem ASMX-WebService Daten versendet und ein Ergebnis zurück bekommt.

namespace G.Modules.LicCalc
{

  [WebService(Namespace = http://tempuri.org/)] 
  [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
  [ScriptService]
  public class CalculatorService : System.Web.Services.WebService
  {

    [WebMethod()]
    public string HelloWorld(LicCalcInfo info)
    {
       return "Hello World" + info.LinuxLicense.ToString();
    }
  }
 
}

Passend dazu gibt es eine Klasse "LicCalcInfo" - die wie DotNetNuke-typische Info-Class aufgebaut ist

using System;

namespace GMS.Modules.LicCalc.Business
{
public class LicCalcInfo
{
private int _windowsLicense;
private int _linuxLicense;

public int LinuxLicense
{
get { return _linuxLicense; }
set { _linuxLicense = value; }
}

public int WindowsLicense
{
get { return _windowsLicense; }
set { _windowsLicense = value; }
}

}
}

Wenn ich jetzt über JavaScript versuche die Methode "HelloWorld" aufzurufen und den Parameter LicCalcInfo übergeben möchte, wird bei der Erstellung der Klasse immer eine JavaScript-Exception ausgelöst. Das JavaScript sah so aus:

function HelloWorld()
{

var info = new LicCalcInfo();
info.LinuxLicense = 10;
DocuSnap.Modules.LicCalc.CalculatorService.HelloWorld(info, SucceededCallback);

}

function SucceededCallback(result, eventArgs)
{
    alert(result);
}

Das ganze funktioniert aber nur, wenn die Klasse "LicCalc" direkt in der ASMX Datei definiert wurde und sich außerhalb des Namespaces befindet. Als extern definierte Klasse habe ich die Einbindung nie geschafft. Die Lösung dabei ist aber mal wieder relativ einfach: Bei der Erzeugung des Objektes in JavaScript muss das Objekt mit dem kompletten Namespace angesprochen werden.. das hat mir dann ein Blick in die automatisch gernierte JavaScript-Datei veraten. Der Aufruf zur Erzeugung muss dann so geschrieben werden:

var info = new DocuSnap.Modules.LicCalc.Business.LicCalcInfo();

Dann kann die Klasse auch in JavaScript erzeugt werden und die Verarbeitung wird erfolgreich durchgeführt.

Eigentlich habe ich ja ein paar Module (News, FAQ) für DotNetNuke gesucht - dabei bin ich dann über ein Game gestolpert, dass jeder von uns kennt und auch gerne spielt: Schiffe versenken :)

Auf der Seite http://www.donein.net/Default.aspx?tabid=58 gibt es sowohl einen Downloadlink als auch die Möglichkeit, das Spiel direkt mal zu testen!

Viel Spaß :)

Eine aktualisierte Version von VisualSVN Server - ein Installation-Package für Subversion auf einem Windows Server 200x - steht zum Download bereit. Diese MSI-Paket installiert einen Subversionen-Server in der Version 1.5.
Auch ein Update ist ohne Probleme möglicht, lediglich die Konvertierung muss auf das neuste Subversionformat durchgeführt werden.

Hier ist der direkte Link zum Download:  http://www.visualsvn.com/server/changes/1.5/

Ich bin mittlerweile wirklich dankbar für dieses Stück Software, da die Installation wirklich simple ist :)

Für ein aktuelles Projekt benötige ich von Plätzen / Anschriften die GEO-Koordinaten. Da zur Visualisierung so wieso Google-Maps später eingesetzt werden soll, liegt natürlichdie Google-API nahe. Dafür habe ich heute ein C# Klasse entwickelt, mit der man einfach über einen HTTPRequest das Ergebnis in XML zurück geliefert bekommt. Die Klassen analysiert das Ergebnis von Google auf Fehler und parst die Werte für Latitude und Longitude.

Zunächst habe ich mir das Core-Modul von DotNetNuke "MAPS" angeschaut, das ebenfalls die Google-Maps nutzt. Es funktioniert recht gut - nur war ich von der vorgehensweise docht etwas erschrocken: Da wird das Ergebnis wirklich noch mit String-Funktionen (Find, Left, SubString) auseinandergenommen um an die Werte zukommen. Hallo? Wofür gibt es einen XML-Parser, der für solche Aufgaben entwickelt wurde und auch deutlich schneller ist, bei der Analyse von XML.
Das aber nur als Zwischenbemerkung an dieser Stelle

Bei der Entwicklung der Klasse hatte ich zunächst Probleme mit XPath die Werte auszulesen. Da ich ja diesmal gezielt ein paar Daten aus dem XML-File benötige und nicht wirklich Node für Node durchgehen muss (wollte), war XPath meine erste Wahl. Mache das aber nicht so häufig und hatte zuerst schwirigkeiten, weil die Abfrage SelectSingleNode immer einen null-Value zurück lieferte. Nach kurzer Zeit viel mir dann aber auf, das Google einen Namespace im XML-Dokument stehen hat - so wie es ja eigentlich auch sein soll. Diesen Namespace muss aber bei einer XPath-Abfrage auf jeden Fall vorher dem Parser bekannt geben. Dann funktioniert die Abfrage auch ohne Probleme. Das sieht dann in etwa so aus:

XmlNamespaceManager nsManager = new XmlNamespaceManager(xmlDoc.NameTable);
nsManager.AddNamespace("gm", "http://earth.google.com/kml/2.0");

///Es wird versucht den Statuscode zu ermitteln
XmlNode nodeStatus = xmlDoc.SelectSingleNode("gm:kml/gm:Response/gm:Status/gm:code", nsManager);

In der Abfrage hier wird der Status-Cide abgefragt, um zu überprüfen ob die Anfrage erfolgreich war. xmlDoc ist dabei mein XML-Parser ( System.Xml.XmlDocument).

Die fertige C# Klasse steht hier zum Download bereit:

Heute stellte sich mir die Aufgabe eine simple Stored Procedures zu schreiben, die x Datensätze aus einer Tabelle liest. Kein Paging sondern wirklich nur eine ganz bestimmte Anzahl - halt die TOP x Datensätze.

Also habe ich folgende SP geschrieben:

CREATE PROCEDURE dbo.Get_Top
@topCount int
AS
    SELECT TOP @topCount
    id, col1, col2, col3
   FROM TestTable

Leider wurde mir dabei immer ein Syntaxfehler ausgeworfen - die Nutzung von dem Parameter innerhalb vom SQL-Statement scheint dem SQL-Server 2005 nicht zu schmecken. Also erst mal etwas gegooglet.... und zum guten Schluß stelle sich raus das die Lösung so einfach ist - aber darauf kommt man wohl zunächst nicht. Es reicht aus um das @topCount einfach eine Klammer zu setzen und schon kann der SQL-Server die SP verarbeiten.

Die lauffähige Stored Procedures für den SQL-Server sieht dann so aus:

CREATE PROCEDURE dbo.Get_Top
@topCount int
AS
    SELECT TOP (@topCount)
    id, col1, col2, col3
   FROM TestTable

Darauf muss man erst mal kommen

Heute habe ich versucht, den FCKEditor innerhalb eines ASP.NET Ajax Updatepanel dazu zu bewegen mir auch den eingegebenen Text auszuhändigen. Normalerweise ist ja die Einbindung und Nutzung vom FCKEditor innerhalb von DotNetNuke denkbar einfach. Also wie gewohnt die Arbeitsschritte ausgeführt und mal mutig F5 gedrückt. Leider mit dem Resultat, dass die Eigenschaft Text vom FCKEditor nach einem partial PostBack immer leer war und der Text zunächst mysteriös verschwand. Die Suchmaschine meines Vertrauen hat mir auch prompt ein paar Hinweise zu dem Thema ausgespuckt - gut, ich war wohl nicht alleine auf dieser Welt.

Auf der Seite http://jlcoady.net/archive/2007/03/30/fckeditor-work-inside-updatepanel wurde ein Lösungsansatz vorgestellt, der aber leider so nicht ganz funktioniert - zumindest im meinem Fall nicht.

private void Page_Load(object sender, EventArgs args)
{
   Page.ClientScript.RegisterOnSubmitStatement(
   editor.GetType(),
   "editor",
   "FCKeditorAPI.GetInstance('" + editor.ClientID + "').UpdateLinkedField();");
}

Dieser Code-Snippet bracht mich nicht weiter, denn der Text wurde immer noch nicht zurück geliefert, nach einem Postback innerhalb vom UpdatePanel.

Auch der folgende Code sollte angeblich funktionieren, konnte aber meine FCKEditor auch nicht wirklich übereden, mal endlich seine Arbeit aufzunehmen.

this.Page.ClientScript.RegisterOnSubmitStatement(
this.GetType(),
"AjaxHack",
"for ( var i = 0; i < parent.frames.length; ++i ) if ( parent.frames[i].FCK ) parent.frames[i].FCK.UpdateLinkedField();"
);

Wie sich nun herausstellt, sind die Scripte vollkommen in Ordnung und funktionieren auch. Nur ist es empfehlenswert die Methode "RegisterOnSubmitStatement" nicht als Methode der Page aufzurufen sondern als Methode vom ScriptManager. Das sieht dann so aus:

ScriptManager sm = ScriptManager.GetCurrent(Page);
if (sm != null)
{
ScriptManager.RegisterOnSubmitStatement(this.Page,
this.GetType(),
"FCKAjaxHack",
"for ( var i = 0; i < parent.frames.length; ++i ) if ( parent.frames[i].FCK ) parent.frames[i].FCK.UpdateLinkedField();");
}

Oh Wunder, jetzt funktioniert auch der FCKEditor in der Zusammenstellung von DotNetNuke, ASP.Net Ajax und dem Updatepanel!

Bei der Neuinstallation eines Windows 2008 Server mit ASP.NET 2.0 und AJAX bekam ich beim Abruf von Resourcen über WebResource.axd und ScriptResource.axd jeweils den Fehler:

Specified argument was out of the range of valid values.
Parameter name: utcDate

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: utcDate

Source Error:

Lösung:

Das liegt an der Systemzeit vom Windows Server. Zunächst sollte diese Zeit überprüft werden und falls nötig auf das aktuell Datum / Uhrzeit gesetzt werden.

Sollte dadurch der Fehler nicht behoben werden, dann einfach unter Software die Installation von AJAX mit der Option "Reparieren" durchführen. Es scheint hier wohl eine Fehler zu geben und ASP.NET AJAX kommt dann mit dem Datum nicht zurecht. Nach der "erneuten" Installation funktioniert dann alles wie gewollt!

Wer kennt es nicht (gerade in kleinen) in Kundenprojekten. Können Sie hier den Text ändern, die Farbe dort gefällt mir nicht - hm, welche genau? Zwei Menschen sitzen vor unterschiedlichen Rechner und versuchen ein Design abzustimmen. Das ist nicht immer ganz einfach. Leider schaffe es auch nicht alle einen Screenshot zu erstellen um diese dann mit den Änderungen abzuliefern.

Abhilfe schafft hier FireShot, ein kleines Firefox Add-On das nicht nur Screenshots macht, sondern dem Anwender es auch direkt erlaubt Veränderungen im Bild vorzunehmen.

Sehr schön, das ist wirklich nützlich! Den Download von FireShot gibt es hier...

Wer sich mit tabellenlosen Designs beschäftigt - und sind wir mal ehrlich, ergibt es anders einen Sinn - der wird sich auch immer wieder mal mit dem DOCTYPE rumschlagen müssen. Zum Glück haben die Entwickler von DotNetNuke da auch mitgedacht und den DOCTYPE pro DNN-Portal, sogar pro DNN Skin konfigurierbar gestaltet.

Dafür muss lediglich eine XML-Datei angelegt werden, die den Namen des Skins trägt und dann die Endung ".doctype.xml" hat  also von Aufbau her so aussieht [SKINNAME].doctype.xml.

Die XML Datei hat folgenden Aufbau:

<SkinDocType>
<![CDATA[<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">]]>
</SkinDocType>

Fertig ist der angepasste DOCTYPE für ein DotNetNuke-Skin.

Das war doch mal wieder einfach :)

Bei der Durchsicht meiner Online-Statistiken ist mir gerade folgender Link aufgefallen: http://www.blogato.net/ und da ich von Natur aus ein neugieriger Mensch bin (liegt wohl am Beruf), habe ich mir die Seite etwas näher angeschaut. Dabei handelt es sich um eine Suchmaschine, die nur in Blogs sucht. Ziel ist es "...nur die relevantesten und interessantesten Beiträge in der Blogsphäre zu finden."

Da auch hier kein "Web 2.0" fehlen darf (eigentlich mag ich es gar nicht Web 2.0 zu schreiben) sollen die User aktiv mithelfen die Qualität der Suchergebnisse zu steigern.

Mein Blog ist auf jeden Fall schon mal im Index :)

Habe soeben eine ziemlich schön (zumindest auf dem ersten Blick) ASP.NET Komponente entdeckt, die einem die relativ einfach Möglichkeit bietet serverseitige Variablen an den Client Browser zu übergeben. Dafür gibt es hier eine Klasse, die einem die Verwaltungsarbeit abnimmt.

Der Weg: var CustomerName = '<%= Customer.Name %>'; ist ja nicht wirklich elegant und ich persönlich finde es immer schlechten Stil, wenn man in einer ASPX-Seite anfängt und Serverseitigen Code schreibt. [Nein, bitte keine Grundsatzdiskussion - einfach meine Meinung :)]

Viel optimaler unter ASP.NET ist doch die folgende Möglichkeit:

protected void Page_Load(object sender, EventArgs e)

{

   wwScriptVariables scriptVars = new wwScriptVariables();

   // *** Add any values static or dynamic

   scriptVars.Add("CustomerName", Customer.Name);

   // *** Done
}

//<![CDATA[

var serverVars = {

    "name": "Müller, Maier, Schmitu"

}

//]]>

</script>

Ein Kunde wollte in seinem aktuellen DNN-Projekt eine Sitemap für sein Portal erstellen - eigentlich ja nichts ungewöhnliches aber in den letzten DotNetNuke Projekten wurde es bei uns so gut wie nie gebraucht.
Habe mir heute die Mühe gemacht und noch mal ein wenig gesucht, welche DNN Module es denn derzeit so auf dem Markt gibt, welche die Anforderungen einer Sitemap erfüllen. Bei all den vielen Treffern habe ich dann die Seite houseofnuke.com bzw. dort das Modul HouseIndex entdeckt und finde die Darstellung dieser Sitemap wirklich klasse. Neben dem Seitenname kann man auch die Keywords und die Beschreibung der Seite ausgeben lassen - echt sinnvoll!

Und so kann die Sitemap aussehen:

Eigentlich finde ich den FCKEditor mal richtig klasse und im Vergleich zum FreeTextBox-Editor deutlich besser zu gebrauchen. Auch die Integration in DNN ist gut gelungen - besonders toll finde ich das Feature unterschiedlichen Benutzergruppen unterschiedliche Toolbar-Sets zur Verfügung zu stellen. Immer wieder haben ich das Problem das Kunden mit Redakteuren arbeiten, die nicht alles mit dem Editor machen sollen.

Die Einrichtung ist ja auch eigentlich ganz simple:

• in der web.config im Abschnitt "FckHtmlEditorProvider" den Parameter "AvailableToolBarSets" modifizieren und die benötigten Toolbarsets per Namen dort bekannt geben.
• dann im Order "Providers\HtmlEditorProviders\Fck\Custom" die entsprechende Datei fckconfig.js abändern und dort einfach die Toolbars definieren.
• Glücklich sein!

Leider bin ich in den Anläufen heute nicht über den zweiten Punkt hinaus gekommen. Immer wieder habe ich die Meldung - in einer JavaScript Alert-Message- bekommen:

"Toolbar set 'basic' doesn't exits"

Egal was ich auch gemacht habe (Browsercache gelöscht, Webserver angehalten, die Konfigurationsdateien web.config und fckconfig.js angepasst) hatte keinen Einfluss darauf. Immer wieder wurde mir diese Meldung ausgegeben. Allerdings nur, wenn ich mich mit den Rechten einer ganz speziellen Gruppe angemeldet habe, die nur auf einem Modul Editierrechte hatte... hm, dabei sollten die eigentlich nicht mit dem Toolbar-Set Basic sonder mit Redaktion-xyz arbeiten.

Nach langen hin und her, analysieren vom Quellcode des DNN FCK-Providers, etc. habe ich dann folgendes probiert:

Den Dialog "Individuelle Editoreinstellungen" aufrufen:

Dann habe ich unten aus der Auswahlliste Instanz, Modul, Portal ausgewählt (natürlich hintereinander) und habe auf "löschen" geklickt. Dazu muss man nun wissen das im engl. dort "clear" steht und "löschen" finde ich ein wenig unschön übersetzt. 

Nachdem ich mir nun allen Mut zusammen gekommen habe .. hab ich einfach darauf geklickt und damit dann die kompletten Einstellungen  zurück gesetzt. Anschließend konnte ich für das Portal die Berechtigungen neu setzen und jetzt: BIN ICH GLÜCKLICH und der Editor arbeitet wie gewünscht mit DotNetNuke zusammen ... :)

In den letzten Jahren habe ich so viel mit XML gearbeitet, dass es mir z.B. keine Probleme bereitet die Web.Config auch mit Notepad(++) zu bearbieten. Für alle die aber lieber eine grafische Benutzeroberfläche nutzen habe ich hier ein tolles gratis Editor für die ASP.NET web.config gefunden. Es trägt den Namen ASPHere und ist komplett kostenlos. Den Download vom Editor gibt es hier...

Hier ein Bild des XML (web.config) Editors.

Ich wünsche viel Spaß!

Hm, also wenn ich die Wahl habe .. dann entscheide ich mich für Hawaii :) Wie ich gerade gehört habe ist das der Codename für .NET 4.0! Ob .NET 4.0 genau so klasse wird wie Hawaii wird sich zeigen ..

Das Framework soll voraussichtlich im Jahr 2009 erscheinen... lassen wir uns überraschen, was Microsoft da zaubert!

Folgendes habe ich gerade auf der DotNetNuke Seite gelesen und mich sehr darüber gefreut. Im wesentlichen geht es dabei um eine Neustrukturierung des Administrationkonzeptes. Zukünftig soll es möglich sein auch selber Administrationsmodule zu entwicklen und diese dann einfach in das Admin-Menü mit aufnehmen (ohne Eingriffe in die Datenbank).
Ganz spannend finde ich auch, dass man die Berechtigung für die einzelnen Admin-Seiten auch endlich über die ganz normalen Seitenberechtigung steuern kann. Damit ist es dann super easy einzelnen Leuten (Gruppen) die Berechtigung für div. Adminseiten zu erteilen.

Ich bin gespannt was die Zukunft hier bringt - hört sich auf jeden Fall gut an.

Den Artikel (Blogeintrag) gibt es hier...

Auch während Weihnachten war das DNN-Core-Team wohl nicht ganz untätig und hat am 27.12.2007 den Download der DotNetNuke Version 4.8.0 frei gegeben. Es wurden viele Fehler korrigiert und neu ist der Support von DNN für den IIS (Internet-Information-Server) 7.0. Wer sich einen genauen Überblick von den Änderungen der aktuellen DNN Version machen möchte - Bitteschön, wie immer geht das im Bugtracking System support.DotNetNuke.com

Wer auf einen Blick die wichtigsten Visual Studio Shortcuts sehen möchte, dem kann ich folgendes PDF empfehlen. Diese Liste der Shortcuts ist sicherlich nicht vollständig, allerdings für die tägliche Arbeit schon holfreich. Zumindest kann so teilweise auf die Maus verzichten....