Wanted: XAML for Spatially Enabled Workflows

After working with XAML for a couple of months now, I’m shifting gears to enhance a data exporter I wrote several years ago.

I sure wish there were examples of spatially enabled Windows Workflow Foundation (WF) applications for this sort of thing. The glamor of Silverlight/WPF is overshadowing a lot of useful things XAML offers for workflow. David Chappell has a good overview of WF here. Indeed, it seems like XAML could be used to implement a lot of the vision outlined by Paul Torrens in his ArcNews article.

What I’d like to see is a thin-client IDE where I could graphically design spatially enabled workflows on a remote server. A good example would be a parcel notification system on a municipal web site. Instead of relying on city staff to write apps, a web site could be provided to allow citizens to design workflows around city activities that impact them. Maybe what is needed is a Spatial Activity Library (SAL) to complement the lower level Base Activity Library. Perhaps each geoprocessing function in ArcToolbox could be wrapped and made available in a SAL and published by ArcGIS Server.

ArcGIS Server, Balkanization and Unintellisensibility

With five ArcGIS Server SDK’s to choose from, it would be helpful to have some sort of matrix summarizing relative strengths weaknesses of each. For now, it sure looks Balkanized.

I’m One of Those Types
Yes, I’m the type of guy who can’t stand stereotypes. You know, the kind that blurts out “generalizations are bad!” when cornered. Generally speaking, generalizations are bad – but not when it comes to IDE’s. I’ve gotten so spoiled on VS intellisense, working with javascript feels awkward. And not because it’s not an MS product – autocompletion in Sql Server Management Studio is quite annoying as well. From what I can tell, static types are what make intellisense possible. With Silverlight I can use intellisense to write all my client side code, if I so choose.

That may change with addition of dynamic types in C# 4.0. Generally speaking, dynamic types are a good thing, but it seems like it’ll make C# more like javascript. Here’s a good writeup showing how dynamic types simplify JSON interaction. Perhaps an understated advantage of SOAP over REST is static types. I guess as long as I have two monitors I’ll survive – with one of them eternally opened to the API reference docs.

Sense and UnIntelliSensiblity
Kirill shows how dynamic types can simplify use of COM libraries in .NET – at the expense of becoming unintellisensible.

This suggests ArcObjects programmers will be able to write code that is visually more elegant than currently possible – yet unintellisensible. It may look pretty during a code review, but I sure feel sorry for any non ArcObjects programmer tasked with altering it. It looks like it would even be possible to write an obfuscator disguised as a prettyfier. It would take Kirill’s first example, strip out the “using”, replace the static type with a dynamic type, and voila, prettier code.