Hallo,
ich hatte heute eine Anforderung, dass ich Benutzern nach Bearbeiten eines Dokumentes eine Zusammenfassung anzeigen musste.
Beim Updaten des Dokumentes wurden einige SPLists mit den Werten des Dokumentes synchronisiert, und Fehler etc sollten dem Benutzer mitgeteilt werden.
Nun konnte ich in diesem Fall nur den asynchronen EventHandler ItemUpdated verwenden.
Dumm nur, dass in diesem kein HttpContext zur Verfügung steht, den ich zum Redirecten benötige.
Glücklicherweise habe ich eine Lösung gefunden, welcher aber nur sicher funktioniert, wenn nicht mehrere Benutzer gleichzeitig Dokumente in dieser Liste updaten...ein Glück das es bei mir so ist :)
Hier der Code:
Hier könnte man noch überlegen ob man mit Locks auch die "Threadsicherheit" herstellt....allerdings werden dann die asynchronen Eventhandler synchron. Und an dem Punkt sieht man, dass dieser Workaround nur in Sharepoint 2007 sinnvoll ist, da man in Sharepoint 2010 die Eventhandler auf synchron stellen kann, und somit auch der Context zur Verfügung steht.
Ich hoffe das hilft dem einen oder anderen.
Sebastian
Donnerstag, 11. August 2011
Montag, 8. August 2011
Specification mit Linq to Sql
Hallo,
in einem meiner letzten Projekte habe ich mir eine einfache Datnzugriffs und Domänenschicht mit Linq2Sql erstellt. Dazu ein Repository zum Zugriff auf die Domänenobjekte. Eine Anforderung war, Objekte nach ganz unterschiedlichen Filterkriterien aus der Datenbank zu holen.
Welche Möglichkeiten gibt es dafür? Natürlich könnte ich für jede Suchabfrage eine Methode schreiben, das würde allerdings zu einem enormen Anstieg der Methodenzahl führen, und die Übersicht verabschiedet sich.
Ja in C#3.0 könnte man dem mit optionalen Parametern entgegen wirken, aber der Aufruf der Datenschicht wäre trotzdem unschön.
Ich könnte DynamicLinq verwenden, aber strings gefallen mir auch nicht so gut.
Nein ich habe mich für das Specification-Pattern entschieden (oder zumindest eine Art davon ;), und will euch hier kurz zeigen, wie das aussieht:
Natürlich erzeugt man sich erstmal wie gewohnt ein LinqModell (PitContentIndexes bei mir).
Danach ein Interface für eine Specification:
Durch den Einsatz von Expression ist der Linq-DataContext in der Lage, den in Code geschriebenen Filter nach SQL zu übersetzen.
Eine Specification um nach einer Produkt- ID zu Filtern, sieht so aus: (ProductID muss im LinqModel vorhanden sein)
Um das Pattern sinnvoll anwenden zu können, benötigen wir noch ein Repository, an welches wir die Specifications schicken können: (das ist nur der wichtige Ausschnitt aus meinem Repository)
Hier sieht man gut, wie man den Filter der Specification einfach an die Where-Methode des LinqModels übergeben kann. Der Filter wird erst auf der Datenbank ausgeführt.
Nun brauchen wir noch einen Service um die Specification nach den Suchanfragen/UseCases zu erstellen und an das Repository zu reichen:
Wie man sieht, ist es eine relativ einfache Sache ist, ein einfaches Specification-Pattern mit Linq2Sql umzusetzen.
Sebastian :)
in einem meiner letzten Projekte habe ich mir eine einfache Datnzugriffs und Domänenschicht mit Linq2Sql erstellt. Dazu ein Repository zum Zugriff auf die Domänenobjekte. Eine Anforderung war, Objekte nach ganz unterschiedlichen Filterkriterien aus der Datenbank zu holen.
Welche Möglichkeiten gibt es dafür? Natürlich könnte ich für jede Suchabfrage eine Methode schreiben, das würde allerdings zu einem enormen Anstieg der Methodenzahl führen, und die Übersicht verabschiedet sich.
Ja in C#3.0 könnte man dem mit optionalen Parametern entgegen wirken, aber der Aufruf der Datenschicht wäre trotzdem unschön.
Ich könnte DynamicLinq verwenden, aber strings gefallen mir auch nicht so gut.
Nein ich habe mich für das Specification-Pattern entschieden (oder zumindest eine Art davon ;), und will euch hier kurz zeigen, wie das aussieht:
Natürlich erzeugt man sich erstmal wie gewohnt ein LinqModell (PitContentIndexes bei mir).
Danach ein Interface für eine Specification:
Durch den Einsatz von Expression ist der Linq-DataContext in der Lage, den in Code geschriebenen Filter nach SQL zu übersetzen.
Eine Specification um nach einer Produkt- ID zu Filtern, sieht so aus: (ProductID muss im LinqModel vorhanden sein)
Um das Pattern sinnvoll anwenden zu können, benötigen wir noch ein Repository, an welches wir die Specifications schicken können: (das ist nur der wichtige Ausschnitt aus meinem Repository)
Hier sieht man gut, wie man den Filter der Specification einfach an die Where-Methode des LinqModels übergeben kann. Der Filter wird erst auf der Datenbank ausgeführt.
Nun brauchen wir noch einen Service um die Specification nach den Suchanfragen/UseCases zu erstellen und an das Repository zu reichen:
Wie man sieht, ist es eine relativ einfache Sache ist, ein einfaches Specification-Pattern mit Linq2Sql umzusetzen.
Sebastian :)
Donnerstag, 4. August 2011
Sharepoint: Zwischenspeichern in nichtmodalen Dialogen
Ich stand letztens vor dem Problem, dass ich eine Art Zwischenspeicherung der EditForm.asp benötigte.
Also suchte und suchte und suchte ich und fand auch einige Lösungswege.
Der einfachste Weg ohne großartige Programmierung geht über den Sharepoint Designer.
Also öffnet den Designer und wählt die Liste, dessen EditForm ihr um den neuen Button zum Zwischenspeichern erweitern wollt.
Öffnet danach die EditForm.aspx im erweiterten Überarbeitungsmodus.
Hier müsst Ihr nun das vorhandene ListViewWebpart ausblenden: (nicht entfernen, sonst funktioniert das ganze aus irgendeinem Grund nicht)
Dann klickt Ihr in den Bereich darüber, und fügt ein benutzerdefiniertes Listenformular hinzu:
Dieses Formular kann man nun nach belieben anpassen, auch Buttons einfügen ;)
Also hauen wir einen eigenen Speichernbutton dazu, welcher speichert und danach diese Seite wieder öffnet:
Die systemseitige Methode ddwrt:GenFireServerEvent('___commit;___redirect{}') speichert das aktuelle ListItem und ruft danach die Seite wieder auf.
Das ist meiner Meinung nach die einfachste Methode, allerdings kann man diese JavaScript-Methode auch in einer CustomAction aufrufen.
Weiter besteht die Möglichkeit eine eigene Klasse zu schreiben, welche von SaveButton ableitet, aber all diese Methoden haben mehr Programmieraufwand zur Folge.
Wenn dazu jemand ein Beispiel möchte, steh ich dazu gern zur Verfügung ;)
Für modale Dialoge muss man sich dann schon AJAX bedienen. Dazu werde ich in Zukunft auch ein Beispiel posten.
Soweit erstmal ;)
Also suchte und suchte und suchte ich und fand auch einige Lösungswege.
Der einfachste Weg ohne großartige Programmierung geht über den Sharepoint Designer.
Also öffnet den Designer und wählt die Liste, dessen EditForm ihr um den neuen Button zum Zwischenspeichern erweitern wollt.
Öffnet danach die EditForm.aspx im erweiterten Überarbeitungsmodus.
Hier müsst Ihr nun das vorhandene ListViewWebpart ausblenden: (nicht entfernen, sonst funktioniert das ganze aus irgendeinem Grund nicht)
Dann klickt Ihr in den Bereich darüber, und fügt ein benutzerdefiniertes Listenformular hinzu:
Dieses Formular kann man nun nach belieben anpassen, auch Buttons einfügen ;)
Also hauen wir einen eigenen Speichernbutton dazu, welcher speichert und danach diese Seite wieder öffnet:
Die systemseitige Methode ddwrt:GenFireServerEvent('___commit;___redirect{}') speichert das aktuelle ListItem und ruft danach die Seite wieder auf.
Das ist meiner Meinung nach die einfachste Methode, allerdings kann man diese JavaScript-Methode auch in einer CustomAction aufrufen.
Weiter besteht die Möglichkeit eine eigene Klasse zu schreiben, welche von SaveButton ableitet, aber all diese Methoden haben mehr Programmieraufwand zur Folge.
Wenn dazu jemand ein Beispiel möchte, steh ich dazu gern zur Verfügung ;)
Für modale Dialoge muss man sich dann schon AJAX bedienen. Dazu werde ich in Zukunft auch ein Beispiel posten.
Soweit erstmal ;)
Abonnieren
Posts (Atom)







