Freigeben über

New List or Not in MOSS (workflow association)

  • Artikel

The other day developing a sample state machine workflow and related custom Association and Instantiation pages I found that the test mechanism for determining whether not a new List (tasks and history) in the Association page is, well, silly. One might think that there would be a context parameter, passed in via the hidden fields or otherwise, that could be checked against an enum or maybe a couple of boolean properties (e.g., NewListRequired == truefalse) that would allow easy determination of the user options selected in the Association of the workflow with whatever list item is the target. Sadly, it is not the case. Instead, one has to check the TaskList value passed in via the post to see if it is a guid or, alternatively, if it matches the pattern. Let me explain. Assign the value from the Request to a local variable:

string TaskListID = Request.Params["TaskList"];

With that done, later on in the code when it is desired to determine whether or not it is a new list you have the option of attempting to parse that string as a guid and catch the exception or check the pattern of the string. If an existing list is chosen the value will be a guid, but if it is not then the string value will contain some text in the format "z[workflow name] Tasks". So, alternatively the string could be checked to match the pattern or simply check the first character to see if it is a "z" - for example:

if (TaskListID[0] == 'z')
{
IsListNew = true;
NewTaskListName = TaskListID.Substring(1);
}
else
{
if (m_AssociationType == AssociationTypeEnum.ContentType)
{
m_TaskList = Web.Lists[TaskListID];
}
else
{
m_TaskList = Web.Lists[new Guid(TaskListID)];
}
}

Further down in the example, the determination is made whether or not the association is to a content type or not and if not it is fetched via the guid contained in the TaskListID string previously assigned the value from the Request object. Since I believe it t be more efficient to check the first character to see if it is a "z" I did that to determine whether or not a new list is needed. I suppose more ideally one would validate whether or not the value was a guid, but that seems inefficient. So, like a presidential campaign I have the choice between bad and bad; check the magic string literal and be efficient or parse it for a guid and catch the exception. This is true wrt the history list as well.

It is certainly possible that there is a property or value other than what I've discovered, but if there is that just speaks to the challenging developer story that exists wrt MOSS development.

Comments