Going dynamic is so hot these days. And, arguably, for a reason.

Restarting the entire solution just to change a tiny bit sucks. This used to be one of the main advantages of pumping up xslts with all the presentation and logic details you possibly could. Isn't it nice, changing it with a notepad and see the site being updated in less than a second? It is, but only if it's humanly possible to understand what's going on in that huge xslt in the first place.

What changes here?

First, asp.net 2.0 sets the trend in .net world. Dynamic code behinds, /App_Code folder - all are clearly designed to bring more dynamism and web like experience in asp.net web development. Too bad that the first attempt doesn't work well in some situations - hence the highly demanded web application model, which is basically "leave everything as it was". But check the VS2005 and Sitecore 5.3 setup without Web Application Project scrapbook post for an alternative.

Then check out this post by Alex Shyba, showing how to use /App_Code to define workflow actions in Sitecore:

Thanks to Ole, starting with 5.3 BETA 060825 we have made reflection work with App_Code. Therefore, custom processors in App_Code simply work out of the box. In the processor definition, simply leave out the assembly part of the type string.

What this means is that ReflectionUtil.CreateObject can find a class loaded through the asp.net app_code, if you omit the assembly name. CreateObject is in the center of Sitecore extensibility - whenever you input a class name somewhere in configuration, it's used to create an actual object. Workflow actions? Yes, but also event handlers, pipeline processors, scheduled tasks, you name it. However /App_Code is not exactly dynamic - it just does the compilation for you, but whenever it happens the application still gets restarted.

Next in line is dynamic xsl extension compilation. Move some of your logic to xsl extension, change the .cs file later and have it recompiled without any restarts, just like xslt itself. I think it's a nice thing to have, but what's interesting is that it's built on dynamic compilation magic used in Sitecore 5 for years to make X(A)ML controls happen; much earlier than asp.net 2.0 was released. Reusing that was a snap, and only took one evening.

I'd finish with a Iron Python ASP.NET CTP. Coding your views in python is one of the most cutting edge developments in asp.net world. I've blogged about it before, but check the recent hanselminutes show on iron python and language extensibility - Scott Hanselman is quite a bit better at explaining things. Monorail is an interesting alternative version of this: ASP.NET with Model View Controller and without page lifecycle and viewstate is a really delicious thought.

I'm not saying that dynamism in it's current form is the "right" thing to have for everyone - but being able to choose is certainly welcome. I have little doubt that it's role will only increase in future

So how to use the Sitecore workflow engine to approve item deletion? Here's what happens inside and it's a bit more complicated that I'd like it to be:

1. A new field in workflow template is used to setup a deletion workflow for items in this workflow (there are many alternative options for this):
   
2.  A custom processor in uiDeleteItem pipeline is invoked every time a user deletes an item. If the item has deletion workflow set up (pt. 1), the actual deletion is cancelled and instead:
   1. Current workflow gets suspended for all versions of the item being deleted (in all languages) that are currently not in the final workflow state. This hides them from the workbox. To be able to remember the workflow/state, a new field is added to standard template.
   2. Latest version in default language gets switched to deletion workflow. This ensures that only one entry for the item will show up in the workbox.
   3. Item is protected (item.Appearance.ReadOnly = true) and custom ribbon panel displays warning (the item is marked for deletion) in Content Editor.
3. If the item deletion is approved, item gets deleted / recycled.
4. If the deletion is denied, all changes in pt.2 are reverted:
   1. Workflow is resumed for all existing versions in all languages.
   2. Item is made writeable.

(Am I missing anything?)

I belive the main reason for the whole process being not entirely straighforward is that Sitecore workflows are targeted at versions, making item level operations such as delete are a bit harder to fit. Apart from uiDeleteItems processor, the rest of the logic is wired up using workflow events:

I wonder if custom workflow engine (and provider) could've been a better choice.

Download sources and package (5.3). This is still more of demonstration and haven't been used in a production site yet, and you might want to adapt it to your specific requirements. Comment, use sdn5 forum or mail me at 'ar at sitecore net' if you have questions or help getting it working.

Brent Turner asked on the forum for a way to use workflow to approve the item deletion. The idea is that when an editor deletes an "important" item, the item doesn't go right into the recycle bin. Instead the decision must be approved using Sitecore workflow.

The idea got Alex, Kim and me interested, we exchanged a number of emails and Alex had a nice entry on the topic.

Actually approved decision is the easiest part: place item in workflow when the user clicks delete button and delete the item once it gets to the right state.

If the deletion is denied, however, it'd getter be back in it's original state, whatever that was before someone decided to delete the item. And while the item is pending for a deletion, editors should see a warning - no sense in modifying the item that might be deleted tomorrow. And then if you consider multiple languages.. There's all sorts of interesting details and somehow I'm sure I didn't get everything right.

As an experiment, I did a screen cast to show how it works. Take a look (SDN5 access required):

Extended mail action adds a little extra to the standard Sitecore workflow mail notification by using the NVelocity template engine. In case you didn't know, standard Sitecore email action supports three hard-coded macro expansions: $itemPath$, $itemLanguage$ and $itemVersion$. So instead of sending a completely static mail notification saying that something had been changed somewhere you can add something like "Hello. Item $itemPath$ had been changed".

Well, thanks to the NVelocity template engine, extended mail action takes it to the next level! Here's the example message template:

Time: $time

State of the $item.Name item (located at $item.Paths.Path) had been changed from '$state.DisplayName' to '$nextState' by $user.Name ($user.Email).

Item workflow history:
#foreach ($historyItem in $history)
Date: $historyItem.Date | User: $historyItem.User | Action: $historyItem.Text
#end

The item was last updated on $item.Statistics.Updated.

and here's the the result:

Time: 26.09.2005 1:03:25

State of the Extended Mail Item item (located at /sitecore/content/Home/Extended Mail Item) had been changed from 'Editing' to 'Done' by Admin (jc-[at]-sitecore.net).

Item workflow history:
Date: 26.09.2005 1:02:45 | User: sitecore\Admin | Action: Item created

The item was last updated on 26.09.2005 1:03:22.

Even though it mostly looks like an additional number of hardcoded macros, its much more powerful: using the NVelocity templates you can code against the Sitecore API using the Sitecore client as long as the method/property evaluates to string. So now you don't have to start Visual Studio every time you need to change your custom template, and the educated users can do it themselves.

How to use it:

1. First of all, if you're not familiar with the Sitecore V5 workflows and workflow actions, I suggest that you read about them first.
2. Download and install the package.
3. Extended email action template is installed to the /templates/workflow folder.
4. There's also an example 1-step workflow installed with the package - Extended Mail Demo Workflow.

Here's how the shortcuts are defined:

/// <summary>
/// Populates the velocity template context. Only the objects that were
/// added in this method will be accessible in the mail template.
/// </summary>
/// <remarks>Override this to add your own data to the context</remarks>
protected virtual void PopulateContext(WorkflowPipelineArgs args)
{
   velocityContext.Put("args", args);
   velocityContext.Put("item", args.DataItem);
   velocityContext.Put("processor", args.ProcessorItem);
   velocityContext.Put("user", Sitecore.Context.User);
   velocityContext.Put("history", args.DataItem.State.GetWorkflow().GetHistory(args.DataItem));
   velocityContext.Put("state", args.DataItem.State.GetWorkflowState());
   velocityContext.Put("nextState", GetNextState(args));
   velocityContext.Put("site", Sitecore.Context.Site);
   velocityContext.Put("time", DateTime.Now);
}

As it says, if you need your own shortcuts/helpers than override the method, place your assembly into the /bin folder and change the 'type' field in the action item in Sitecore.

The Velocity itself is a powerful tool: you can define your own macros and variables, use basic conditions (#if) and loops (#foreach) and parse external templates. Google it if you need more information - most of the hits will come from the java version of Velocity, but it's almost the same.

We've put on hold the two big articles I've told about in the last post. Reason? We expect similar articles right from the heart of the Sitecore development, and we expect them soon!

So, we've decided to keep converting our support knowledge base into the smaller articles. Here are the new ones:

Item-Specific Context Menu. How to dynamically create the context menu depending on the list item that was clicked.
Toggling Control Visibility. Shows how to show or hide any control in the application based on user preference (using the Registry).
Customizing Upload Process. How to tweak the media upload process (customizing the uiUpload pipeline)

All articles I've put here previously as the word documents are now available at the SDN5:

Understanding Workflows. Basic information on the Sitecore V5 workflows.
My First XAML Application. XAML application basics.
Publish Queue Viewer. Creating the real-world application and using the advanced controls.

Next week I'll go through the last ones and update them basing on the feedback I've received.

'Understanding Workflows' is the basic article on one of the new cornerstone concepts in the Sitecore V5. I apologize for posting the articles in MS Word format, but this is the how they were edited and I really don't want to waste any time cleaning word's html. And if you have a lot of comments, you can use reviewing tools in Word and send the entire document back to me.

Since the articles themselves are more or less in the draft stages, I appreciate any comments or suggestions you might have, so we can fix the things up before going live with the new SDN and also better understand what topics should be addressed next.

Understanding workflows.doc (359 KB)