本站首页    管理页面    写新日志    退出


«November 2025»
1
2345678
9101112131415
16171819202122
23242526272829
30


公告
本博客在此声明所有文章均为转摘,只做资料收集使用。并无其他商业用途。

我的分类(专题)

日志更新

最新评论

留言板

链接

Blog信息
blog名称:
日志总数:210
评论数量:205
留言数量:-19
访问次数:927180
建立时间:2007年5月10日




[openCMS]管理和定制OpenCms 6 - 第5章 工作流(1)
文章收藏,  网上资源,  软件技术,  电脑与网络

李小白 发表于 2007/11/30 9:21:38

原创:路由器技术资料网(www.52router.com) 翻译:性感小肥猪(hahahaha78_fbs at yahoo.com.cn) 本书为英文版的中译本,本人翻译该书是出于个人爱好!请不要询问任何与OpenCms有关的技术问题!如需购买本书请进入本站的商城页面并联系译者!转载请注明出处! 第5章 工作流 我们在上一章中学习了OpenCms工作区的资源管理视图和管理系统视图。本章中我们将讨论工作流视图。  工作流视图提供了OpenCms的项目管理能力和任务追踪能力。本章将讨论以下内容:   • 理解工作流的概念   • OpenCms工作区中的工作流视图   • 创建、分配和跟踪任务   • 管理编辑人员用户组   • 设置并使用权限   什么是工作流? 一般的说法是,工作流是在创建一个或多个内容时从开始到结束的一个过程。通常,工作流处理是从一个想法、要求或一段新的内容开始的,并最终以发布新的内容结束。一个好的企业级的内容管理系统的基本方面是拥有处理工作流的功能,就象以其它方法来处理一样。 不同的内容管理系统以不同的方法来处理工作流。在最极端的情况下,工作流被紧密结合到CMS中,以至于对任何内容的处理都要使用到工作流。另一种情况是工作流并不占有如此重要的地垃。 在 OpenCms中,工作流与内容的联系是不明显的,也就是说工作流与内容之间并没有必要的联系。   这种工作流项目与CMS相分离具有一些比较明显的优势:   • 实现工作流是可选的—如果您不想使用它,您就不必使用它。   • 因为工作流与库结构并不是紧密结合的,您在实现工作流过程中具有一些灵活性。   • 如果您不喜欢OpenCms的默认的工作流,您可安装第三方的工作流模块甚至是自己定制一个工作流模块。   本章的大部分内容讨论了工作流的技术现状—在OpenCms中如何创建和管理任务,如何使用项目与工作流协同工作,以及如何使用工作流视图的不同特性。不过,我仍然尝试提供一个更高水平的应用,即如何能简单地处理创建内容的过程。 在研究技术细节之前,我想大概说一下工作流是如何工作的。在本章结尾部分将回顾一下这里所述的概念和讨论工作流策略。 工作流是怎样工作的 工 作流的基本假定是组织内不同的个人和用户组能执行不同的任务。如果只有一个人创建并发布内容,那么就没有必要使用工作流。即使是在同一个系统中有两三个编 辑人员并且每个人负责一个方面,使用工作流的价值也不大。相反地,工作流适用于有大量的用户或用户组对不同的方面负责的情形。 作一个简单的假设,一个小组织中有一个小团队管理其OpenCms驱动的网站,团队经理负责监管处理过程并分配新文章,有几个作者负责创建新内容,他们中的每一个通常都是单独工作的。当某篇文件写好后,编辑人员校对文本,确保与组织的指导方针一致,在经理的批准之后负责将文章发布到网站上。 在这个简单的例子中,有三个明显的角色—经理,作者,编辑人员—并且每个角色都有一套任务并且负责各自的任务, 项目经理分配并跟踪任务,作者创建内容,编辑人员检查并发布内容。 但是即使是这样一个简单的环境中,其处理过程也变得复杂困难。  经理如何跟踪每一个作者的工作? 编辑人员如何跟踪哪些内容已准备好发布,哪些内容需要进一步修改?如果某个作者做了大量的工作而另一个作者却什么也没做,如何有效地平衡这两个之间的工作量? 这里需要一套工具来进行流程化处理,能够轻松地跟踪各自的任务并与其它人相合作。 第一步是在OpenCms中创建一个反映出管理内容的过程的组织结构的结构,按照上面的例子,我们需要创建经理,作者,编辑人员角色 OpenCms 的工作流工具使用团队角色代替群组,事实上,工作流角色与组是相同的。 (第4章中讨论了创建和管理组)     第二步是设置操作程序。 OpenCms提供了用于实现这些程序的灵活的工具。  It is up to the organization to formalize procedures and then to use the tools in accordance with these procedures。 我们虚构的组织的程序已在前面粗略地说过—经 理创建任务并分配给作者,作者创建内容,当内容就绪之后通知编辑人员,编辑人员作修改(可能会把内容返回给作者以进一步修订),当编辑人员认为内容准备好 时,他或她通知经理(拥有决定发布内容权限的人),如果确定,编辑人员就发布内容。当然这之中可能会有许多辅助的程序。 第三步是权限设定,以允许适当的组或个人有权访问VFS中适当的区域。当然这是可选的,在上面的简单的例子中可能并不需要这样的措施,但在大型的有多个编辑团队的组织中  ,限制特定的组只能访问特定的区域可能更合适。 我大概介绍了工作流的过程,能够解决的问题以及如何实现工作流。现在,我们将讨论工作流的技术现状并了解OpenCms工作区中的工作流。 本章的最后一部分将提供一个对工作流的高水平的应用策略。 工作流视图 工作流视图提供了一个到工作流系统的基于任务的界面。 换句话说,工作流的整个过程被分解为任务,每个任务都可被分配给用户或用户组,并且可监控任务的执行。我们将详细地了解任务以及与任务有关的工具。 我们在第3章及第4章中讨论了创建和管理内容,并在第4章中了解了用于管理用户和用户组的工具。这些概念将被应用到这里。我们将能够在项目内分配编辑任务。 要进入工作流视图,从OpenCms Workplace区中顶部工具条上的View下拉框中选择Workflow 即可。 500)this.width=500'> 当载入工作流视图后,您将看到任务列表,上面截图中任务列表是空的。工作流界面 (颜色配置,图标,布局)与管理视图和资源管理器视图不同(虽然是继承了管理视图的界面)。如果您是opencms 5的用户,对该界面就非常熟悉了—工作流使用的仍然是旧版的布局。 在工作流工具条的左上解有一个向左的箭头。 这是后退按钮。 当该按钮是蓝色时,您可点击该按钮返回到之前的屏幕。下一个黑色的按钮是Filter(过滤器)下拉列表。过滤器决定了在任务列表中显示什么任务。默认情况下,使用 My new tasks filter(我的新任务过滤器)。 这将显示所有明确分配给当前用户ID(上面的屏幕截图中是Admin)的任务并象新的状态那样标记出来。 下拉列表中的过滤器被划分为四个类别。前三个类别按任务的三个状态 --- 新任务,活跃,已完成来划分。 状态用于表明某个任务所处的阶段。 当一个任务刚创建时,其状态为New(新任务)并被分配一个特定的角色和用户。 当用户接受任务后,任务就不再被标记为new(新任务)。一个任务从被创建到完成这一段时间里都是活跃的,在完成之后就被标记为完成(completed)。  (注意一个任务可同时拥有 new和active 两种状态—这些状态并不是互相排斥的) 。 Filter (过滤器)下拉列表拥有下面六个选项:My active Tasks(我的活跃任务), Active Tasks for My Roles为我的角色激活任务), All active Tasks(所有活跃的任务), New Tasks created by me(我自己创建的新任务), Active Tasks created by me(我自己创建的活跃的任务), 以及 Completed Tasks created by me(我自己创建的已完成的任务)。 令人遗憾的是,没有能够显示系统中你的所有的任务的过滤器。 Filter下拉列表旁边是一个叫作For all projects(针对所有项目)的选择项。我在之前提及任务是对项目敏感的。默认情况下,仅显示当前选择的项目下的任务(此例子中是Playground project)。 如果选择此项,那么也将显示来自于其它项目的任务。 创建新任务 工作流工具条上最后一个按钮为一张纸上有一个黄色的勾号以及一个红色的十字架。  这是Create New Task(创建新任务)按钮。点击该按钮将打开一个用于创建新任务的屏幕。 500)this.width=500'> 表单看起来很简单。 第一个要做的事情是设置角色和组信息。 我们在第4章中讨论了创建新组的过程。    当创建新组时您可回想一下,有一个Group As Role选择项。如果某个组被设置为扮演为角色,那么在工作流视图中的此位置就可用。   表单中第一个区域为Task for, 其后有两个下拉列表 。它的选项是 Users role(用户角色)以及所有以Users role为父类别的角色。  实际上,这表示在系统中是不显示Admin 组的, 并且这些组的用户也不能登录进工作区中。 第二个下拉列表是由在第一个被选择的角色中的许多直接的成员所组成的列表。  (Editor 用户只是我的OpenCms安装中的Users 角色中的一员) ,如果未在第一个列表中选择角色,那么此列表中是空的。 我们在第4章中了解了用户是如何间接地属于角色(组)的。那些间接地属于角色的用户将不会在第二个下拉列表中显示出来。 当您必须选择一个角色时,您可以选择不为某个用户分配任务。 Task文本区是用于输入任务的标题的。 此标题将显示在上面提及的任务列表中。 Task 区下面的文本区是用于描述任务的。 这是用于解释任务的目的的主要区域。  令人遗憾的是,该区域比较小,并且不够输入足够多的信息。如果您的描述比较长,您可能希望使用此区域输入基本的信息并使用注释(在下面解释)来提供详细的描述。 Due date(完成日期)区域被用来指定任务应该在什么时候完成。  点击右边的日历图标将打开一个非常友好的可用鼠标点击的日期选择面板。 Due date 区域是必须要填的。 Priority (优先权)下拉列表提供了一个用于指明此特定的任务的重要性(或非重要性)的方法。这里有三个级别的优先权—high(高), medium(中), 和 low(低)。 在Due date区域之下有四个选择项。前三个选择项与在某种情况下发送信息有关,最好一个则是用于向多个用户分配任务。如果选中 Message when accepted 选择框的话,当另一个用户标记接受任务时您(任务创建者)将收到一条消息。 如果第二个选项项, Message when forwarded被选中的话,将通知任务创建者任务被转给另一个用户了。  如果任务是编写一篇文章(与本章开头部分的例子一样),那么当作者编写结束时,他或她将把文章转给编辑人员,并且如果选中此选择框的话,将通知管理者(任务创建者)任务已被转给另一个用户。 如果选中 Message when completed 选择框,那么当任务被标记为已完成时,将通知任务创建者。 最后,如果Inform all role members of the task选择框被选中的话,那么此任务将显示在每一个在第一个任务下拉列表中选择的角色的任务列表中。 一旦选择了这些区域之后,点击OK按钮将创建一个新任务。您将返回到任务列表(其中仍然是空的,除非您为自己分配了一个任务)。 Notification(通知) 一旦创建了一个任务,将向受理人发送一封描述任务信息的邮件。下面是一封在我给Bob用户分配任务后发送给他的示例信息: From: opencms@example.com To: bob@example.com Subject: OpenCms task management: new task for Bob Editor (Bob) / Editors Automatic message from OpenCms task management: A new task was created for you or your role. Project: Playground Project Task: Write an article Task Initiator: (Admin) example.com/opencms/opencms/system/login/index.html? startTaskId=34&startProjectId=13 信息低部的链接可直接访问新任务(如果用户未在系统中,该用户必须先登录.) 同样地,Bob 在下一次登录并查看他的任务列表时,新的任务将显示在其中。 Viewing the Task (查看任务) 现在您应该位于任务列表视图,该列表中可能仍然是空的。 要查看您刚才创建的任务,从第一个过滤器下拉列表中选择 New Tasks created by me(我创建的新任务) 项。 500)this.width=500'> 最左边栏中的图标(此例中是一个白色的长方形中一个蓝色的勾)用于指示任务的状态。淡蓝色的勾号用于表示任务是新任务,深蓝色勾号表示任务已激活并被接受,红色的勾号表示该任务已超过规定的日期,黑色的X表示任务已完成。除了这些图标之外,被标记为高优先级的任务还有一个惊叹号!图标。 标记为低优先级的任务有一个蓝色的向下箭头图标。  任务列表中下面的七栏显示了任务的基本信息。 要查看任务的详细信息,点击任务栏中的任务名称。 在任务详细情况页面的顶部是一个与任务信息有关的表格以及许多用于操作或修改任务的按钮。在此表格之下,有一个被附加到任务的文件的列表。此列表将包含对此任务所做的所有修正和注释。 首先,让我们看一看屏幕顶部的表格: 500)this.width=500'> 此屏幕上的按钮的变化取决于查看任务的人。 例如,任务创建者(发起人)有一个叫作Message的按钮。  但是屏幕上被分配任务的人的按钮叫作Query。  在这两个例子中,此按钮被用来在任务的不同阶段之间进行沟通。 点击Message (或 Query) 按钮将打开一个文本编辑器屏幕,您可使用该屏幕来创建消息。 500)this.width=500'> 点击Send 将发送消息。如果您是创始人,消息将发送给受理人。 如果您是受理人,消息则将发送给创始人。 当通过邮件来通知消息接受者有新消息时 ,他们必须登录进系统才能阅读该消息。  消息将显示在文档区并且看起来如下所示: 500)this.width=500'> 当被分配了一个新任务时,受理人必须在工作之前先接受它。 在受理人的屏幕上将显示一个标签为Accept的按钮。 例如,下面是Editor用户的任务的细节屏幕: 500)this.width=500'> 点击Accept 将提示用户确认接受。如果用户(此例子中的用户叫作 Editor)确认了,那么将返回到任务细节屏幕。顶部表格的背景颜色将不同,指示出任务现在已被接受,并且以Forward按钮代替Accept按钮。  点击此按钮将打开一个允许您将此任务分配给另一个角色或用户的屏幕。 让我们返回到开始部分的假定中,当作者结束编写一篇文章的草稿之后,他或她将通知编辑人员。在OpenCms中的一个方法是将任务转给编辑人员。 以此方法,任务就添加到编辑人员的任务队列并且对于编辑人员来说很容易跟踪任务情况。如果编辑人员发现文章中的问题,他或她可能会将文章重新发送给作者。 否则的话,编辑人员可能会执行所需要的操作(如发布文章)并将任务标记为已完成。 即不是受理人也不是发起人的其它用户将看到Take 按钮而不是Accept 或 Forward 按钮。  通过点击该按钮,用户可成为该任务的受理人—换句话说,他们可从之前的受理人处取走任务。 任务发起人也可改变任务的到期日期以及任务的优先权。当用于改变的按钮在受理人和发起人的屏幕上显示时,这些按钮将使受理人的屏幕不再激活。发起人可使用这些按钮来分别修改任务的完成日期或优先级。 转寄或取得一篇文档,以及改变完成日期和优先权,都是被记录进任务视图中的Documentation 区的事件。这就是用于追踪任务历史的一个虚拟的"paper trail(纸质的跟踪资料)"。 点击New Comment按钮将打开一个类似于 query/message 屏幕的窗口。 500)this.width=500'> 编辑人员可使用注释区来记录某个任务的处理过程。  这些注释都被记录在任务视图的Documentation 区。 任务被接受之后, Complete 按钮就不可用了。 当任务被标记为被接受时,OpenCms假定用户已在执行任务了,并且不再检查用户是否已真正完成了任务。 当任务完成之后,点击Complete 按钮将打开一个确认会话。 如果您点击OK来真正标记任务已完成,任务将被标记为已完成并被从激活的任务列表中移除。 当任务完成之后,除了任务的发起人,对于其它用户来说,所有的按钮都不再激活。任务发起人将有一个激活按钮,该按钮将在Complete按钮所处的位置显示出来。 此新按钮叫作 Recycle。 再循环一个任务将重新开始该任务,这是很有用的,例如,有一个需要每周或每月来完成的任务时,此按钮就很有用了。您可以仅仅再循环旧任务而不需要每次都重新创建新任务。 Recycling (循环) 当您点击 Recycle时,将显示Recycle Task 屏幕。 500)this.width=500'> 此屏幕上所有的区域与Create New Task 屏幕上的区域是相同的—除了此屏幕上所有区域都具有在之前所设置的值之外。 点击OK将把此任务标记为新任务并放置到被选择的用户和角色的任务队列中去。  这并不是一个真正的新任务,而是与之前相同的任务。 因此,所有旧的文档历史记录将被保护,并且新的条目将被添加到被循环的任务的文档备注中。 这就是OpenCms工作流视图的全部过程。通过这个简单的工具,您可创建一些相当灵活并且复杂的工作流。 再一次地,我要声明一下工作流工具并不直接与VFS中的内容相结合的事实。但是通过使用一些策略,您可使工作流适合您的需要。现在我们要了解一些在OpenCms中管理工作流的策略。 Workflow Management Strategies (工作流管理策略 ) 整个工作流系统可能会使某些对CMS概念不熟悉的人感到畏惧。 不过,工作流系统是管理您的内容的一个强有用的工具。下面是一些使用项目和工作流追踪来管理任务的策略。 Use Projects to Manage Content Areas (使用项目来管理内容区) 项目提供了一个用于清楚地将内容划分到逻辑的组中的方法。 它通过将编辑人员的权限限制到其所在的项目中的资源的方式来对访问控制提供帮助。它帮助对项目进行管理,就如同项目管理人员有一个其所负责的被定义好的域名一样。总之,工作流是管理内容的一个有效的方式。 对于定义项目有两个策略。  第一个是为网站内的每一个主要的内容区创建一个项目。  此设置按不同的内容采取功能路线(原文This setup takes the functional route in the division of content)。一个项目管理人员可能会被分配多个项目。此系统的优势是编辑人员可能会被限制到网站的一个小的子集中。  同样地,可通过最少量的工作将任务从一个项目管理人员处移到另一个项目管理人员处。 第 二个方法是为每一个项目管理人员创建一个反映出组织结构的项目(与网站的结构相反)。此结构使得项目管理人员的工作变得轻松一些,因为他或她只需要跟踪一 套的内容和任务。对于负责在一个项目管理人员下的多个不同的区域的内容的编辑人员来说,此方法更容易一些。与项目管理人员一样,他们只需要跟踪一个项目。 不过此配置有两个缺点 。  如果一个内容区被从一个项目管理人员处移到另一个项目管理人员处的话,重新配置项目就显得有一点单调乏味。  同样地,将编辑人员限制为只能访问一个内容区域就显得比较困难。  这可通过小心地使用组和文件权限来解决,但是这需要更多的维护工作。 不管您选择哪种方式,当您的内容库不停地增加时,使用项目将能够帮助您管理内容。 Use Group Hierarchies for Inherited Permissions (针对被继承的权限使用分级组) OpenCms 的访问控制允许您为VFS中的任何资源指定精确的许可。如果不同的组中的多个编辑人员需要访问相同的资源,您需要做更多的努力以确保所有适当的人员能够访问共享的资源。 从技术上考虑,一个新闻网站有两个编辑组 – 一个组处理硬件新闻,另一个组处理软件新闻。许多时候,这些编辑人员都处理不同的内容,但是这两个组都需要更新headlines.html 文件。该文件只能有一个拥有者及一个用户组,但是硬件编辑组与软件编辑组是不同的用户组。因为系统中的其它用户不能编辑此文件,只是简单地为用户组中的每一个人赋予写入权限是不明智的。 有两个解决此问题的方法。 一个是为这两个组创建访问控制。 这可以通过explorer视图打开文件的上下文相关菜单(点击图标)并选择 Permissions来办到。您可以按用户或按组添加新的访问控制。 500)this.width=500'> 另一个方法是,您可以充分利用组继承并设置这两个组都继承某一个公共组的权限。这样,您就可为公共组提供所需要的权限。  让我来详细解释一下这之间的细微的区别。 如我们在第4章中所学,组可以按照层级来组织,这样的话,子组就能继承父组的权限。 如果两个组都有同一个父组的话,那么为父组提供对文件的访问权限将使得两个子组也拥有同样的权限。例如,考虑一下下面的组结构: 500)this.width=500'>  此配置中,父组是Tech_Editors,而 Hardware 和 Software 组为其子组。 因此,如果Tech_Editors 组拥有对某个文件的写入权限的话,那么Hardware 或 Software 组中的成员也将拥有写入该文件的权限。 为了严格的控制访问和工作流规则,您需要您的VFS中的目录的访问控制。默认的访问控制是允许所有的工作区用户编辑网站内的所有文件。 小心地对组进行规划能够在OpenCms中轻松地维护访问控制。 Tracking Workflow with Tasks (通过任务来跟踪工作流) 工作流工具被设计为提供一个接近于管理您的内容的功能。 工作流提供了一个清楚并直观的方法来跟踪被生成、编辑和维护的内容的状态。使用工作流视图将帮助您实现编辑过程的效率最大化。在许多复杂的工作流中,使用一个任务来跟踪从创建到完成的整个过程可能导致任务比较难以完成(原文:In more complex workflows, using one task to track the entire process from creation to completion may result in tasks that are bloated and difficult to work with)。 您会发现在这样的情况下为编辑和发布过程分配每一个步骤是很容易的。 例如,假设一个项目(假设为'Project X')只有一篇文章以及相应的JSP文件。 下面是项目管理人员可能创建的任务列表:   • 编辑 1: 在Project X中编写文章。   • 开发员 1: 为Project X创建JSP。               • 编辑 2: 校对并编辑文章。               • 编辑 2: 校对JSP中的内容。               • 项目经理: 批准文章。               • 项目经理: 批准JSP。               • 项目经理: 发布项目。 我们可减少任务的数量。 例如,我们可要求编辑1在完成之后将文章转给编辑2,而编辑2在完成之后将文章转给项目经理以等待批准。这样就减少了对项目的跟踪,但是对处理过程的控制就有一点困难了。对于要处理大量内容的组织来说,使用存在期更短的工作流或只需要一步的工作流可能更有用。 一个鼓励用户使用任务的方法是为他们设置默认的工作流而不是视图explorer视图。 Keeping a Trail (保持追踪) 对任务使用分配-接受-转寄-完成(assign-accept-forward-complete)这几个步骤可能就足够了。不过,当有大量的编辑人员时,或编辑人员与项目管理人员不处于相同的地理位置时,那么传送可能会出现错误并且信息的传达可能会失败。  Email可能未被注意到或偶然被删除。  不管是口头或书面的交谈也可能会被忘记。并且这些方法并不能在中央位置保存所有的信息。 要解决这些问题,您可能会发现使用工作流提供的Query(查询), Message(信息), 和 Comment(注释)工具来跟踪任务的状态更加可靠。 如果项目管理人员和编辑人员之间的通讯是通过信息来处理的,并且有关人员勤于记录处理过程的话,那么每项任务都会有一个完整的纸质追踪痕迹。这能有效地提升信息的传递并防止忽略重要的信息或要求。 我们已学习了这三个视图中的每一个,并且我们已完成了对工作区的探索。剩下来的事情是讨论安装和配置 OpenCms 的模块 摘要 我们在本章中对工作流作了个大概的了解。首先我们讨论了工作流的基础,然后又学习了OpenCms提供的工具。  最后,我们探讨了在组织内使用工作流的一些策略。 您应该对本章中的三个OpenCms视图是如何工作的有了很好的理解。下一章中我们将讨论如何定制OpenCms网站。


阅读全文(4138) | 回复(0) | 编辑 | 精华
 



发表评论:
昵称:
密码:
主页:
标题:
验证码:  (不区分大小写,请仔细填写,输错需重写评论内容!)



站点首页 | 联系我们 | 博客注册 | 博客登陆

Sponsored By W3CHINA
W3CHINA Blog 0.8 Processed in 0.703 second(s), page refreshed 144806944 times.
《全国人大常委会关于维护互联网安全的决定》  《计算机信息网络国际联网安全保护管理办法》
苏ICP备05006046号