Philo's WebLog : Developer

A simple conceit vs. questions left unasked

philoj — Sat, 27 Oct 2007 06:38:00 GMT

Here's a fun mental exercise - on the one hand, we have the "everyone is lost but me" syndrome, where someone will charge off on a course of action, despite many many warnings about the perilous nature of his quest, until he runs smack dab into that windmill.

And yet we have "there is no such thing as a stupid question" - where even though everyone around you seems to know what's going on, and you see some flaw, the refrain is "it never hurts to ask the question."

How do we reconcile these? One the one hand, we say that charging off contrary to everyone's opinion is bad; but on the other hand questioning the course when everyone is charging off is good.

The issue is ego.

"Everyone is lost but me" isn't about one person heading in a direction that everyone else warns about; it's about believing that you are smarter than everyone else around you. I can cite two examples and a counter-example from, of all places, Hollywood:

Batman&Robin, where Joel Schumacher killed a multi-billion dollar franchise because he was sure what the public wanted to see was more camp like the Batman TV show of the 60's. Never mind that Tim Burton's dark, adult dramas had raked in sinful amounts of cash - when everything is working right, obviously it's time to change the formula. The box office punished Schumacher and comic book movies went into remission for ten years, until Spiderman and Raimi's understanding of the public brought it back.
Annapolis (and the thought that prompted this post). This one is near and dear to my heart, since I'm a Naval Academy graduate. As I understand it, the director/producer people wanted to make a movie set at the Naval Academy - hoping to trade a bit on the patriotism borne by 9/11 and launch a new era of Top Gun movies. They approached the Navy about filming at USNA. The public affairs officers in the Navy read the script, and asked for a few changes. The producer/director people refused, and the Navy refused permission (so the movie was shot in Philadelphia). This turn of events was crushing to a lot of USNA graduates, and at first we blamed the Navy for being so unbending. Now that I have seen part of the film, I understand. One of the objections the Navy had was about a romance between a Plebe (freshman) and a female upperclassman. This is fraternization and an expulsion offense at the Naval Academy. I'm sure the producer/director people thought this made it a "forbidden love," but it just came away as completely and utterly unbelievable. I had to turn the movie off. So because the producer/director people thought they knew better than Navy officials what a USNA movie should look like, it tanked.
The exception: The Lord of the Rings. When Peter Jackson first landed the role as director, he talked about "his vision" of Tolkien's work. Several hundred thousand angry emails and letters from fans later, he took their rebukes as a challenge and decided to go the other way - be as accurate as humanly possible to the original work. The rest of that, is history.

Of course, there's an exception to all of this - there are times that you may be so sure in your vision that you decide to ride off despite the warnings of others. Many visionaries have changed the world this way. Sometimes it's still ego, but I think a large number of times what sets them apart isn't thinking "everyone else is lost but me" but rather "everyone else is looking for the path, but I think I can find a shortcut" - not doubting the intelligence of everyone else, but believing they've found insight into a new path.

A fine line to walk, to be sure.

And yet you'll sit in a room of people you know are smarter than you who are discussing a plan and settling onto the details when you're sure you've spotted a flaw in their plan. Is it ego to ask about it? Well, it may be ego to assert that you have found the flaw in their plan and their all stupid; but I think again - many folks who ask (or sadly, don't ask) that question aren't sure they're smarter than everyone else - often they just think they are the ones who have missed something.

Who was it that said "don't let your ego write checks your body can't cash..."?

InfoPath & SharePoint screencast demo

philoj — Fri, 28 Sep 2007 08:01:00 GMT

As follow-up to the "hook InfoPath to a database" demo, here I'm taking a step back to a simpler form - building an InfoPath form to be used on its own in conjunction with SharePoint.

http://channel9.msdn.com/ShowPost.aspx?PostID=344635

In the next few videos I'm going to cover:

InfoPath, xml schemas, and xml
An advanced InfoPath form connected to a database
Connecting an InfoPath form to a .Net web service
Connecting an InfoPath form to a SQL Server web service
eForms & workflow in SharePoint

(Just a reminder - this and other fun InfoPath 2007 stuff all covered in my book...)

I'll also be covering more business intelligence content (SQL Server Analysis Services, ProClarity, PerformancePoint - stay tuned!)

SQL Server Analysis Services in ten minutes

philoj — Mon, 24 Sep 2007 21:29:00 GMT

Analysis Services has been part of SQL Server for a while, but it's underappreciated by most. I've posted another video on Channel 9 to try to share what a powerful capability this is for understanding large volumes of aggregated data.

More than just the simple demo (showing a cube, clicking through some dimensions, pulling the data into Excel 2007), Analysis Services opens the door to truly powerful analytic capabilities in data mining, visualization, and (with PerformancePoint Server), scorecards, dashboards, analytic charts, and planning scenarios.

I'm not trying to trivialize the technology - OLAP cubes are definitely something that's a short time to learn, a lifetime to master. But I am trying to demystify some of this stuff so SQL Server devs & DBA's can get an idea where to start.

Short video, but I'm trying to keep them under ten minutes.

http://channel9.msdn.com/Showpost.aspx?postid=343717

Philo on EDI

philoj — Mon, 24 Sep 2007 07:29:00 GMT

I wrote this post on Joel On Software in 2004 in response to a newbie asking about EDI. Since then I have referred several people to it, but a few times I've found the post tricky to find. So, instead of constantly relying on the benevolence of Joel acting as a library for me, I'm going to recycle bits and post this here. The advice is targeted towards EDI, but it really is good general purpose advice for building ETL or any kind of document parsing...

Step 1: Get sample data from every trading partner. Refuse to do anything until you have this. Claim work stoppage, announce loudly at meetings you're stalled, send emails to VP's, whatever - GET DATA FROM EVERY PARTNER BEFORE STARTING.

Step 2: Make zero assumptions. Provide error cases for every possibility

Step 3: Get the ANSI X12 specs for the document. Read them. Compare the sample data from #1 to them. Be prepared to create program flows for every line in the implementation guides BUT look for lines that aren't used by your partners. Any line you can't find being used, document it. Once you have a full list, send that list to your manager for "I don't see these fields being used - do we need to implement them?" Get the answer in writing.

Step 4: Make sure your code can provide for the lines in step 3 when some partner starts using one of them the day after you deploy.

The hardest part about EDI is that the rules are observed mainly in the breach, and nobody makes partners follow the rules. I built my 810/850 parser as a class hierarchy, which ended up serving me VERY well - it was very modular, and changes like those in step 4 above turned out to be relatively straightforward.

Final note: make sure you know what versions the partners are using, too. :-)

A "drill through" web part

philoj — Wed, 27 Apr 2005 23:58:00 GMT

This MSDN article shows how to implement a SharePoint web part that can act as a consumer or a provider. However, if you try to use it as a "drill through" web part (another web part filters the results in this web part; clicking on this web part filters or populates another web part), it won't work (actually it will; but it will give unpredictable results)

The reason is that the filter value which filters the grid isn't available when the page is reloaded for the second click-through, and so the index returned on the postback points to the wrong row. The simple solution is to store the selected index in a ViewState variable and test against both the ViewState and the returned datagrid index, then filter as appropriate.

Philo
I had no illusions
That I'd ever find a glimpse of summer's heatwaves in your eyes

Emailing a different InfoPath form

philoj — Tue, 26 Apr 2005 01:33:00 GMT

I recently needed to create an InfoPath form that enabled the user to post the data to another user in a format they could open in *their* InfoPath form. After some thought, I went with the idea of running an XSL transform on the data and posting it via an email connector.

Of course, first I needed to create the XSLT. Obviously you can do this in notepad, but I prefer tools that are less likely to make my eyes bleed. I chose to go with Altova's MapForce - it's a great visual designer for mapping one schema to another:

I extracted the form files from each InfoPath form and loaded the myschema.xsd files as source and destination. MapForce handled most of the mapping, connecting similarly-named nodes. Then I generated the XSLT. I had to do a quick edit on the XSL to provide the processing instructions and pull out the schemaLocation attribute on the root. (You can probably do this in MapForce too, but I was in a rush...)

So, next thing - add the xslt to the form as a data connection. You want to create a data connection that will Receive Data from an XML file - then you can select your XSLT file and add it as a resource.

Now create a data connection to submit the form via email - set properties as needed.

Add a button and add form code - I'm working in jscript so that I didn't need a fully trusted form.

The final step, add the following code:

//Get the current form data
var CurrentForm=XDocument.DOM;

//Get the transform
var XSLTFileDOM=XDocument.GetDOM("MTCXSLT");

//Initialize the final xml DOM
var tmpDOM=new ActiveXObject("MSXML2.DomDocument.5.0");
tmpDOM.validateOnParse=true;
tmpDOM.async=false;

//Perform the transform; strDOM gets the XML String
var strDOM=CurrentForm.transformNode(XSLTFileDOM);

//Load the XML String from above into our DOM variable
tmpDOM.loadXML(strDOM);

//Post the DOM via email.
XDocument.DataAdapters("SubmitToMTC").SubmitData(tmpDOM);

Voila!

Philo

Creating a Structured Product Labeling Editor

philoj — Sun, 06 Jun 2004 08:16:00 GMT

The challenge: use InfoPath to create an editor for the Structured Product Labeling (SPL) subset of the HL7 Clinical Document Architecture (CDA) schema.

I've done quite a bit of document-centric work, and my philosophy has always been to design an XML schema first, because from an xsd, all other things can flow:

InfoPath can generate forms from schema
BizTalk can generate maps from schema
There are EDI tools to generate implementation guides from schema
XMLSpy can generate databases and code from schema

So when I was told there was an SPL schema to work from, I figured this was a one-day job, tops.

I was wrong.

Here's what a drug label usually looks like in the physical form. Now, one of the great features of InfoPath is that you can just point it at an xml schema and get a form out of it. However, doing this with the SPL Schema (this isn't complete - the included files aren't there; see the SPL schema link for the whole schema) yields a pretty unsatisfying result.

The problem is that the schema has a whole lot of metadata, and what is there for content is just markup, like HTML (imagine trying to autogenerate a form from the schema for xhtml - it doesn't reflect how people really use the schema).

This is, of course, in retrospect. Going in, I couldn't get the hang of why the form wasn't getting me where I needed to go. It wasn't until I looked at the sample SPL XML - that's when the markup concept clicked and I started looking at the SPL schema as a destination instead of a source.

Another consideration is that the SPL Schema serves the label, not the drug or the company. What this means is that the information in the schema is geared towards describing the medication, but there may be additional information regarding the drug, the label editing and approval process, or other considerations that the pharmaceutical company wants stored with the label.

These two considerations indicate that the label is best served by using an authoring schema to store the information and generating the SPL XML from that schema. Since InfoPath natively stores its data in XML, the InfoPath schema can serve as an authoring schema nicely. (Alternatively, if the pharma already has a business system in place to store SPL-type information, InfoPath can be designed to interact with that system)

So - next week we'll lay out an InfoPath form to serve the label, designed from a blank form to save directly to XML.

Philo

Healthcare / HL7 solution

philoj — Fri, 04 Jun 2004 17:51:00 GMT

Over the next few days I'll be posting a series of articles covering my trials and tribulations in creating an “HL7 Generator” - specifically using InfoPath to generate XML in the Structured Product Label format, which is a subset of the Clinical Document Architecture.

Here is an image of the (nearly) completed form.

As usual, it turns out the best approach was to look at it sideways...

Here's an (updated) approximate schedule of the articles:

6/7/2004: Analysis and SPL overview
7/12/2004: Form Design
7/19/2004: Code
7/26/2004: XSLT and views
8/2/2004: Task pane

Of course, this is subject to change as I write...

Philo

InfoPath Context Sensitive Help

philoj — Sun, 25 Apr 2004 23:10:00 GMT

InfoPath SP1 (public beta at the link; final due out this summer) includes a lot of cool changes, both in the UI and behind the scenes (most notably the ability to stuff managed code behind the form). First I'm going to cover the OnContextChange event and using it to create context-sensitive help.

To create a managed code InfoPath form, you need to download the InfoPath Toolkit for Visual Studio .Net - this provides the templates for InfoPath in VS. Once installed, open Visual Studio, create a new project, select Microsoft Office InfoPath Projects, then either “Visual Basic Projects” or “Visual C# Projects” (I'll be using C#), and “InfoPath Form Template” from the “Templates” pane.

Name your project, click “OK” and you've got an InfoPath project and form. (Also notice that under the “Project” menu in Visual Studio you've got some new InfoPath commands, most notably “Open InfoPath” for those times you close the form designer)

So, for our context-sensitive help we're going to need an HTML file containing the help. Create your file - all you really need to do is append all the help paragraphs/articles into a single file. The way I handled context sensitivity is to wrap each help segment into a DIV, then hide all the DIVs and show the appropriate DIV based on the control selected. Other possibilities include using HTML anchors and scrolling to the anchor for the article, or even creating a document with an empty DIV, then pulling the text from another location and dynamically inserting it into the document.

So, I have an HTML document with a series of DIVs. I used FrontPage 2003 because I found the layer handling helped out a lot. (View | Task Pane, then in the Task Pane menu at the top select “Layers”) You'll want each layer/DIV to use the following tag:

For [Name] use the control name for the control you want the DIV associated with.

[Thanks to Josh Bertsch for help with the following code, C# and jscript]

Now add the following jscript to the <HEAD> of the file:

This will, after a 1-second pause, zip through the DIV tags in the file, showing the one whose ID is the same as the control name, and hiding the rest.

Once you're happy with the file, in InfoPath go to Tools | Form Options, then the Advanced tab. In the “Custom Task Pane“ section check “Enable custom task pane”, then click the “Resource Files“ button and add your file. (NOTE: if you change your help file later, you'll have to go to this option, remove the file and add it again, otherwise you won't see your changes). Once you've added the file, then it should be available in the drop-down for “Task pane location“ - select it.

Now, in InfoPath go to the Tools Menu, Programming, and click “On Context Change Event“ - this will create and take you to the OnContextChange event handler in the VS.Net IDE.

Add a reference in the project to Microsoft.mshtml.

Use this code in your OnContextChange handler:

if (e.Type == "ContextNode")

{

string aLoc=e.Context.nodeName;

aLoc=aLoc.Replace("my:", "");

HTMLTaskPaneObject taskPane=(HTMLTaskPaneObject)thisXDocument.View.Window.TaskPanes[0];

mshtml.HTMLWindow2Class window=(mshtml.HTMLWindow2Class)taskPane.HTMLDocument.Script;

window.execScript("waitForContext('" + aLoc + "')", "JScript");

}

That should do it - now just remember that the DIV id has to be the same as the name of the control. Also watch out for width/height definitions on the DIVs - best to just let the task pane do the formatting.

Philo

Book Review: SharePoint, Building Office 2003 Solutions

philoj — Sat, 17 Apr 2004 22:31:00 GMT

I bought Scot's book hot off the presses, since it's the first major SharePoint 2003 book. When I got it, I breezed through it, and I'll be honest - I was unimpressed.

Well, I had reason to browse through it again, and this time I just sat down and started reading it. That's when I realized - certain book publishers that use multiple authors had taught me not to bother reading computer books through, as they were so disjointed they worked better as technical manuals. So that's what I'm used to - being able to flip a few pages and find the thing I'm looking for.

Scot's book is different. It harkens back to a day where you could actually read through a book and learn a new technology in a structured manner. If you take the time to read the book from start to finish (it doesn't take long - if you skim the tutorials you can probably get through most of it in a single evening) it's a good thorough introduction to SharePoint. And I mean thorough - there are tutorials on building web parts, working with page templates, creating data views in FrontPage, integrating Windows Single Signon...

(Incidentally, I'm not trying to cast aspersion on one method of publishing over another - I'm simply trying to indicate the different “reading philosophies“ each may require)

He also has a nice walkthrough for creating a new portal from the ground up - laying out areas, sites, as well as explaining users and groups.

All in all, I give this book a healthy thumb's up for anyone who wants to learn SharePoint admin and development - for the first book out of the gate, it's an excellent reference to have.

Philo