SharePoint Site programmatisch generieren/verändern

Andi Fandrich Als Antwort am 10 Feb. 2014 16:17

Klar geht das und zwar mit mehreren Möglichkeiten.

Die einfachste Methode ist, eine eigene Vorlage zuerstellen (mit Inhalt speichern) und dann die Sites aus dieser Vorlage erstellen.

Die nachhaltigste Methode ist ein eigenes Feature. Listenelemente lassen sich dann deklarativ im XML erzeugen. Dokumente können als <Module> bereitgestellt werden.

Die schlampigste Methode ist es einfach alles per Code zu erzeugen.

Oddball Als Antwort am 17 Feb. 2014 15:06

Danke für die rasche Antwort - das hilft mir sehr weiter! (Auch, wenn meine Antwort jetzt unvorhergesehen etwas länger auf sich hat warten lassen)

Ich hatte gehofft, es auf eine solche Weise lösen zu können. Hättest du vielleicht ein Codebeispiel (oder einen Link zu einem entsprechenden Tutorial) parat, in welchem erläutert wird, wie man eine eigene Vorlage erstellt?

LG

Andi Fandrich Als Antwort am 17 Feb. 2014 15:28

Bitteschön: http://msdn.microsoft.com/en-us/library/ee231576(v=vs.100).aspx

Die Vorlage an sich ist aber das kleinste Problem. Sinnvollerweise erstellt man sich passende Features, die die eigentliche Arbeit machen. Die Vorlage referenziert nur diese Features.

Oddball Als Antwort am 17 Feb. 2014 16:03

Danke für den Tipp! Ich werde den Link mal durchgehen.

Oddball Als Antwort am 28 März 2014 15:31

So - ich entstaube den Thread mal wieder ein wenig. Ich hab' mich in der letzten Zeit durch diverse Tutorials inner- wie außerhalb von MSDN gearbeitet und denke, dass ich bereits prinzipiell auf der richtigen Spur bin, habe allerdings immer noch einige Schwierigkeiten mit der anfangs von mir genannten Problemstellung.

Ich möchte eine Site erstellen (und dieser dann z.B. Listen hinzufügen - zuerst geht es mir allerdings nur um die Site), indem ich eine XML-Vorlage verwende.

Der Punkt ist nun der: Das ganze soll vollkommen programmatisch ablaufen, ohne, dass man nebenbei auf SharePoint Designer oder das Interface im Browser zurückgreift - aber genau letzteres ist leider bei vielen der MSDN-Tutorials der Fall.

Prinzipiell sollte das ganze also lediglich zwei Schritte in Anspruch nehmen:

1. Das Erstellen der XML-Vorlage für die Site

2. Das programmatische Erstellen der Site mittels der Vorlage

Daher nun noch einmal explizit nachgefragt: Wie stelle ich das nun an? Ich muss gestehen, im Augenblick ein wenig ratlos zu sein. (Sollte der Punkt von Relevanz sein: Ich nutze Visual Studio 2012)

Viele Grüße

Andi Fandrich Als Antwort am 28 März 2014 16:08

[quote user="Oddball"]1. Das Erstellen der XML-Vorlage für die Site[/quote]

Wie stellst Du Dir das vor? Sollen die Benutzer später irgendwie eigene Vorlagen erstellen können? Oder möchtest nur Du per Visual Studio Vorlagen bauen (was deutlich einfacher ist)?

[quote user="Oddball"]2. Das programmatische Erstellen der Site mittels der Vorlage[/quote]

Auch hier die Gegenfrage: wie soll es denn später ablaufen? Auf Button-Klick? Denkbar wäre auch, daß der Benutzer einen Eintrag in eine Liste macht und ein programmierter EventReceiver erstellt dann die Site dazu (und hinterläßt einen Link, wenn er fertig ist). Das kann man ggf. auch mit einem Genehmigungsworkflow verbinden.

Wie auch immer, der Code dazu ist vergleichsweise einfach:
- eine SiteCollection: webApp.Sites.Add(...)
- ein Subweb: web.Webs.Add(...)

Oddball Als Antwort am 31 März 2014 09:13

Zu 1: Mein Gedanke war es, eine vordefinierte Vorlage (mit mehreren Variationen) zu verwenden, entweder bereits als Datei vorliegt oder in Visual Studio erstellt würde - für später hatte ich mit dem Gedanken gespielt, dort mittels eines Formulars in der Anwendung selbst ein paar Variationen zu ermöglichen.

Zu 2: Als ersten Schritt war es geplant, das ganze in ein Programm zu integrieren, welches quasi auf einen Schlag mehrere Sites (gemäß Vorlage) einrichtet - damit man die Weboberfläche mit einem Mausklick erstellt und konfiguriert hat, ohne den langen Umweg über den SharePoint Designer oder das Browser-Webinterface nehmen zu müssen. Für später schwebt es mir derzeit vor, weitere Sites mittels des oben erwähnten Formulars via Button-Klick hinzuzufügen.

Danke für den Hinweis mit den Codeschnipseln! Ich denke, ich bekomme langsam ein Gefühl dafür, wie die Anwendung sich umsetzen lässt.

Andi Fandrich Als Antwort am 31 März 2014 14:37

Ich würde Dir empfehlen das alles in eine Visual Studio Solution zu packen. Darin kannst Du dann meherere eigene Features unterbringen und in deren FeatureActivated-Ereignis auch eigenen Code unterbringen. Per Code kannst Du dann eine eigene Site erzeugen und die Features aktivieren. Dabei wird auch einmalig der Code ausgeführt, der irgendwelche "Nacharbeiten" erledigen kann. Wenn Du mehrere Features machst, kannst Du das dann auch granularer handhaben, z.B. wenn ein Benutzer keinen Kalender möchte, dann wird einfach das Kalender-Feature nicht aktiviert.

Oddball Als Antwort am 1 Apr. 2014 11:06

Eine Lösung via Visual Studio war bisher auch meine bevorzugte Herangehensweise. :-)

Ich fürchte allerdings, beim Aufbau einer solchen Solution hapert es bei mir noch ein wenig - mein Problem liegt dabei in der Kombination der einzelnen Aspekte dieses Anwendungsteils: Einerseits muss die Seite definiert werden (also braucht man eine lauffähige Sitedefinition) und andererseits den Code, welcher auf Basis dieser dann die Site erstellt. Aber wie bringe ich beides in einer Lösung unter? Bisher habe ich die Sitedefinitions immer eigenständig in SharePoint erstellt und dann manuell bereitgestellt - genau das würde dann der Idee eines einzigen "Installers" aber zuwiderlaufen.

Von daher: Gibt es eine Möglichkeit, die notwendigen Templates, anhand welcher später die Seiten erstellt werden sollen, in einer SharePoint-Anwendung sowohl programmatisch zu erstellen, als auch bereitzustellen?

Andi Fandrich Als Antwort am 1 Apr. 2014 12:32

Das sollte nicht das Problem sein: man kann beliebig viele Features in einer einzigen SharePoint-Solution (WSP) unterbringen.

Du kannst also ein oder mehrere Features haben, die sich um die "Steuerungs-Site" kümmern, also um die Site, über die Benutzer später neue Sites anlegen. Ob Du wirklich eine eigene Sitedefinition machen möchtest, mußt Du selbst wissen. In jedem Fall solltest Du den eigentlichen Inhalt auch wieder in Features packen. Du kannst dann eine neue Site anlegen und dabei entweder Deine eigene Sitedefinition benutzen oder z.B. auch die vordefinierte "Blank Site". Jetzt aktivierst Du einfach die notwendigen Features und die erledigen den Rest.

Oddball Als Antwort am 3 Apr. 2014 12:53

Danke für den Tipp! Eine eigene Sitedefinition hatte ich bisher angedacht, ja.

Die Frage ist jetzt nach der Umsetzung: Wie kann ich die Inhalte der Sitedefinition in die einzelnen Features integrieren? Bisher war es nämlich eher so, dass die Sitedefinitions als einzelner Unterpunkt im Projektmappen-Explorer (also auf einer Ebene mit Ordnern wie Verweise, Features, Package, etc.) abgelegt waren, weil dies als Teil des in MSDN empfohlenen Sitedefinition-Projektes offenbar immer so gehandhabt wird.

Nun will ich ja ein Projekt erstellen, welches ein Feature zum Erstellen der Site besitzt, sowie eines oder mehrere Features mit der Sitedefinition und deren Inhalten - Als Grundgerüst verwende ich lediglich ein leeres SharePoint 2010-Projekt aus den VS2012-Vorlagen. Ich muss zugeben, dass ich mit Features bisher noch nicht gearbeitet habe - wo setzt man da nun an?

Andi Fandrich Als Antwort am 3 Apr. 2014 15:57

[quote user="Oddball"]ich mit Features bisher noch nicht gearbeitet habe - wo setzt man da nun an?[/quote]

Das sind natürlich notwendige Grundlagen, die Du Dir wirst aneignen müssen. Ich würde Dir vorschlagen, das alles erstmal mit Testsolutions zu machen. Lege ein neues SharePoint-Projekt an und gib ihm erstmal nur eine Liste oder nur einen Inhaltstyp. Lerne das jeweilige Element kennen und spiele mit den Optionen herum, bis Du weißt, wie man sowas per Feature bereitstellt.

Erst dann setzt Du das ganze in einem großen Projekt um. Wie Du das innerhalb Visual Studio strukturierst ist dabei einigermaßen egal. Hauptsache Du kommst damit klar. Visual Studio legt neue Elemente wie Listen immer in einen Unterordner, aber den direkt in den Projektordner. Du kannst problemlos eigene Ordner erstellen und die Ordner von Visual Studio dort hineinschieben. Das tut der Funktion keinen Abbruch.

AlexNitter Als Antwort am 10 Apr. 2014 16:05

Hallo,

da ich derzeit an der selben Thematik arbeite möchte ich meine Erfahrungen gerne teilen:

bei meinem Projekt geht es darum, für jeden Kunden eines bestimmten Produkts eine eigene Website mit vordefinierten Listen und Bibliotheken bereitzustellen.

Da ich persönlich das Erstellen eines kompletten Website-Templates inklusive aller zugehörigen Listen und Layout-Anpassungen über Visual Studio als extrem aufwendig und unflexibel empfinde, habe ich mich für einen anderen Weg entschieden.

Für die Website-Vorlage habe ich über die SharePoint-Oberfläche eine Website erstellt, wie sie für die Kunden bereitgestellt werden soll. Ich habe über die Oberfläche die Listen definiert und das Layout der einzelnen Seiten angepasst. Für zusätzliche Funktionalität (z.B. diverse Event-Receiver für die Listen und zusätzliche Ribbon-Buttons) habe ich mit Visual Studio ein Feature entwickelt, welches auf der Website aktiviert wird. Daraufhin habe ich daraus eine Website-Vorlage erstellt. Den Namen der Vorlage habe ich in einer Konfig-Liste in der Root-Website hinterlegt.

Das Erstellen der Website wird über einen Event-Receiver in der Kundenliste der Root-Website angetriggert. Wenn ein neuer Eintrag hinzugefügt wird, wird der Event-Receiver gefeuert. Dieser liest den Template-Namen aus der Konfig-Liste aus und erzeugt anhand des neuen Eintrags und des Template-Namen eine neue Website.

Damit bin ich bis jetzt sehr gut gefahren. Wenn ich eine Änderung an dem Template habe, kann ich diese einfach an der Oberfläche vornehmen und die Website erneut als Template speichern und muss nicht die komplette Solution anpacken und neu bereitstellen.

Andi Fandrich Als Antwort am 10 Apr. 2014 16:21

[quote user="AlexNitter"]Da ich persönlich das Erstellen eines kompletten Website-Templates inklusive aller zugehörigen Listen und Layout-Anpassungen über Visual Studio als extrem aufwendig und unflexibel empfinde[/quote]

Du hast Recht, es ist etwas aufwendiger, lohnt sich aber meiner Meinung nach.

Wenn Du eine Website über den Browser als Vorlage speicherst, wird daraus auch eine WSP-Datei (im Vorlagenkatalog). Diese Datei ist auch nichts anderes als eine SharePoint Solution und enthält Features für die Listen usw. Diese WSP kann man in Visual Studio importieren und dort beliebig verändern und erweitern. Man muß also nicht alles manuell erzeugen.

Der größte Vorteil einer Visual Studio Lösung liegt für mich in der Upgradefähigkeit. Wenn man später feststellt, daß noch irgendwas in alle bereits erstellten Websites muß, ist das durch eine Erweiterung der Solution kein Problem. Wenn die Websites aber aus vielen verschiedenen Templates erzeugt wurden, ist es ein Problem.

Edit: trotzdem natürlich Danke für den Beitrag. Die beschriebene Vorgehensweise kann für manchen ja die Lösung sein.

AlexNitter Als Antwort am 10 Apr. 2014 16:42

Das Thema Upgrade-Fähigkeit ist absolut berechtigt. Da sollte man sich im Vorfeld einige Gedanken zu machen, was für Anforderungen im laufenden Betrieb an die Lösung gestellt werden (könnten).

Ich habe dies aber etwas anders gelöst: sämtliche Listen-Definitionen entspringen einem Inhaltstyp, der in der Root-Website angelegt wurde. Von daher brauche ich, wenn ich Änderungen an den Listen vornehmen möchte, einfach nur einmlig den Inhaltstyp ändern. Und falls ich sonstige Änderungen habe brauche einfach nur das Feature für die Kunden-Websites aktualisieren neu deployen.

Ich finde die Idee, eine Website-Vorlage über das Studio zu erstellen und so die ganze Geschichte per Klick deployen zu können durchaus charmant. Wenn ich mir aber anschaue, wie viele Änderungen ich an dem Template im Laufe der Entwicklungsphase machen musste - seien es nur kleinste Änderungen wie Text-Anpassungen oder kleine Layout-Geschichten - läufts mir bei dem Gedanken, dies alles im Studio tippen zu müssen, eiskalt den Rücken runter. Und bevor ich mir den Aufwand mache, jedes Mal die Änderungen über die Oberfläche zu machen, dies als Template zu speichern, die generierte wsp zu nehmen und im Studio zu importieren - dann finde ich es komfortabler, die Vorlage einfach dort zu lassen und einfach über den Namen zu referenzieren.