Archive for December, 2007

Friday, December 14th, 2007

Workflow Insights: Introduction

This week I am starting a new series of articles to give you guys more insight in the Windows Workflow Foundation framework. The Windows Workflow Foundation (WF) is a framework which was released last year as part of the .NET Framework 3.0 alongside the Windows Presentation Foundation (WPF) and the Windows Communication Foundation (WCF). It allows you to model workflows: flows of logical (and easy-to-understand) work units. Here’s a basic example.

Workflow Insights: Workflow Example

The units are represented by blocks, so-called “activities”, you can use by dragging them on your workflow designer. And right there, you get the main advantage of workflows. This methodology of creating a process by assembling logic building blocks together is pretty powerful. Especially when you envision a developer sitting down next to a business guy and interactively building the workflow together with him in just a couple of hours. And this without loosing track of the objective as they are working with small logical blocks.
For example, you can use a Send Email activity without having to know how it is actually sent or which methods you have to use. You just fill in a couple of properties and off you go. The big hick-up, unfortunately, is that there aren’t many blocks to choose from. So, we have to create them ourselves. And this is where the frustration begins. Most of the time the business has these complex rules set up and wants them translated to workflow technology. Creating all of these abstractions of the inner workings to the actual logic they’re producing, can be quite hard and sometimes just plain impossible. Why? Well, we have this framework we have to work around, which has very specific rules and complex, new logic to get code to run. And I’m not yet talking about parallel execution of our blocks.

Another great advantage is its pluggable system of services. When we want to run a workflow, the Workflow Foundation can add services to extend its possibilities. One of the most interesting services already developed, is persistency. It gives us the possibility to have the workflow, its whole instance, being interrupted and saved on a data storage. This way, lengthy processes that are waiting on some user interaction can be cleared from main memory and brought back to execution only when needed!

All in all, Windows Workflow Foundation is quite a nice technology, which can be very powerful. Unfortunately, development is proofing to be quite challenging. This is why I decided to give this series a try to get things cleared up and help you guys with some hints and tips. Hope you’ll like the series. Stay tuned!

Monday, December 3rd, 2007

SharePoint Branding Issues: Calender View

Back again for a SharePoint branding issue, and this time we’ll tackle the calender. More specifically its calender views: the day and the week view. Let me first show you, how the week view should look like:

SharePoint Branding Issue: Calender view on default.master

As you can see, an appointment can cover multiple hours. This way you have a graphical overview of how much time appointments will take. This, however, is how it looks like on the other MOSS master pages:

SharePoint Branding Issue: Calender view on MOSS master pages

This is not what we expected. Appointments now only cover a small fragment of the time to take, while the rest stays blank. It is very confusing for the user. And some appointments seem to pointlessly be in different columns. The day view experiences the same kind of problem. What is this weird voodoo? We did not change anything to the calender, now did we?
Well, no, we didn’t. But we did change the looks of it by changing how the looks are parsed. As I already mentioned in another article a couple of weeks ago, the other MOSS master pages use a (correct) doctype declaration, while the default master page does not even contain one:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Make no mistake, this is a declaration HTML pages should contain. Otherwise, you have no clue how browsers will render the page. Internet Explorer falls back to its “quirk mode”, where everything is “kinda” allowed. Other browsers will just try to render the page. And this is what we experience in the calender views. The inner box of the appointment has a CSS property: height equals 100% to make the appointment cover the whole time slot space reserved in the table of the view. In the doctype declared version, this is only supported if all parent elements also have a CSS height equal to 100%. Of course, this is not the case for all its parents. That’s why the appointments get shortened.

Is there a solution? Well, no solutions, only workarounds, I’m afraid.

  • Remove the doctype declaration from the master page. I don’t really advice it, but it can do the trick. Make sure other browsers still display the master page correctly. Future browsers can break the layout however. (this is what SharePoint did for the default.master)
  • Rewrite the views. You could make the views compatible with current standards, but it’ll cost quite some time to develop.
  • Have SharePoint show the default.master for the calender views. It’s an ugly workaround, as you’ll have different layouts in your site, but it works.

Once more, a very unfortunate branding issue. Aspecially, because it could have been prevented by generating correct HTML. Hopefully this kind of bugs will be resolved in future SharePoint versions. Till next time.