SharePointCommunity
Die deutschsprachige Community für SharePoint, Microsoft 365, Teams, Yammer und mit Azure

Sponsored by

Willkommen im Forum Archiv.
Einträge sind hier nicht mehr möglich, aber der Bestand von 12 Jahren SharePoint-Wissen ist hier recherchierbar.




SharePoint Server 2010 -> 2019 Umstellung - Einige Grundlegende Fragen zu Modern View, formula und Lookup Spalten in PnP

Unbeantwortet Dieser Beitrag hat 1 Antworten

Ohne Rang
282 Beiträge
MStel erstellt 12 Sept. 2019 13:39
SchlechtSchlechtIn OrdnungIn OrdnungDurchschnittDurchschnittGutGutSehr gutSehr gut

Hallo,

ich habe leider noch keine Kategorie für SP2019 gefunden, in die ich rein posten könnte, deshalb hoffe ich, dass es nicht unangebracht ist, wenn ich hier trotzdem frage.

Wir haben nämlich den Quantensprung von 2010 auf 2019 gewagt und meine Arbeitsumgebung hat sich dadurch grundlegend geändert, wobei das Objektmodell ja größtenteils unberührt blieb.

Meine bisherige Arbeitsweise war recht simpel, ich habe mit PowerShell Skripten meine Infrastruktur mit Listen, Spalten, Ansichten etc. aufgebaut und sobald es etwas komplizierter wurde, habe ich über einen Content Editor Webpart eben Javascripte mit jquery und css verwendet um Daten oder deren Darstellung zu manipulieren, um den Ansprüchen meiner User gerecht zu werden.

In der 2019er Umgebung habe ich jetzt PnP für mich entdeckt, was größtenteils den PowerShell Part von früher abdeckt, und kann die grundlegendsten Dinge damit auch schon lösen.

Einige Dinge funktionieren jedoch noch nicht so ganz.

1. Bietet SP2019 ja eine Unterscheidung zwischen der klassischen und der modernen Ansicht, um nach wie vor auf meinen Formularen Webparts hinzufügen zu können, muss ich jedoch in die klassische Ansicht wechseln, und sobald diese in irgendeiner Form schon mal bearbeitet wurde und nicht mehr der "vanilla" seite entspricht, ist ein Wechsel in die Moderne Ansicht zurück nicht mehr möglich.
Also möchte man in Sp2019 offensichtlich vermeiden, Webparts in die modernen seiten hinzuzufügen(zumindest auf den allitems/newform/editform etc. einer Liste), was bei meinen Anforderungen allerdings ein kompletter Dorn im Auge ist, da ich auf Javascripte innerhalb der Formulare angewiesen bin. Gibt es also ohne große Umstände eine saubere Möglichkeit, auch auf diesen Seiten Webparts wie den Content Editor hinzuzufügen?

Falls nein würde mich interessieren, wie groß die Negativ Aspekte, die klassische Ansicht weiterhin zu verwenden gegenüber der modernen Ansicht sind? Wenn es sich lediglich um das Responsive Design handelt wäre das nämlich unproblematisch, da unsere Intranet Anwendungen sowieso mit genormten Bildschirmgrößen und nicht von mobilgeräten aufrufbar sein werden.

2. Die zweite Sache, bei der ich auf Granit gestoßen bin, sind die Formula Felder.
Diese lassen sich in PnP zwar mit Parametern auch mit korrekten Formeln anlegen, allerdings nicht in zusammenhang mit dem -List Parameter, dass bedeutet ich muss um diese zu nutzen eine Websitespalte anlegen, und diese anschließend der Liste zuordnen. Das fände ich eigentlich unsauber und wollte fragen ob ihr eine Idee habt, warum das nicht funktioniert, oder wie ich das lösen kann? Mit allen anderen Field Types funktioniert der -List Parameter nämlich. Und jetzt für alle Spalten eine Websitespalte und einen dazugehörigen Inhaltstyp anzulegen, wenn ich diese doch nur in einer einzigen Liste verwende scheint mir auch nicht sinnvoll.

3. Die Lookup Spalten machen mir auch etwas zu schaffen. Diese kann ich zwar im vergleich zu den Formelfeldern in der korrekten Liste anlegen, allerdings verweisen diese auf Nichts. Mir fehlt quasi die Möglichkeit die LookupList und die LookupColumn zu setzen, laut einigen Code Snippets können diese Problemlos gesetzt werden, bei mir kann ich das leider nicht bestätigen. Die Autovervollständigung in Visual Studio Code gibt einem ja schon eine Übersicht, was mit den einzelnen feldtypen möglich ist, hier habe ich jedoch nichts gefunden was mir irgendwie weiterhelfen kann.
Einmal angelegt kann ich auch übers UI der korrekt angelegten Lookupspalte keine Ziel-Liste und -Spalte mehr zuweisen. Erstelle ich die Spalte schon übers UI funktioniert das wie gewohnt in Sp2010.

Das wären so die wesentlichen Dinge, die mir noch an der Migration auf 2019 zu schaffen machen, vielleicht hat der ein oder andere ja schon Erfahrungen mit SP2019 gemacht und kann mir zumindest teilweise weiterhelfen, das wäre schön. 

Vielen dank im Voraus!
MFG

Alle Antworten

Ohne Rang
19231 Beiträge
Andi Fandrich Als Antwort am 12 Sept. 2019 14:39
SchlechtSchlechtIn OrdnungIn OrdnungDurchschnittDurchschnittGutGutSehr gutSehr gut

PnP: hast Du gesehen, daß es von PnP mehrere Varianten gibt? PnP-PowerShell, PnP für C#, PnP.js, ...

1. MS möchte die serverseitige Entwicklung für SP weiter zurückdrängen und dazu gehören auch die klassischen Webparts. Man kann sie nur auf den klassischen Seiten einsetzen. Dafür gibt es für die Modern Pages SPFx, das rein clientseitig ist. Es gibt auch SPFx-Webparts.

2. Es war in SP eigentlich schon immer Best Practice nur Websitespalten zu verwenden und keine Spalten direkt in Listen anzulegen. Von daher solltest Du Dich einfach auch daran halten. Wenn man z.B. eine Spalte gezielt durchsuchbar machen möchte (Managed Property), geht das nur mit einer Websitespalte.

Zu 3. kann ich nichts sagen.

Viele Grüße
Andi
af @ evocom de
Blog