Nur eine schnelle Beobachtung, dass es ein sehr wichtiger Unterschied zwischen diesen zwei Definitionen ist:

<FieldBind Feld "InParam1 =" DesignerType = "StringBuilder" ID = "2" Text = "Input Parameter # 1" />

im Vergleich:

<FieldBind Feld "InParam1 =" ID = "2" Text = "Input Parameter # 1" />

Die erste zeigt, wie dies in der SPD:

während die letzteren zeigt wie folgt:

Ich bin nicht sicher, wie hilfreich diese Screenshots sind aber ich habe in der Anstrengung, sie zu machen, damit Sie sie sehen haben 🙂

Die Beobachtung ist dies: StringBuilder ermöglicht es Ihnen, eine Zeichenfolge erstellen (offensichtlich) durch das Mischen von Zeichenfolgenliteralen und Workflow-Daten (über die "hinzufügen Lookup" Schaltfläche in der linken unteren Ecke). Wenn Sie die Schaltfläche Hinzufügen Lookup verwenden, Es fügt ein Token in der Form"[%Token %]". Wenn SharePoint Ihre benutzerdefinierte Aktion aufruft, (C#-Code in meinem Fall), SharePoint übergibt das Token selbst, nicht der Wert des Tokens. Wenn Sie den Standard-Designer-Typ verwenden (der zweite Typ), SharePoint erweitert das Token und Istwert des Tokens an Ihrer Aktion.

StringBuilder = schlecht, Standard Designertyp = gut.

Natürlich, Das ist nicht das, was ich wirklich meine. Eben nicht versuchen und einen Parameter an Ihre benutzerdefinierte Aktion übergeben, wenn der Designer geben = StringBuilder. Verwenden Sie der Standardtyp Designer und Kette ein StringBuilder-Objekt darauf nach vorne, wenn Sie komplexe Zeichenfolgen in Ihrem Workflow erstellen müssen (Das ist übrigens genau das, was man tut, um einen dynamischen Betreff für die e-Mail-Aktion erstellen, aber das ist ein Thema für einen anderen Blogeintrag, Har har).

<Ende />