DNN 3.1 Source-Code der Desktopmodule

Das Core-Team von DotNetNuke hat die Strategie bei den mitgelieferten Modulen geändert. Diese werden jetzt nicht automatish mit DotNetNuke installiert sonden müssen / können  einzeln installiert werden. Dabei müssen diese Module nicht mit der Hand installiert werden sonden einfach in den Ordner Install/Module abgelegt werden. Bei der Originalauslieferung liegen die bisherigen Module schon (als ZIP - Datei mit einem dnn-File) in diesem Ordner vor. Auf den ersten Blick sieht man den Source Code nicht mehr. Keine Panik, das Core-Team hat den Source nur in die Datei Projekt.resources versteckt. Einfach in ZIP umbennen, auspacken und glücklich sein!  

DotNetNuke 3.1

Nachdem jetzt schon seit ein paar Tagen die DotNetNuke Seite auf der Version 3.1 läuft, gibt es diese Version nun auch endlich als Download. Unter www.dotnetnuke.com gibt es die Version DNN 3.1 vom 09.06.2005. Da bin ich jetzt aber mal gespannt!

DotNetNuke JavaScript alert "Die Internetseite ... kann nicht geöffnet werden"

In der aktuellen Version von DotNetNuke (DNN 3.0.13) hatte ich vermehrt mit der Fehlermeldung "Die Internetseite ... kann nicht angezeigt werde. Vorgange abgebrochen" zu kämpfen! Dies Meldung kamm immer in einer JavaScript alert MessageBox und sah so aus: Leider kann man diesen Fehler nicht provozieren und erst recht nicht reproduzieren. Mittlerweile habe ich eine Lösung für das Problem: Die SolPart-Komponente scheint hier diesen Fehler zu erzeugen und das auch nur im Internet Explorer. In der JavaScript-Datei "spmenu.js" muss einfach eine Zeile verändert werden: this.delaySubmenuLoad=(spm_getAttr(o, 'delaySubmenuLoad', '0') != '0' && spm_needsSubMenuDelay()); ändern in: this.delaySubmenuLoad=spm_needsSubMenuDelay(); Danach war der Fehler bei mir behoben. Hoffentlich übernimmt das CoreTeam von DotNetNuke auch diese Änderung in der nächsten Version.

DotNetNuke Controls

Es lohnt sich doch immer erst mal zu forschen, ob jemand eine Problemstellung schon mal gelöst hat, bevor man etwas selber programmiert. :) Heute musste ich zum ersten Mal (in einem DotNetNuke Modul) eine Auswahl von Dateien aus dem Portal vornehmen. Hatte bisher aber mir noch nie angeschaut, wie das so geht. Das Core-Team von DotNetNuke rocks .. die haben natürlich ein sehr coole Komponten geschrieben, um das Problem zu lösen. <%@ Register TagPrefix="Portal" TagName="URL" Src="~/controls/URLControl.ascx" %> <portal:url id="ctlURL" runat="server" width="300" showtabs="false" showfiles="true" showUrls="false" urltype="F" showlog="false" shownewwindow="false" showtrack="false"/> Mit diesen beiden Zeilen kann man folgende Funktionalität in DotNetNuke abbilden: "showfiles" -> Auswahl einer Datei aus dem Portal "showtabs" -> Auswahl einer Seite (Tab) aus dem Portal "showUrls" -> Eingabe einer URL "showlog", "shownewwindow", "shownewwindow" ;-> Die bekanten Einstellungen So macht das Entwickln echt Spaß :)

Jede Menge Stuff: DotNetNuke / Web Services / NT - Service / Scheduler

Heute Abend habe ich mal mit ein interessantes Thema beschäftigt - Scheduler-Jobs unter DotNetNuke. DotNetNuke im Core einen eigene Implementierung für Scheduler, allerdings laufen diese Jobs im Prozess er Webanwendung. Dieses bedeutet, dass die einzelnen Jobs nur dann ausgeführt werden können, wenn der Hauptprozess der Webanwendung auch läuft. Darauf kann man sich allerdings nicht wirklich verlassen ... Aus diesem Grund habe ich eine eigene Architektur entwickelt, bei der man vom Hauptprozess unabhängig ist. Folgendes Szenario: Ich möchte jeden Abend um Punkt 21 Uhr eine E-Mail an ganz bestimmt User verschicken. In einem Windows NT-Service habe ich einen Scheduler integriert, der je nach Konfiguration zu einem beliebige Zeitpunkt verschiedene Assemblies ausführen kann. Natürlich hätte man auch den Windows internen Scheduler nehmen können aber so habe bin ich etwas flexibler, was die Konfiguration betrifft. Wie kommt jetzt dieser Service an Daten von DotNetNuke ran? Nun der Scheduler ruft zu einem ganz bestimmten Zeitpunkt ein Programm auf, dass für den Versand der E-Mail zuständig ist - oder viel mehr das die E-Mails aufbereitet und dann in eine MSMQ schiebt. Die benötigten E-Mailadressen bekommt dieses Programm über einen Web Service der innerhalb der DotNetNuke Webanwendung läuft. Bei diesem Web Service handelt es sich lediglich um Schnittstelle, die dann wiederum auf eine typische DotNetNuke Assembly zugreift. Damit ist die Grundarchitektur von DotNetNuke nicht verändert wurden. Der Source Code für den Web Service ist wirklich sehr simple: using System;using System.Collections;using System.ComponentModel;using System.Data;using System.Diagnostics;using System.Web;using System.Web.Services;using System.Xml ;using System.Xml.Serialization ;using Lowfett.Goldmember.WeightProcess.MailNotification.Business ;namespace Lowfett.Goldmember.WeightProcess.Webservive.MailNotification{    /// <summary>    /// Zusammenfassung für Service1.    /// </summary>    public class WSMailNotification : System.Web.Services.WebService    {        public WSMailNotification()        {            //CODEGEN: Dieser Aufruf ist für den ASP.NET-Webdienst-Designer erforderlich.            InitializeComponent();        }        #region Vom Komponenten-Designer generierter Code         //....        #endregion            [WebMethod]        [System.Xml.Serialization.XmlInclude(typeof(MailNotificationInfo))]                public ArrayList GetUserToNotify()        {            return new MailNotificationController().GetUserToNotify() ;         }    }} Wichtig ist das die Assembly des Web Service im "bin" Verzeichnis von DotNetNuke liegt - die asmx Datei kann in einem beliebigen Unterverzeichnis liegen. Den Source Code für den NT-Service und den Client des Web Services erspare ich mir an dieser Stelle!

dotnetnuke.com wurde auf die Version 3.1 aktuallisiert

Die Seite www.dotnetnuke.com läuft jetzt mit der noch nicht verfügbaren Version 3.1 von DotNetNuke. Das läßt vermuten, dass diese Version von DotNetNuke wohl auch bald zum Download bereit gestellt wird. Hauptsächlich wurden in diesem Release Bugfixes eingepflegt. Eine genau Übersicht gibt es unter http://support.dotnetnuke.com....

Die Datenbank von DNN ist sehr groß und wächst permanent an!

Hans-Peter von deutschen DNN-Portal hat dort einen recht interessanten Hinweis gepostest: http://www.dnnportal.de/Weblog/tabid/177/EntryID/112/Default.aspx Ein Tip an alle DotNetNukler: Überpürft mal ob man wirklich alle Einträge braucht die DotNetNuke dort reinschreibt und vor allem ob und wie lange die Einträge dort gespeichert werden. Immerhin hat DotNetNuke die Tabelle SiteLog bei mir auf 10.000.000 (da ist keine Null zu viel) anwachsen lassen. Wie man sich vorstellen kann, kommen da einige MB zusammen. Da ist wohl morgen erst mal "Putztag" angesagt und das nicht nur in meiner Wohnung :)

DotNetNuke on DotNetRocks

DotNetRocks ist eine Radiosendung die sich mit allem rund um das Thema .NET befasst. In einer der letzten Sendungen war ein paar der Köpfe von DotNetNuke als Gäste eingeladen. Dabei handelte es sich um "Jim Duffy" und "Shaun Walker"! Wer sich diese Sendung anhören möchte ... hier ist der direkte Link: http://www.dotnetrocks.com/default.aspx?showID=113  Echt cool ;-) Die Inhalte sind: Wichtige Änderungen zwischen der Version 2 und der aktuellen Version 3 Der Gedanke von Open Source    Die Zukunft von DotNetNuke

Windows Service in .NET

Hier ist ein cooler Artikel der kurz und knapp eine Anleitung zum Erstellen eines Windows Service unter DotNet gibt: http://www.developer.com/net/csharp/article.php/10918_2173801_1 Habe ihn gerade entdeckt, da ich auf der Suche war den Scheduler Service von DotNetNuke zu umgehen. Der hat nämlich so einige negative Eigenschaften, die ich für meinen Anwendungsfall nicht gebrauchen kann. So ist der Scheduler von DotNetNuke nur verfügbar, wenn auch die Webanwendung aktiv ist. Sollte es also vorkommen, das niemand im Portal online ist und die Webanwendung ist heruntergefahren ... blöde Sache! Nun ja, deswegen versuche ich das jetzt mit Hilfe eines (DotNet) Windows Service zu implementieren.  

Dotnetnuke - Userverwaltung / It not a feature it’s a bug ;-)

Habe soeben ein Fehler in der Benutzerverwaltung von DotNetNuke gefunden. Wenn sich ein Benutzer mit Hilfe eines Cookies immer anmelden möchte wird bei einer späteren Anmeldung per Cookie wohl keine Validierung der Daten durchgeführt. Ein Sperren des Benutzerkontos und auch die Änderung des Passworts haben keinerlei Einfluß... der Benutzer kommt weiter fleißig ins Portal :( Derzeit setze ich auf dem Live-Server die DotNetNuke Version 3.0.12 ein - werde mal testen ob das in der Version 3.0.13 auch noch so ist.  

MSMQ rocks

Bei einem Portal mit DotNetNuke besteht das Problem, dass ne ganze Menge E-Mailtraffic entsteht. Es gibt eine ganze Menge an Funktionen und Modulen, die E-Mail-Benachrichtigungen durch die Gegend schicken. Besonders beim Thema Newsletter versagt DotNetNuke ein wenig - immerhin sprechen wir von mittlerweile ca. 20.000 Usern (oder E-Mailadressen). Da ich schon seit langem die MSMQ etwas stärker involvieren wollte, war hier die beste Möglichkeit dieses endlich zu realisieren. Eine E-Mail ist ja so wieso ein asynchroner Prozess und was hindert einen also daran die E-Mails in eine gemeinsame "Message Queuing Services" zu schieben, um diese von einer Stelle aus zu verschicken. MSMQ steht für "Microsoft Message Queuing Services" und ist ein wenig, um asynchrone Prozesse oder man kann diese auch Workflows nennen, abzubilden. Ein Windows Service sorgt für das Prozessmodell, denn irgendwie muss das Programm zum Abrufen der MSMQ und zum Versenden der E-Mails ja "leben". Die Erstellung eines Windows Service ist nicht spektakulär, deswegen erspare ich mir Details. Wie man einen Versand von E-Mail realisiert ist nun auch ein alter Hut .. damit will ich nun wirklich keinen langweilen. Okay, ich gebe zu das ist nicht so die super Erfindung aber eine ganz nette Sache um Anwendung DotNetNuke etwas zu entlasten - das "Reinschieben" einer Nachricht in die MSMQ geht nun mal schneller als das direkte Versenden. Vorteile sind z.B. auch, dass man Transaktionen nutzen kann um so sicherzustellen, dass die E-Mail an den SMTP-Server auch sicher übergeben wurde. Teilweise werden die Nachrichten direkt von DotNetNuke in die MSMQ geschoben oder aber wenn noch viel "Vorarbeit" geleistet werden muss kommen hier der DotNetNuke Scheduler Mechanismus zum Einsatz. Warum ich diesen nicht benutze um die E-Mails aus DotNetNuke zu versenden? .. ganz einfach: Ich wollte eine allgemein g��ltige Schnittstelle haben!

DotNetNuke JavaScript - Error

Wer einen seltsamen JavaScript-Fehler bei DotNetNuke bekommt und einfach keine Lösung findet - vielleicht ist da ja eine: Also der Fehler ist folgender: Beim Laden einer Seite kommt die eine JavaScript-Meldung.. Zeile: 2Zeichen: 1Fehler: SyntaxfehlerCode: 0 Habe mir einen Wolf danach gesucht. Habe dann den HTTP-Header mitgeschrieben und gesehen das zwischendurch auf die 404 Seite weitergeleitet wurde. Die Datei: aspnet_client/system_web/1_1_4322/WebUIValidation.js sollte geladen werde, konnte aber nicht gefunden wurden. Da klingelte es - es fehlten das benötigte aspnet_client - Verzeichnis im Stammverzeich der DotNetNuke Installation. Ich denkde das dieser Fehler nicht nur für DotNetNuke Anwendungen sonder auch für jede andere ASP.NET Anwendung zutrifft....

DotNetNuke - Javascript error "ScrollTop' is null or not an object.

Wer schon mal über den lästigen Fehler Javascript error "ScrollTop' is null or not an object. bei DotNetNuke stößt, dem sei hier Abhilfe geschaffen. Das trat immer auf, wenn ich ein eigenes Modul auf eine Seite platziert habe. Man muss sagen, dass man sich diesen Fehler selber einhandelt. Habe ein paar Module - oder viel mehr den HTML Code dafür - aus einem alten Projekt kopiert. So weit auch kein Problem nur darf natürlich kein weiteresmal ein <form> - Tag im HTML-Code auftauchen! Also einfach mal mit <strg>-f nach dem Wort "form" suchen und schauen ob das der Grund ist ;-)

Erstes DNN-Portal online

Nach ein sehr anstregenden 14 Tagen ist es endlich so weit und mein erstes DotNetNuke-Portal ist online. Also mein erstes Web-Portal auf Basis von DotNetNuke. Bis auf ein paar Schwierigkeiten ging auch eigentlich alles ganz gut. Jetzt läuft es auf jeden Fall :) Wer mal schauen will: http://www.lowfett.de Das wird alles noch wachsen und muss ausgebaut werden .. aber jeder fängt mal klein an :)

DotNetNuke 3.0.12 E-Mail Benachrichtigung

Gerade schalte ich mein erstes Portal mit DotNetNuke 3.0.12 online. Bisher hatte existierte immer noch ein Problem, dass bei der E-Mailbenachrichtigung für einen neuen User, der Username und das Passwort fehlten. Der Grund ist ganz einfach, denn in den Vorlagen steht: [User:Password]bzw.[User:Password] richtig ist aber: [Membership:Password]bzw.[Membership:Password]   Wer neugierig ist und ein weiteres DotNetNuke Portal sehen will: www.lowfat.de oder sehr bald www.lowfett.deEs befindet sich noch in den Anfängen aber aller Anfang ist schwer ;-)  

DotNetNuke UserOnline BuddyListe

Wie fleißige Leser dieses Weblog wissen, entwickel ich eine (ganze) Menge Module um eine Community auf Basis von DotNetNuke zu realisieren. Darunter fällt so etwas wie: Private Nachrichten (Instant Messaging) Erweiterte Benutzerprofile. Mit Angaben wie Alter, Foto, Geschlecht und einen dynamischen Fragekatalog Such nach den Benutzernprofilen - das war ein ein wenig Denksport ;-) Was bei einer guten Community nicht fehlen darf ist eine Buddyliste. Nach ein paar Nachforschungen und der No. 1 Anlaufstelle www.dnnportal.de habe ich zwar eine Buddyliste gefunden aber leider ist diese zu einfach gestrickt. Was ist daran kompliziert? Folgendes: Gerade entsteht eine Buddyliste die: anzeigt, welche seiner Buddies online sind man hat die Möglichkeit, das Hinzufügen eines Eintrages zu unterbinden - das Hinzufügen meines Buddies muss also durch ihn genehmigt werden gleichzeitig kann man die Liste auch nutzen um andere User zu sperren bzw. die Kontaktaufnahme zu unterbinden. ein Rechtesystem, dass bestimmt, wer welche Aktion durchführen kann. Den Grundstein habe ich heute Nacht dafür gelegt. Hoffe das ich morgen damit so weit fertig werde und das dann in das Puzzel Community einbauen kann.    

Neue Modulberechtigungen hinzufügen

Nachdem jetzt das Modul der Usersuche für DotNetNuke fertig ist, war noch die Anforderung, dass man für unterschiedliche Benutzergruppen differente Rechte vergeben kann. Normale User sollten z.B. kein Bild sehen können.... usw. Da ich alle meine Module mittlerweile in C# entwickel, habe ich ein Konvertierung des Mechanismus von DNN vorgenommen. Zja, viel Arbeit und eigentlich wollte ich gerade schlafen gehen, immerhin haben wir ja schon vier Uhr ...(nachts). Im Badezimmer ist mir eingefallen, dass es in der Tabelle Permission eine Spalte ModuleDefID existiert ... und das wohl mit gutem Grund. Hmmmm.... Okay, die letzten dreieinhalb Stunden hätte ich mir sparen können :( Also, wenn jemand von euch die Rechte bei DotNetNuke erweitern will, dann einfach diese in der Tabelle Permissions eintragen und bei ModuleDefID die entsprechende Referenz aus der Tabelle ModulDefinition. Na, man lernt halt nie aus .... gute Nacht!

Fuer jeden Satz mit x gibt es auch eine Loesung

Heute habe ich mich noch mal um die Suche in Benutzerprofilen bzw. in der Tabelle ASPNET_PROFILE gekümmert. Um wirklich eine gute Performance zu erreichen. wird man nicht eine redundanten Datenhaltung nicht vermeiden können. Um nicht den DotNetNuke - Core, Tabellen oder aber die Stored Proceduren von DNN zu verändern, habe ich mich dann für Trigger direkt im MS SQL Server entschieden. Die Erstellung des Triggers war zunächst etwas problematisch, da man innerhalb eines Trigger nicht auf ein Feld vom Typ "nText" zugreifen kann. Änder der Datentypen wollte ich ja vermeiden und so habe ich einfach die Daten aus der Orginaltabelle gelesen. Klappt perfekt und die redundante Datenhaltung tut jetzt auch schon fast gar nicht mehr weh :) Wichtig ist nur das man mit einem Trigger arbeitet, der ausgelöst wird nachdem die Aktion insert ode update durchgeführt wurde. Beispielhaft sieht das dann so aus: CREATE TRIGGER GaliNeo_ASPPROFILE_Update  ON [dbo].[aspnet_Profile] FOR INSERT, UPDATEAS DECLAR @sPostalCode varchar(5) DECLARE @sUserId char(100)DECLARE @iUserId intDECLARE @sUserName nvarchar(50) /*die aktuelle UserId ermittlen, die vom update betroffen ist */select @sUserId=Userid from inserted /*Benutzername aus der Tabelle ermittlen, damit die DNN-UserId ermittelt werden kann*/SELECT @sUserName = [UserName] FROM ASPNET_USERS WHERE [UserId] = @sUserId /*Die DNN-UserId wird ermittlet */SELECT @iUserId = [UserId] FROM Users WHERE [UserName] = @sUserName /*Ermitteln der geänderten Daten direkt aus der Orginaltabelle */SELECT @sPostalCode=dbo.fn_GetProfileElement('PostalCode',PropertyNames,PropertyValuesString)FROM ASPNET_PROFILE WHERE [USERID] = @sUserId   IF ((SELECT count(*) FROM GaliNeo_User_Profile WHERE [UserId] = @iUserId)= 0)begin INSERT INTO GaliNeo_User_Profile ( [UserId], [PostalCode], ) VALUES ( @iUserId, @sPostalCode, )endelsebegin  UPDATE GaliNeo_User_Profile SET  [PostalCode] = @sPostalCode  WHERE [UserId] = @iUserId end    

Der beruehmte Satz mit "x" ....

Mal wieder das alte Problem der Suche in einem Benutzerprofil in DotNetNuke..... zuerst sah die ganze Geschichte noch recht brauchbar aus, allerdings wird das unter "Druck" ziemlich langsam. Eine Suchanfrage dauert da schon mal 8 Sekunden und das um gerade mal 10 - 15 Datensätze zu ermittlen. Ich finde das ist nicht akzeptable, zumal ich jetzt noch mit keiner großen Datenmengen > 30.000 arbeite. Also hat sich mein Verdacht bestätigt, dass die Lösung einfach nicht performant genug ist. Das ermittlen der benötigten PLZ geht recht schnell, nur leider dann das zerpflücken der Daten aus der Tabelle ASPNET_PROFILE dauert und dauert. Nun hier kann man aber dem guten SQL-Server keine Schuld geben, für das was dort passiert ist er immer noch verdammt gut  ;-) Na jetzt muss aber eine andere Lösung her damit DotNetNuke bzw. meine Lösung hier etwas mehr Spaß macht! Meine Idee ist jetzt einfach mit einer redundanten Tabelle zu arbeiten, in denen ich die Daten aus der Tabelle ASPNET_PROFILE speichere. Um aber dafür nichts im Core-Bereich zu modifzieren, werde ich versuchen die Daten via Trigger in die neue Tabelle zu schreiben. Ob mir das geklingt und wie das wird .. na klar, gibt es hier auf dieser Welle!

Löschen von permanente Module in DotNetNuke

So, nachdem ich das erste Modul zur Sortierung von den wie ich sie getauft habe "permanten Modulen" fertig hatte, habe ich mich an das nächste gemacht. Schon mal versucht ein solches Modul wieder aus dem Portal bzw. aus einzelenen Seiten zu entfernen? Herzlichen Glückwunsch, so billig können Aushilfskräfte gar nicht sein ;-) Also musste ein Admin-Modul her, womit ich ein solches Modul schnell entfernen kann. Der Ablauf ist recht simpel, man wählt das Modul aus, bekommt eine Liste mit allen Seiten und wählt dann aus ob auf allen oder nur auf bestimmten Seiten, das Modul gelöscht werden soll. Mein nächstes Vorhaben ist etwas kniffliger, denn ich möchte das nach dem Erstellen / Hinzufügen einer Seite, diese direkt alle permanten Module so konfiguriert, wie auf einer "Schablone" definiert.Ja natürlich kopiert DNN die Module auf die neue Seite, aber leider ist die Sortierreihenfolge immer falsch bzw. wird auf -1 gesetzt und das eine oder andere Mal hatte ich auch trouble mit den Skins. Die Kunst ist hierbei natürlich nicht in den Core einzugreifen... mal schauen wie das wird....

Loesung: Suchen in der ASPNET_PROFILE Table / DotNetNuke Profil

So, nach ein wenig google etwas Arbeit habe ich jetzt ein Lösung gefunden, die sogar recht performant aussieht. Zunächst noch ein paar Basics: Die Tabelle ASPNET_PROFILE beinhaltet folgende Felder: UserId PropertyNames PropertyValuesString PropertyValuesBinary LastUpdatedDate Das Feld PropertyNames beinhaltet eine mit ":" separierte Zeichenfolge, die definiert welche Benutzereigenschaften / -properties gespeichert werden. Zusätzlich wird die Position dort angegeben. Ein Beispiel: FirstName:S:39:7 Dieser (Teil-)Eintrage besagt das die Property den Namen "FirstName" hat, vom Typ String "S" ist, an der Postion 39 anfängt und 7 Zeichen lang ist. Um nun einzelene Daten zur extrahieren, habe ich mir eine die Funktionalität der UDF (User Defined Functions) vom Microsoft SQL Server bzw. der MSDE zu nutze gemacht. Diese Funktionen können direkt aus SQL-Statements aufgerufen werden. CREATE FUNCTION dbo.GaliNeo_UDF_GetElement(@ord AS INT,@strToParse AS VARCHAR(8000),@seperator AS VARCHAR(1) )RETURNS INTASBEGIN   -- Wenn die Eingabeparatemer null sind, wird auch null zurück gegeben  IF  @strToParse IS NULL      OR LEN(@strToParse) = 0      OR @ord IS NULL      OR @ord < 1       OR @ord > LEN(@strToParse) - LEN(REPLACE(@strToParse, @seperator, '')) + 1    RETURN NULL   DECLARE @ipos AS INT, @curord AS INT   SELECT @ipos = 1, @curord = 1   -- nächsts Element suchen  WHILE @curord < @ord    SELECT      @ipos    = CHARINDEX(@seperator, @strToParse, @ipos) + 1,      @curord = @curord + 1  RETURN    CAST(SUBSTRING(@strToParse, @ipos, CHARINDEX(@seperator, @strToParse + @seperator, @ipos) - @ipos) AS INT)END Die GaliNeo_UDF_GetElement ist eine sehr allgemein Funktion um mit separierte Strings in SQL-Queries zu arbeiten. Sehr hilfreich war dabei ein Artikel auf der Seite WindowsItPro. Diese Funktion können wir nun in der eigentlichen UDF "GaliNeo_UDF_GetProfileElement" nutzen: CREATE FUNCTION dbo.GaliNeo_UDF_GetProfileElement(@fieldName AS NVARCHAR(100),@fields AS NVARCHAR(4000),@values AS NVARCHAR(4000))RETURNS NVARCHAR(4000)ASBEGIN   IF  @fieldName IS NULL      OR LEN(@fieldName) = 0      OR @fields IS NULL      OR LEN(@fields) = 0      OR @values IS NULL      OR LEN(@values) = 0    RETURN NULL DECLARE @fieldNameToken AS NVARCHAR(20)DECLARE @fieldNameStart AS INTEGER, @valueStart AS INTEGER, @valueLength AS INTEGER SET @fieldNameStart = CHARINDEX(@fieldName + ':S',@Fields,0) IF @fieldNameStart = 0 RETURN NULLSET @fieldNameStart = @fieldNameStart + LEN(@fieldName) + 3 SET @fieldNameToken = SUBSTRING(@Fields,@fieldNameStart,LEN(@Fields)-@fieldNameStart) SET @valueStart = dbo.GaliNeo_UDF_GetElement(1,@fieldNameToken,':')SET @valueLength = dbo.GaliNeo_UDF_GetElement(2,@fieldNameToken,':') IF @valueLength = 0 RETURN '' RETURN SUBSTRING(@values, @valueStart+1, @valueLength)END Aus einer SQL Query kann jetzt diese Funktion wie folgt genutzt werden:SELECT dbo.GaliNeo_UDF_GetProfileElement('PostalCode',PropertyNames,PropertyValuesString) FROM aspnet_Profile So, das tat doch mal wieder fast nicht weh und bei 10.000 Profilen ist es von der Performance noch in Ordnung. Mal schauen wie es sich verhält, wenn man etwas mehr Daten in er DB hat.  

Erweiterte <strong>DotNetNuke Benutzerprofile</strong>

Ich habe ein Modul geschrieben, dass es einem Portalbenutzer erlaubt mehr über sich zu verraten. Dabei nutze ich zum einen die von DNN Core-Team eingesetzt Whidby Implementierung um verschiedene Daten abzuspeichern. Jetzt wollte ich noch eine Suche programmieren mit der Möglichkeit sich alle Benutzer im Umkreis von x-KM anzeigen zu lassen (also eine klassische Umkreissuche). Nach einer langen Nacht, ziemlich viel Mathe (oh man studiere ich etwa wieder -)) und google ist die Umkreissuche aus kein Thema.Aber wie komme ich nun an die PLZ der einzelnen Benutzer ran. Diese sind mit allen anderen Informationen wie Stadt, Telefon, usw. in einem Text-Feld gespeichert. Ich hoffe nicht, dass ich jetzt jedes Textfeld zerlegen muss um an die PLZ zu kommen. Das macht bei mehrere zehntausend Profilen keinen Spaß :(Eine weiter Idee ist mir gekommen, dass ich beim speichern der Profile einen Trigger anwerfe der die PLZ in eine neue Tabelle schreibt. Frage: Wer hat sich so eine Form der Datenspeicherung einfallen lassen????? Weiter Infos und die Lösung dieses Problems gibt es hier im Block....

Fertig: DotNetNuke permanente Module

So, jetzt ist das Admin-Modul online und wird beim Kunden getestet. Bei der Entwicklung sind mir noch ne ganze Menge mehr Szenarien eingefallen, die man bei der Verwaltung von DNN - Modulen einstetzen kann z.B.:Schon mal versucht ein permanantes Module zu löschen? Okay, bei 10 Seiten geht das noch aber bei größeren Portalen macht das wirklich keinen Spaß! Werde mich damit in den nächsten Wochen nach und nach befassen und hoffe somit das DotNetNuke noch besser zu administrieren sein wird. Nicht das DNN schlecht wäre aber es handelt sich halt um ein universelles System. Die Basis von DotNetNuke ist einfach klasse und das Potential sehr groß!  

DotNetNuke permanente Module

Na da habe ich doch wieder etwas entdeckt, was an DotNetNuke nicht so super toll funktioniert bzw. schwer zu handel ist. Bei einem Projekt habe ich eine zweite Navigation aufgebaut, die ich mit dem Link-Modul realisiert habe. Diese Module bzw. die Container sollen jetzt auf allen Seiten erscheinen - gut das ist kein Problem, denn DotNetNuke bietet mir ja die Möglichkeit in den Moduleoptionen dieses zu definieren "Show on all Tabs". Das macht DotNetNuke auch ganz brav, nur leider wird die Reihenfolge der einzelnen Module, immer etwas nach dem Zufallsprinzip ermittelt. Aus diesem Grund habe ich mich heute Abend hingesetzt um für solche Anwendungsfälle ein Modul zu entwicklen, dass die Reihenfolge eines Modul auf allen Seiten neu setzt. Zunächst wählt man ein Modul und bekommt anschließend eine Liste mit allen Tabs auf denen das Modul angezeigt wird. Nun hat man die Möglichkeit entweder für jedes Tab einzeln eine neue Platzierung anzugeben oder aber für alle Tabs auf einmal. Natürlich ist das nicht ganz ungefährlich, da es ja auch durch aus sein, dass hier Konflikte auftreten können, wenn ein einzelnes Modul zwischen den permanten Modulen exisitert. Allerdings wird dieser Anwendungsfall im ersten Schritt bewußt auser Acht gelassen. Derzeit (also im aktuellen Projekt) kommt es halt nicht vor. In diesem Modul steckt mit Sicherheit noch einiges an Potential, um die Usability von DNN zu verbessern ... Hoffe das ich morgen die ersten Ergebnisse und die Reaktion von DotNetNuke berichten kann...

DotNetNuke 3.0.12

Nach langem warten ist es endlich so weit, die Portalsoftware DotNetNuke wurde in der Version 3.0.12 freigegeben und diesmal ohne ein lästiges "Beta" dahinter! Zudem hat das Core-Team eine Erweiterung der Modul-Palette angekündigt. Darauf darf man sehr gespannt sein!