Bara en snabb iakttagelse att det finns en mycket viktig skillnad mellan dessa två definitioner:

<FieldBind fältet = "InParam1" DesignerType = "StringBuilder" ID = "2" Text = "Input parametern # 1" />

kontra:

<FieldBind fältet = "InParam1" ID = "2" Text = "Input parametern # 1" />

Först visar såhär i SPD:

medan de sistnämnda visar såhär:

I’m not sure how helpful these screen shots are but I put in the effort to make them so you have to view them 🙂

Iakttagelsen är detta: StringBuilder kan du skapa en sträng (uppenbarligen) genom att blanda ihop teckensträngar och arbetsflödesdata (via den "Lägg till sökning" knappen i det nedre vänstra hörnet). När du använder knappen Lägg till uppslag, den infogar i stället ett token i form"[%variabeln %]". När SharePoint åberopar din anpassade åtgärden, (C#-kod i mitt fall), SharePoint passerar token som sig själv, inte värdet av token. Om du använder standardtypen för designer (den andra typen), SharePoint utökar token och skickar det verkliga värdet för token till åtgärden.

StringBuilder = BAD, standardtyp för designerns = bra.

Självklart, Det är inte vad jag egentligen menar. Bara inte prova och passera en parameter till din anpassade åtgärden när formgivaren skriver = StringBuilder. Använda designer av standardtyp och kedja en StringBuilder att det på framsidan om du behöver för att bygga komplexa strängar i arbetsflödet (vilket är för övrigt exakt vad gör för att skapa en dynamisk ämne för e-post, men det är ett ämne för en annan blogginlägg, har har).

<slutet />