我应该使用工作流程还是事件接收器?

发布于 2024-07-15 07:53:09 字数 461 浏览 11 评论 0原文

我想构建一个自定义内容类型,它将作为具有多个状态的列表项的基础。 不同的状态将决定哪个列表将实例化该项目。 它将根据用户操作在状态之间移动,从而在列表之间移动。

我有几个选择来实现这一点:

  1. 在每个列表上创建工作流来处理与该列表相关的特定功能。 必要时将项目移动到另一个列表(将项目复制到新列表,删除原始项目),然后开始该工作流程。
  2. 在我们将使用的自定义内容类型上创建一个工作流程,并让它在各个列表之间移动项目。 不确定内容类型的工作流程是否可以从一个列表移动到另一个列表,更不用说跨网站集了。
  3. 使用自定义内容类型上的事件接收器来管理状态。 用户对某个项目进行操作,更改其状态,因此事件接收器在另一个列表上创建其自身的副本,然后在当前列表中删除其自身。 我知道这适用于跨网站集。

哪种方式最好,为什么? 有什么绝对行不通的吗? 有什么方法是我忽略的吗?

I want to build a custom content type that will be the basis of a list item that will have multiple states. The various states will determine which list will instantiate this item. It will move between the states, and therefore the lists, based on user actions.

I have a few choices to implement this:

  1. Create workflows on each list that handle the specific functions related to that list. Move an item to another list when necessary (copy item to new list, delete orig item), and let that workflow kick off.
  2. Create a workflow on the custom content type we will be using, and let that move the item between the various lists. Not sure if a workflow on a content type can move from list to list, let alone across site collections.
  3. Use the event receivers on the custom content type to manage state. User acts on an item, changing its state, so the event receiver creates a copy of itself on the other list and then deletes itself on the current list. I know this works across site collections.

Which way is best, and why? Anything that absolutely will not work? Any method I've overlooked?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

无敌元气妹 2024-07-22 07:53:09

在我看来,使用事件接收器,因为它们遵循项目而不是列表。 您仍然需要为接收列表启用内容类型,但这种方法比根据某些内容类型的存在或不存在更新和删除列表中的工作流要容易得多。

但是,为什么不将这些方法结合起来呢? 让内容类型事件接收器处理内容类型特定的活动,并让列表处理任何列表特定的活动。 事件接收器便宜且灵活。

.b

In my opinion, use event receivers, as these follow the item rather than the list. You still need to enable the content type for the receiving list, but this approach is a lot easier than updating and deleting workflows in lists based on the presence or absences of certain content types.

However, why not combine the approaches? Have the content type event receiver deal with the content type specific activities and let the lists handle any list specific activities. Event receivers are cheap and flexible.

.b

書生途 2024-07-22 07:53:09

一般来说:
在 SharePoint 中,工作流和事件接收器是相关的(如果您查看带有附加工作流的列表上的事件,您会发现启动工作流的事件接收器。)

工作流的优点是用户可以检查日志(假定您使用 Log-Activity)

事件接收器的优点是事件数量较多; 它们比工作流程更灵活。

根据您的描述,我可能会选择工作流程,以便用户可以检查他们的项目是否已正确处理。

Generally speaking:
In SharePoint workflows and event-receivers are related (if you look at the events on a list with an attached workflow you will find a event-receiver starting the workflow..)

The advantage of workflows is the possibility for the user to check the log (given that you use the Log-Activity)

The advantage of event-receivers are the greater number of events; they are more flexible than workflows.

From what you describe i would probably choose workflows, so the users can check if their item was processed correct.

逆蝶 2024-07-22 07:53:09

我使用与每个列表方法关联的工作流程,因为我需要工作流程历史记录作为用户执行操作的审计跟踪。 我更喜欢内容类型工作流程的想法,但是回想起来,这对于我所做的事情来说是更干净的解决方案。

I use the workflow associated with each list approach because I need the workflow history as an audit trail for which user does what. I rather like the idea of a workflow on the content type however and in retrospect this would have been the cleaner solution to what I've done.

千里故人稀 2024-07-22 07:53:09

这是在工作流和事件接收器之间做出决定的完美流程图:

http://msdn.microsoft .com/en-us/library/ff648492.aspx

This is prefect flowchart to decide between workflows and event receivers :

http://msdn.microsoft.com/en-us/library/ff648492.aspx

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文