One of the nice things about the WF activity model is that you can pretty rapidly take existing code and expose that functionality out as a WF activity. I was reading on Doug's blog, and noticed that he's got a series going where he will create an Open XML document (the XML based representation of the next version of Office documents). He's got two parts so far, a Word document and an Excel spreadsheet creator. I've taken those and wrapped those into WF activities that are available on the community site (Word document activity, Excel spreadsheet activity). Make sure to check out the implementation notes on Doug's site, if you want to do some large scale number crunching in Excel, this would be a good start, but you would want to change so that it doesn't write out a single cell at a time. Formatting and formulas are also not included in this sample, but you could easily extend to support these by diving through some other Open XML posts.
The Excel activity takes in a dictionary with cell references and then its values (see code below).
Dictionary<string,object> cellContents = new Dictionary<string, object>();
cellContents.Add("A1", "hello World");
There is one trick to remember and that's to add the reference to WindowsBase (on my machine, located at: C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\WindowsBase.dll) if you're looking around for System.IO.Packaging.
When he gets a Powerpoint post up there, I will wrap that up in an activity as well. If anyone extends these to support some more advanced scenario, or have a really nice design experience (think grid control), please let me know, and we'll get your version hosted on http://wf.netfx3.com!
Let me know what you think!
The great thing about this position is that I get to pay attention to all of the conversations folks are having about WF.
The bad thing about this position is that I get to pay attention to all of the conversations folks are having about WF. I'm still learning how to listen to everything and anything that's going on in the world of WF, so forgive me for being a little slow to respond.
Brian Noyes started off with this post last Wednesday about the complexities inherent in WF, which was followed by Scott listing some of the common gotcha's in WF development. Tomas also has two posts (part 1 and part 2) on the subject. Jon weighed in somewhere in the middle there discussing some of the points raised. Some interesting comments are being posted to Jon's and Brian's posts.
For me, this is really rewarding to see the community having these conversations about the technology. Please keep having them, and if you have feedback, post it into our connect site. These things get routed directly to the team. Things are pretty much ready to go on v1, but that means we're working on planning what vNext and beyond are looking like, and we need to hear these things!
That being said, there is complexity in our model, and a lot of that comes from being extensible enough to manage the logic of your Windows Forms app using the same engine that runs the document life cycle workflows in MOSS. I think this is the benefit of providing this "foundational" api to enable workflow in any application, but it does come at the cost of a learning curve and complexity, and there are valid arguments whether certain pieces of complexity are neccessary. So, what do we do about it? Let's have a real informal $100 exercise. Basics of the exercise here:
You have $100 engineering dollars to spend. No matter how many millions we'd actually wind up spending, we use $100 as an easy number for people to keep in their heads. There are well over $100 dollars worth of features you want. The challenge is in determining how to spread the $100 in a way that produces with the most aggregate value.
You have $100 engineering dollars to spend. No matter how many millions we'd actually wind up spending, we use $100 as an easy number for people to keep in their heads.
There are well over $100 dollars worth of features you want.
The challenge is in determining how to spread the $100 in a way that produces with the most aggregate value.
What would you like to see added, improved, "fixed" in WF? Some thoughts, but don't feel limited to these: [Standard disclaimer: These are just my ideas, and nothing here means it will become part of the product.]
The other day, someone directed me to Mike Taulty's blog (http://mtaulty.com/blog/ ) where he has some fantastic posts about using Windows Workflow Foundation (check out his post on long running activities). Mike also has put together a ton (24 as of today) screencasts on using WF.
These have been added to a new screencasts directory in the file area. Dive in and check them out. If you've got screencasts that you're doing, feel free to upload those as well. Once they get approved, they will be added into this directory.
So, we've got some examples of using the WF Rules Engine outside the confines of a workflow (see here, and here). One feature you get inside of a workflow is that the rules engine will utilize the tracking service, if one has been provided, to log out information regarding rule execution. Moustafa shows how you can use System.Diagnostics tracing in order to have the same effect when using the rules outside a workflow.
Take a look at this sample, especially if you are interested in incorporating the WF Rules Engine in a non-workflow application. This would be something nice to attach a config flag or other setting to in order to enable rule tracing, which may be helpful if you are trying to debug a complex rules scenario.
I'm working on putting some other rules samples together, if there are specific scenarios you are interested in, drop me a line and I'll see what we can do!
I would be remiss if I did not point out this, a sample showing a nice WPF interface, WCF peer-to-peer communication, and WF to handle the logic of game generation.
I'm going to take a look at it and see if we could use rules as the validation mechanism, that way there is a "server" and a "client" workflow component to the application.
From Brian R's blog:"Workflow is both cute and pretty"
A little more background on the quote will be coming in my next post!