Doar o observaţie rapid că există o diferenţă foarte importantă între aceste două definiţii:
<FieldBind teren = "InParam1" DesignerType = "StringBuilder" ID = "2" Text = "Parametru de intrare #1" />
comparativ cu:
<FieldBind teren = "InParam1" ID = "2" Text = "Parametru de intrare #1" />
Primul show de acest fel în SPD:
în timp ce acesta din urmă Arată ca aceasta:
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 🙂
Observarea este aceasta: StringBuilder vă permite să construiască un şir (în mod evident) prin amestecarea împreună şir literali şi fluxul de date (prin "Add Lookup" butonul din colţul din stânga jos). Când utilizaţi butonul Adauga Lookup, se inserează un simbol în formă"[%Token-ul %]". Când SharePoint invocă dumneavoastră acțiune particularizată, (C# cod în cazul meu), SharePoint trece token-ul în sine, nu valoarea simbolului. Dacă utilizaţi tipul implicit de design (al doilea tip), SharePoint extinde token-ul şi trece de valoare reală de token-ul dumneavoastră de acţiune.
StringBuilder = proaste, implicit designer tip = bun.
desigur, Asta e ceea ce am cu adevărat înseamnă. Doar nu încercaţi şi trece un parametru dumneavoastră acțiune particularizată când proiectantul tip = StringBuilder. Utilizaţi tipul implicit de design şi lanţ StringBuilder o să-l în faţă, în cazul în care aveţi nevoie pentru a construi complexe siruri de caractere în fluxul de lucru (de altfel care este exact ceea ce o face pentru a crea un subiect dinamic pentru acţiunea de e-mail, dar asta e un subiect pentru un alt blog intrare, har har).
<final />
Dezvoltarea de acțiune de flux de lucru particularizat este foarte usor, încercaţi acest,
http://sarangasl.blogspot.com/2009/11/sharepoint-workflow-actions-for.html