More Querystring Fun

Blog Post created by pkaiser Employee on Apr 30, 2010

Wow, it's been a while since I've found time to blog. I enjoyed meeting many new people at the OSIsoft Users Conference earlier this week, and also seeing lots of old familiar faces. While it's fresh in my mind, I thought I would reiterate the new querystring functionality that was a popular discussion topic at the Users Conference.


If you saw the presentation that I made with Tamara Carbaugh on Wednesday morning, then you already know about all of the new querystring support added to PI WebParts in version 3.0. If not, then you'll be glad to learn that querystrings are an even more powerful mechanism for simple integration in PI WebParts. We've supported querystrings in our TreeView and TimeRange web parts for some time, and in my last blog on the topic I talked about the querystring support in our ad-hoc trend. In PI WebParts 3.0, we've dramatically extended querystring support to the rest of the web parts, and eased some of the restrictions regarding their usage.


In the past, the limited querystring parameter support found in the TreeView and TimeRange parts suffered from a few constraints:

  • The names of applicable querystring parameters were fixed. For example, there was no way to apply a querystring parameter with a simple name such as “Start” to the “Start Time” property of an instance of the RtTimeRange web part. The only querystring parameter that could be applied to the “Start Time” property of RtTimeRange had to be named “RtTimeRange_StartTime.”
  • Querystring parameters were automatically applied to all instances of the applicable web part. In other words, the querystring parameter named “RtTimeRange_StartTime” was applied to all instances of the RtTimeRange web part on the page. There was no opportunity to “opt in” (or “opt out”) on a web part instance-by-instance basis.
  • A single querystring parameter could not be applied to instances of different parts. The querystring parameter named “RtTimeRange_StartTime” was automatically applied to every instance of RtTimeRange on the page, if any, but could not be made to have any effect upon an instance of RtTrend on that same page.

To overcome these constraints, PI WebParts 3.0 extends querystring parameter support to any connectable web part property, and allows the configuring user to specify the name of the querystring parameter to use. This is accomplished through the use of our existing web part connection dialog. Now, when you click our "lightning bolt" button to connect a property to a providing web part, in addition you can connect it to a querystring parameter. You don't have to do both; you can connect a property to another web part without connecting it to a querystring parameter, and you can connect a property to a querystring paramter without connecting it to a providing part. Or you can connect a property to both a providing web part and a querystring parameter. When a web part property is connected to a querystring parameter, but the parameter does not appear in the querystring in the URL, that connection is simply ignored.


So what happens when a web part property is connected to both a querystring parameter, and another web part? And what if that property has a user-specified (i.e. typed-in) default value? Obviously, at the time a web part page is rendered, it is now possible for a web part property value to be provided from multiple sources. For all web parts, a value provided from a connected web part takes precedence. If there is no value from a connected web part, then the value from the querystring paramter is used. If there's no value from a connected web part, and no value from a querystring parameter, then the default value is applied.


As noted in my previous querystring parameter blog, and in the presentation that I gave wih Tamara earlier this week, querystring parameters are a tried-and-true mechanism for simple UI-level integration between PI WebParts and other web-based or web-aware applications. They're widely-used, reliable, and so easy to implement that even a Product Manager could do it. Or an Engineering Group Lead like me, that hasn't written code in a while...