Chỉ là một sự quan sát nhanh chóng là có một sự khác biệt rất quan trọng giữa hai định nghĩa:

<FieldBind lĩnh vực = "InParam1" DesignerType = "StringBuilder" ID = "2" Văn bản = "Đầu vào tham số #1" />

so với:

<FieldBind lĩnh vực = "InParam1" ID = "2" Văn bản = "Đầu vào tham số #1" />

Đầu tiên cho thấy như thế này trong SPD:

trong khi các chương trình sau đó như thế này:

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 🙂

Các quan sát là điều này: StringBuilder cho phép bạn xây dựng một chuỗi (rõ ràng) bằng cách trộn với nhau chuỗi literals và dữ liệu quy trình làm việc (thông qua các "thêm tra cứu" nút ở góc dưới bên trái). Khi bạn sử dụng nút thêm tra cứu, Nó chèn một mã thông báo trong các hình thức"[%Token %]". Khi SharePoint invokes hành động tùy chỉnh của bạn, (Mã C# trong trường hợp của tôi), SharePoint đi kỷ niệm chính nó, không có giá trị kỷ niệm. Nếu bạn sử dụng loại thiết kế mặc định (loại thứ hai), SharePoint mở rộng kỷ niệm và đi các giá trị thực tế của kỷ niệm để hành động của bạn.

StringBuilder = xấu, mặc định thiết kế loại = tốt.

Tất nhiên, đó là những gì tôi thực sự có nghĩa là. Chỉ cần không thử và vượt qua một tham số để hành động tùy chỉnh của bạn khi các nhà thiết kế loại = StringBuilder. Sử dụng các loại thiết kế mặc định và chuỗi một StringBuilder để nó lên phía trước nếu bạn cần phải xây dựng chuỗi phức tạp trong công việc của bạn (mà bất ngờ là chính xác những gì một không để tạo ra một đối tượng năng động cho hành động email, nhưng đó là một chủ đề cho một blog entry, Har har).

<kết thúc />