-ACS Documentation : Workflow : Workflow Design Documentation +OpenACS Documentation : Workflow : Workflow Design Documentation
@@ -98,7 +98,7 @@ code
. Ticket-tracker is a prime example, but other examples include order fulfillment and customer service in the ecommerce module, the recruting pipeline in the intranet module, and user -approval in the ACS core. +approval in the OpenACS core.
@@ -217,7 +217,7 @@
tasks is to approve or reject something, we'll typically have an
approved_p attribute that takes a boolean value, and can
be branched on in an or-split. We considered (1) having a skinny table
-as part of the workflow package to hold the values, (2) using the ACS
+as part of the workflow package to hold the values, (2) using the OpenACS
kernel metadata/attribute system or (3) have a clob column in the case
table that holds an XML document with the values. We originally did
(1), then migrated to (2) when the kernel was somewhat ready for it,
@@ -364,17 +364,17 @@
-For workflow to be really functional, we rely on the ACS kernel at
+For workflow to be really functional, we rely on the OpenACS kernel at
some point implementing a system for automatically generating
forms based on metadata. This is used for setting workflow
attributes as part of performing a taks. Currently, we do it ourselves
in a very ad-hoc fashion. Speaking of attributes, we store a
wf_datatype about attributes, in addition to the
-information stored by the ACS kernel. This is historical. We needed
-it, because the ACS kernel currently doesn't let us say that the
+information stored by the OpenACS kernel. This is historical. We needed
+it, because the OpenACS kernel currently doesn't let us say that the
datatype of some attribute is the primary key of some object of a
specific type, e.g. that the value of an attribute should be a
-party. In this case, the ACS kernel datatype would be number, and the
+party. In this case, the OpenACS kernel datatype would be number, and the
wf_datatype would be party. We needed that for the manual
assignments, when we did those with attributes, but now that we don't
use attributes to store those anymore, because attributes can only
@@ -426,7 +426,7 @@
Management System. There's also a
wf_attribute_value_audit table, which all the historical
values of workflow attributes, a service that is conceptually better
-provided by the ACS kernel, but since the kernel currently doesn't do
+provided by the OpenACS kernel, but since the kernel currently doesn't do
that, we have it here.
@@ -435,7 +435,7 @@
whether something is defined at the workflow or context level, to
query the actual workflow state (used by
workflow_case.enable_transitions), and one to abstract
-away from traversing the ACS kernel party hierarchy.
+away from traversing the OpenACS kernel party hierarchy.
@@ -710,7 +710,7 @@ the workflow engine. It would fully expose implementation details, because these are necessary to understand how to build non-simple workflows. It would also allow the user to export the workflow in some -way that is importable into another ACS installation for distribution +way that is importable into another OpenACS installation for distribution either alone or with a package, either as a SQL file to load into the RDBMS, or as an XML in the WfMC standard format.