Listen aus SiteCollection in Sub-Site nutzen

René Fritsch Als Antwort am 2 Juni 2010 13:53

Moin Stefan,

du beschreibst eine geradezu klassische Herausforderung, vor der jeder, der Inhalte in SharePoint zu organisieren hat, früher oder später steht.

Dein Ansatz, die Kontaktdaten sowie News und Projekte zentral abzulegen, ist absolut sinnvoll. Um diese gesammelten Daten gefiltert auf den diversen Sub-Sites anzeigen zu lassen, bieten sich Datenansichten / Data Views an. die du mithilfe des SharePoint Designers erstellen kannst. Wenn du darin ungeübt bist, ist das anfangs eine ziemliche Frickelei, aber der Lohn für die Mühe ist ein Ergebnis, das optisch kaum von einer normalen SharePoint-Liste zu unterscheiden ist (ganz anders als z.B. beim Content Query Web Part).

Es gibt auch diverse kostenpflichtige Tools von Drittanbietern, die z.T. sogar Daten aus mehreren Site Collections aggregieren können. Schau' dir als Beispiele mal die Websites von SharePointBoost sowie KWizCom an.

Falls du dich für die Data Views entscheidest, aber selbst nicht damit zurecht kommst: So etwas gehört zu unserem Dienstleistungs-Portfolio, so dass wir bei Bedarf gern auf Stundenbasis Unterstützung leisten.

Stefan Grobe Als Antwort am 8 Juni 2010 14:43

Hallo René,

danke für die schnelle Antwort und Hilfe!

Leider ist der SharePoint Designer in unserem Unternehmen aus diversen Gründen nicht installiert. Ich bin generell leider auf die Standard-Funktionaltitäten einer SharePoint Team-Site beschränkt und kann auch keine neuen (kostenpflichtigen/kostenfreien) Tools einbinden. Gibt es daher vielleicht auch ohne SharePoint Designer oder Drittanbieter-Tools Wege, an den RSS-Feeds oder Content Queries vorbeizukommen? Wenn nein, gibt es wenigstens Möglichkeiten, die RSS-Feeds oder Queries zu formatieren? Oder geht hier ebenfalls nichts ohne den Designer? :)

Schöne Grüße,

Stefan

Henning Eiben Als Antwort am 9 Juni 2010 11:15

Es gibt schon eine Möglichkeit die Content-Queries zu formatieren, ist nur nicht so ganz simple.

Dazu musst du die ItemStyles.xsl anpassen. Diese liegt im SharePoint in der Style-Library. Hier kannst du per XSLT das Ergebnis deiner Query individuelle Anzeigen lassen.

Eine Anleitung über die Bearbeitung der ItemStyles.xsl findest du z.B. unter http://www.heathersolomon.com/blog/articles/customitemstyle.aspx

Stefan Grobe Als Antwort am 9 Juni 2010 14:11

Vielen Dank für den Link!

Leider ist dies halt wieder nur mit dem SharePoint Designer möglich, oder komme ich auch irgendwie anders an die xsl-Datei? Ansonsten wäre das schon eine gute Lösung...

Gibt es denn keinen anderen Weg, irgendwie auf alle Listenspalten zugreifen zu können?? Ich verzweifel langsam wirklich daran. Ich kann einfach nicht verstehen, wieso es nicht möglich ist, in der Sub-Site genauso mit der Liste zu arbeiten wie in der Site Collection... !

Henning Eiben Als Antwort am 9 Juni 2010 18:25

Was habt ihr denn gegen den SharePoint Designer?

Du kannst die XSL-Datei auch ohne SPD bearbeiten. Du kannst die "einfach" per WebDAV aufrufen. Allerdings musst du die Datei vorher auschecken (also die Liste einmal im Browser öffnen und die Datei auschecken, sonst funktioniert das Speichern nicht).

Stefan Grobe Als Antwort am 10 Juni 2010 09:54

Ich habe gestern auch noch heraus gefunden, dass ich auch ohne Share Point Designer die Design-Anpassungen über die ItemStyle.xls (liegt in der StyleLibrary innerhalb der SiteCollection) durchführen kann. Super!

Henning Eiben Als Antwort am 10 Juni 2010 10:24

Hatte ich ja auch schon angedeutet ... aber: was spricht gegen die Verwendung des SharePoint Designers, insbesondere weil er ja seit letztem Jahr kostenlos erhältlich ist.

Stefan Grobe Als Antwort am 10 Juni 2010 10:46

Wir haben bei uns über 300 produktive Team- und Projektseiten. Der Designer wird wohl bewusst nicht eingesetzt, weil sonst die Gefahr besteht, dass viele Seiten bei einer Migration auf eine höhere SharePoint Version nicht mehr funktionieren würden...

Ich kann selbst nicht einschätzen, ob die Gefahr wirklich bestehen würde...

Henning Eiben Als Antwort am 10 Juni 2010 10:57

OK, ich würde den Designer auch nicht alle Mitarbeitern zur Verfügung stellen - aber PowerUsern, die z.B. Design-Änderungen am Portal machen sollen, sind mit dem SPD deutlich produktiver. Es hat ja auch nicht jeder Benutzer das Recht auf die Style-Library - so könnte man also den Benutzer der standard SharePoint-Gruppe "Designer" durchaus die Verwendung des SPD erlauben.

So erleben wir das auch bei Kundenprojekten, wo die Mitarbeiter den SPD nicht installiert haben, aber die Administratoren/Designer des SharePoint durchaus.

Stefan Grobe Als Antwort am 10 Juni 2010 11:09

Besteht denn die Gefahr, das die Design-Änderungen (bzw. sogar ganze Team-/Projektseiten) bei einer Migration nicht mehr funktionieren könnten?

Ich führe ja letztendlich nun auch Design-Änderungen über die ItemStyle.xls durch...

Henning Eiben Als Antwort am 10 Juni 2010 11:26

Das kommt darauf an, was du machst. Wenn du den Designer verwendest um die ItemStyle.xsl, CSS-Dateien oder MasterPages zu bearbeiten besteht keine Gefahr.

Problematisch wird es, wenn du WebPart-Seiten mit dem SPD bearbeitest und diese dann "unghosted" werden. Das kann zum einen Einfluss auf die Performance des Webs haben und ggf. auch Probleme bei einer Migration machen. Da hilft nur, Seiten nicht zu "unghosten" :) Da kommt man aber ganz gut drum rum.

Durch den SPD gewinnst du auch DataViewer-WebParts, die es ausschließlich im SPD gibt. Mit ein wenig tricksen kannst du auch verhindern, dass die Seiten auf denen du das DVWP verwenden will unghosted werden.

Stefan Grobe Als Antwort am 14 Juni 2010 17:20

Hallo Henning,

danke fuer deine Infos! (mit dem Begriff "unghosted" kann ich aber leider nichts anfangen)

Die Formatierung ueber die ItemStyle.xsl funktioniert bei meiner Kontakt-Liste bis auf eine Ausnahme:

Das Feld "EMail" liefert leider keine Daten, obwohl die Feldbezeichnung meiner Meinung nach korrekt ist. Hast du eine Idee, woran es liegen koennte? Hier ist der kleine Code-Ausschnitt von meinem custom Item Style:

<div class="link-item">
                <xsl:call-template name="OuterTemplate.CallPresenceStatusIconTemplate"/>
                <a href="{$SafeLinkUrl}" target="{$LinkTarget}" title="{@LinkToolTip}">
                     <xsl:value-of select="$DisplayTitle"/>,
                     <xsl:value-of select="@FirstName"/>
                </a>
      <div class="description">
             <xsl:value-of select="@Company"/><br></br>
             <xsl:value-of select="@JobTitle"/><br></br>
             <xsl:value-of select="@EMail"/><br></br>
             <xsl:value-of select="@WorkPhone"/><br></br>
             <br></br>
      </div>

</div>

Vielen Dank fuer deine Hilfe!

Stefan

Henning Eiben Als Antwort am 15 Juni 2010 09:36

[quote user="Stefan Grobe"]

danke fuer deine Infos! (mit dem Begriff "unghosted" kann ich aber leider nichts anfangen)

[/quote]

Vielleicht erkläre ich das aus der anderen Richtung. Die Seiten im SharePoint existieren ja nicht direkt physisch im Dateisystem und schon garnicht für jede URL individuell. Es existiert also nur einmal eine Default.aspx die über eine Reihe von "Platzhaltern" verfügt. Wenn du nun WebParts auf die Seite ziehst, dann merkt sich SharePoint an welche Stelle der Seite welches WebPart gehört. Dies wird als "Ghosted" bezeichnet.

Wenn nun eine Seite mit dem SPD bearbeitet wird, dann wird eine Kopie dieser default.aspx-Vorlage erstellt. Zwar merkt sich SharePoint weiterhin an welche Stelle der Seite welche WebParts gehören, aber er hat zuvor eine neue ASPX-Seite in seiner Datenbank abgelegt, das ist nicht mehr die gleiche ASPX-Seite wie für alle anderen, nicht mit dem SPD bearbeiteten Seiten. Dieses wird als "unghosting" bezeichnet.

[quote user="Stefan Grobe"]

Die Formatierung ueber die ItemStyle.xsl funktioniert bei meiner Kontakt-Liste bis auf eine Ausnahme:

Das Feld "EMail" liefert leider keine Daten, obwohl die Feldbezeichnung meiner Meinung nach korrekt ist. Hast du eine Idee, woran es liegen koennte? [/quote]

Puh, das kann ich so ohne weiteres leider nicht sagen - müsste ich mir mal ansehen. Das schaffe ich aber erst nächste Woche.

Stefan Grobe Als Antwort am 15 Juni 2010 10:58

Ah okay! Also nehme ich an, dass ich durch meine Änderungen an der ItemStyle.xsl noch keine Kopie der default.aspx-Vorlage erstelle..!?

Die anderen Wege, um den Spaltennamen herauszufinden habe ich bereits ausprobiert, leider bin ich mir nicht sicher, ob diese Spaltennamen und vor allem die Datentypen tatsächlich die korrekten sind... über die Schema.xml hätte ich es direkt herausfinden können.

Allerdings möchte ich auch kalkulierte Spalten oder Spalten mit dem Datentyp "Person or Group" einbinden und mir bei den Spalten "Begin" und "End" nur das Datum und nicht die Zeit ausgeben lassen. Ist alles ein wenig schwieriger und anhand der anscheinend nur verfügbaren Datentypen (http://www.heathersolomon.com/blog/articles/customitemstyle.aspx , Punkt 17) wohl gar nicht so einfach möglich..  

Henning Eiben Als Antwort am 15 Juni 2010 11:14

[quote user="Stefan Grobe"]

Ah okay! Also nehme ich an, dass ich durch meine Änderungen an der ItemStyle.xsl noch keine Kopie der default.aspx-Vorlage erstelle..!?

[/quote]

Richtig.

[quote user="Stefan Grobe"]

Die anderen Wege, um den Spaltennamen herauszufinden habe ich bereits ausprobiert, leider bin ich mir nicht sicher, ob diese Spaltennamen und vor allem die Datentypen tatsächlich die korrekten sind... über die Schema.xml hätte ich es direkt herausfinden können.

[/quote]

Dann musst du dich ggf. an dem Server anmelden und das nachsehen :)

[quote user="Stefan Grobe"]

Allerdings möchte ich auch kalkulierte Spalten oder Spalten mit dem Datentyp "Person or Group" einbinden und mir bei den Spalten "Begin" und "End" nur das Datum und nicht die Zeit ausgeben lassen. Ist alles ein wenig schwieriger und anhand der anscheinend nur verfügbaren Datentypen (http://www.heathersolomon.com/blog/articles/customitemstyle.aspx , Punkt 17) wohl gar nicht so einfach möglich..  

[/quote]

Na, Datumsspalten kannst du doch im XSL formatieren: http://panvega.wordpress.com/2008/12/08/ddwrtformatdate-with-different-formatflags/

Henning Eiben Als Antwort am 21 Juni 2010 13:08

[quote user="Stefan Grobe"]

Das Feld "EMail" liefert leider keine Daten, obwohl die Feldbezeichnung meiner Meinung nach korrekt ist. Hast du eine Idee, woran es liegen koennte? Hier ist der kleine Code-Ausschnitt von meinem custom Item Style:

<div class="link-item">
                <xsl:call-template name="OuterTemplate.CallPresenceStatusIconTemplate"/>
                <a href="{$SafeLinkUrl}" target="{$LinkTarget}" title="{@LinkToolTip}">
                     <xsl:value-of select="$DisplayTitle"/>,
                     <xsl:value-of select="@FirstName"/>
                </a>
      <div class="description">
             <xsl:value-of select="@Company"/><br></br>
             <xsl:value-of select="@JobTitle"/><br></br>
             <xsl:value-of select="@EMail"/><br></br>
             <xsl:value-of select="@WorkPhone"/><br></br>
             <br></br>
      </div>

</div>

[/quote]

Ich glaube Email wird mit kleinem "m" geschrieben, und nicht mit einem großen "M" :)

Andi Fandrich Als Antwort am 21 Juni 2010 13:19

[quote user="Henning Eiben"]Ich glaube Email wird mit kleinem "m" geschrieben[/quote]

In meinen SharePoints wird die Standard-Spalte "EMail" geschrieben. Das Problem muß irgendwo anders liegen.

Henning Eiben Als Antwort am 21 Juni 2010 13:32

Hmm, wenn ich bei mir den Internal Field Name ansehe, dann steht da bei mir "Email" und nicht "EMail". Der Display-Name bei einer Kontaktliste ist hingegen "E-Mail-Adresse".

Andi Fandrich Als Antwort am 21 Juni 2010 14:55

Das ist aber seltsam. Ich habe jetzt bei zwei WSS3-Servern nachgesehen und bei beiden ist das M groß geschrieben. Ebenso bei einem MOSS 2007 und bei SharePoint Foundation 2010. Allerdings heißt das Feld auch nur E-Mail (Displayname).

Henning Eiben Als Antwort am 21 Juni 2010 16:50

Also ich habe mal einfach in einer Teamsite eine neue Kontaktliste eingerichtet. Der Feldname ist daraufhin "Email" geworden.

Stefan Grobe Als Antwort am 21 Juni 2010 17:13

Vielen Dank Euch Beiden für die rege Unterstützung!!!

Ich hatte es ehrlich gesagt nicht für möglich gehalten, aber das kleine "m" hat tatsächlich das Problem gelöst. Ich weiß nicht, wo ich das große "M" aufgeschnappt hatte, irgendwo war es jedenfalls hinterlegt. :-)

Vielen, vielen Dank noch einmal!!!

Andi Fandrich Als Antwort am 21 Juni 2010 17:21

Ah, jetzt habe ich es auch gesehen. In einer Kontaktliste heißt das Feld intern tatsächlich Email und wird als E-Mail-Adresse angezeigt. Ich hatte mir immer die entsprechende Websitespalte angeschaut, aber die wird hier ganz offensichtlich nicht verwendet :-(

Henning Eiben Als Antwort am 21 Juni 2010 17:38

Das macht ja auch Sinn, nicht die bereits vorhandene Websitespalte zu verwenden ...

Stefan Grobe Als Antwort am 14 Juni 2010 18:16

Noch eine weitere Frage:

Kennst du ohne den SharePoint Designer eine Möglichkeit, die auf der Seite http://www.heathersolomon.com/blog/articles/customitemstyle.aspx angesprochenen Schema.xml-Dateien aufzurufen? In meiner benutzerdefinierten Projektliste basieren die Spalten nicht auf gängigen Inhaltstypen (Content Types), sondern sie sind ebenfalls benutzerdefiniert. Leider habe ich hier Probleme, die korrekten Spaltennamen und Datentypen herauszufinden...

Danke!

Henning Eiben Als Antwort am 15 Juni 2010 09:31

[quote user="Stefan Grobe"]

Kennst du ohne den SharePoint Designer eine Möglichkeit, die auf der Seite http://www.heathersolomon.com/blog/articles/customitemstyle.aspx angesprochenen Schema.xml-Dateien aufzurufen? In meiner benutzerdefinierten Projektliste basieren die Spalten nicht auf gängigen Inhaltstypen (Content Types), sondern sie sind ebenfalls benutzerdefiniert. Leider habe ich hier Probleme, die korrekten Spaltennamen und Datentypen herauszufinden...

[/quote]

Auf die Schema.xml kannst du IMHO nur direkt auf dem Server zugreifen - per SPD dürfte das nicht funktionieren, weil die ja in dem Features-Verzeichnis liegt, welches nicht via Web zugänglich ist.

Aber in dem Artikel sind doch zuvor auch andere Wege beschrieben, um an den internal Name von Inhaltsspalten heranzukommen.