Morning (at least where I am)
I had a bit of a brainwave on the way home... The problem is a bug in
cfa_workflowReset.
In the tag, it has (from ~line 50):
--- start code snippet ---
<!--- reset workflow object values --->
<cfset stTasksFinished = structNew()>
<cfset stTasksHaveNotified = structNew()>
<cfloop list="#lTaskIDs#" index="currentTaskID">
<cfset null =
StructInsert(stTasksHaveNotified,currentTaskID,0)>
</cfloop>
<cfa_contentObjectData dataSource="#attributes.dataSource#" objectID
= "#attributes.workflowID#">
<cfa_contentobjectProperty name="isActive" value="1">
<cfa_contentobjectProperty name="lActiveTasks" value="">
<cfa_contentobjectProperty name="stTasksHaveNotified"
value="#stTasksHaveNotified#">
<cfa_contentobjectProperty name="stTasksFinished"
value="#stTasksHaveNotified#">
</cfa_contentObjectData>
--- end code snippet ---
In the loop, the stTasksHaveNotified struct is updated, which is fine.
In the cfa_contentObjectData, the stTasksHaveNotified AND stTasksFinished
properties are updated
with the stTasksHaveNotified struct created previously.
cfa_contentObjectData caches the object
to request scope whenever it saves to the codb so that when a user gets the
latest version
later in the request it can grab it straight from memory.
Because the object is cached in request scope, the two object properties
actually reference the
same memory space as they have been updated using the same structure in the
cfa_contentObjectData.
This means that when cfa_workflowExecute is run, whenever it updates the
stTasksHaveNotified property
of the workflow stTasksFinished gets updated too.
The solution for this is shown in the updated code snippet below, I have
inserted comments where
appropriate.
--- start snippet ---
<!--- reset workflow object values --->
<cfset stTasksFinished = structNew()>
<cfset stTasksHaveNotified = structNew()>
<cfloop list="#lTaskIDs#" index="currentTaskID">
<cfset null =
StructInsert(stTasksFinished,currentTaskID,0)><!--- Insert this here to
create separate struct --->
<cfset null =
StructInsert(stTasksHaveNotified,currentTaskID,0)>
</cfloop>
<cfa_contentObjectData dataSource="#attributes.dataSource#" objectID
= "#attributes.workflowID#">
<cfa_contentobjectProperty name="isActive" value="1">
<cfa_contentobjectProperty name="lActiveTasks" value="">
<cfa_contentobjectProperty name="stTasksHaveNotified"
value="#stTasksHaveNotified#">
<!--- <cfa_contentobjectProperty name="stTasksFinished"
value="#stTasksHaveNotified#"> Old property update --->
<cfa_contentobjectProperty name="stTasksFinished"
value="#stTasksFinished#"><!--- Set stTasksFinished to struct in separate
memory space --->
</cfa_contentObjectData>
--- end code snippet ---
I've run two test scenarios to confirm this and all seems well. Hope that
helps someone...
Ray, please update next Spectra release.
Cheers
Gareth
-----Original Message-----
From: Gareth Hunt
Sent: 10 July 2001 19:50
To: Spectra-Talk
Subject: Bug in cfa_workflowExecute ?
Evening all
I apologise for the long mail, but I have hit what seems a rather complex
problem which needs some background explanation.
Am using Spectra v1.5 on Solaris. We are in the process of porting a
workflow
system from a Spectra v1.01 system that was developed on NT.
One of the features is enabling the administrator to re-assign tasks to
other
users and then reset the workflow. This feature worked in the Spectra v1.01
version, but is barfing in v1.5
The code looks something like this:
--- start snippet ---
<cfif bResetWorkflow>
<!--- Reset the workflow --->
<cfa_workflowReset
datasource="#myDS#"
workflowid="#workflowID#"
>
<!--- Restart the workflow --->
<cfa_workflowExecute
datasource="#myDS#"
workflowid="#workflowID#"
>
</cfif>
--- end snippet ---
I have hacked around in cfa_workflowExecute and tracked the error to the
'workflowInstRefresh'
method for the 'workflowinstance' type.
Within this method there are the following declarations (~ line 40):
<cfscript>
stTasksFinished = stObjectData.stTasksFinished;
stTasksHaveNotified = stObjectData.stTasksHaveNotified;
</cfscript>
These two structs contain the same keys (taskIDs) and values (boolean), but
are used
for different purposes. However, it seems that when stTasksHaveNotified is
updated,
stTasksFinished is updated as well. As both of these variables are structs,
this implies
that they are sharing the same memory space.
I have even tried updating stObjectData.stTasksFinished and
stObjectData.stTasksHaveNotified
directly, but the same problem occurs.
Having trawled through the code for the best part of a day, I cannot find
the reason
for them sharing the same memory space and so am pleading for help.
1. Can anyone replicate this?
2. If so, any ideas?
Note: there is no problem with the tag when it is run on a newly created
workflow. It is only
when it is run on an existing workflow.
That is the brain-teaser for tonight, answers on a postcard please.
Cheers
Gareth
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
