VibrantCode

So, I downloaded and installed the IE8 Beta yesterday and decided to play around with WebSlices. I found it really easy to create a simple WebSlice (just apply some CSS Classes) and I decided to try and do this with the Reports Module.

I was suprised with just how easy it was! I have already created a replacement ViewReports.ascx file that turns every Reports Module into a WebSlice. I've attached the new file here, just replace your existing DesktopModules/Reports/ViewReports.ascx file with it if you want to check it out. Any Visualizer should work, but I've only tried the Grid.

CAUTION: This is for preview purposes ONLY! This replacement file has NOT been tested in ANY SIGNIFICANT WAY (other than trying it out once). Back up your existing ViewReports.ascx file BEFORE using this!

Here's the popup you see when you view a report

And here's a screenshot of the WebSlice in action:

Anyway, the file is attached. Try it out on one of your test sites! I'll probably integrate this into an upcoming version in a more configurable way, since it's so easy :).

ViewReports.zip (.54 KB)

UPDATE: Changed to a ZIP file

In this series of blogs, I'm going to follow the development of an RSS Data Source. I'm going to use Visual Studio 2008, but I'll be using .Net 2.0 features so you should be able to follow along in Visual Studio 2005. You can also use the Express editions of Visual Web Developer (both 2005 and 2008 versions should work). All the code will be in VB.Net, but it should be straightforward enough for C# developers to understand (after all, its all .Net)

Continued from Part II.

Part III - Settings

In this part, we're going to add a setting page so that we can change the RSS feed that our Data Source downloads.

In current versions of the Reports Module, Data Source settings are stored in the ModuleSettings table provided by DotNetNuke. This ensures that all copies of the same module instance will share the same Data Source settings (Visualizer settings are not shared between copies). However, Data Source developers need not (and should not) access these directly. Instead, the Reports Module provides a layer on top of the ModuleSettings table called "Data Source Settings". When the Data Source is executed, the Reports Module passes a Dictionary containing these settings (inside the ReportInfo object). To allow users to edit the settings, we go back to the Settings.ascx file we created in Part I.

Let's start with the user interface for our settings page. All we need for now is a place for the user to enter a feed URL. When we're done, it should look like the screenshot below

So, open up the Settings.ascx file and make sure you are in Design mode. First we need to add a label, so users know what they should type in our text box. In the Solution Explorer, find the file: controls/labelcontrol.ascx and drag it on to the design surface.

Next drag an ASP.Net TextBox control, from the Toolbox, on to the surface. You should have something that looks like this:

Now, set the properties of the controls to the following values:

Property	Value for Label	Value for Text Box
ID	feedUrlLabel	feedUrlTextBox
ControlName	feedUrlTextBox	N/A
Width	N/A	100%

Save your changes, and open up the code file: Settings.ascx.vb. Here, we need to add code to connect our text box to the Data Source settings. The key to this is the LoadSettings and SaveSettings methods provided by ReportsSettingsBase. First, we need to import some extra namespaces:

Then, we can implement the LoadSettings and SaveSettings methods.

The LoadSettings method is provided with a System.Collections.Generic.Dictionary(Of String, String) containing the current settings saved for the Data Source. Our implementation uses the SettingsUtil helper class (provided with the Reports Module) to retrieve a value from the dictionary, or return a default value if it doesn't exist (in this case, an empty string).

The SaveSettings method is also provided with the current settings. However, this method is responsible for retrieving the values entered by the user and updating the settings.

Save the file, and navigate to the Settings page on your test module. You should see our new Settings control displayed, as in the screenshot below:

Oops, we still need to put the label text in! We're going to support the DotNetNuke Localization Framework, so we need to put the text in two places.

First, lets add the localized text. Create a Resource File called Settings.ascx.resx in /DesktopModules/Reports/DataSources/RSS/App_LocalResources file and open it. In Visual Studio, you get a nice table interface for editing resource strings. Add the following entries to the table (feel free to tweak the values as you want, just keep the name the same):

Name	Value
feedUrlLabel.Text	RSS Feed URL
feedUrlLabel.Help	Enter the URL to an RSS feed to retrieve data from

Your resource file should look like this after making those changes

Now, go back to Settings.ascx and set the following properties on the label we created earlier:

Property	Value
Text	RSS Feed URL
Suffix	:
CssClass	SubHead

Note: That's a colon (':') in the Suffix property. Also, CssClass is case sensitive.

Now, save and refresh your page. You should see something like the screen shot below:

Now, to change our Data Source code to use this new setting. Let's go back to the /App_Code/RSSDataSource/RSSDataSource.vb file and take a look at the signature for the ExecuteReport method:

The important parameter here is the report parameter. There is a property called DataSourceSettings on that object which contains the same dictionary we created in SaveSettings. First, delete the FeedUrl constant we were using before. Then add following code to the beginning of the ExecuteReport method to get the Feed URL from the settings:

This code checks for the setting, and if it isn't present or if it isn't a valid URL we throw an exception provided by the Reports Module: RequiredSettingMissingException. We pass it the name of our setting and some contextual information about our Data Source (which is provided automatically by our base class. If the setting isn't present, the Reports Module will automatically display a useful error message indicating that the setting is missing.

While we're in the code, let's add HTML Decoding directly to the Data Source, so we don't have to use the HTML Decode converter in the Module Settings. To do that, we change the line that adds entries to the output table so that it automatically HTML Decodes the description:

Make sure everything is saved and go back to the website. You should probably go back to the home page, just to make sure everything is properly recompiled. Go back to the settings page for the Reports Module, and make sure the RSS Data Source is selected. Then configure it with your favourite RSS feed. This time, I'll use my personal blog's RSS feed (WARNING: Shameless plug alert!).

Once you've done that, make sure the HTML Decode property is set and the HTML Visualizer is properly configured, just like in part 2 and click Update. You should see the RSS feed displayed just like in Part 2, only now we can change the URL!

At this point, we have a working RSS Data Source! You can stop here if you want, but in the next part I'll cover packaging the Data Source up so that it can be installed in any Reports Module installation.

Download the code so far.

UPDATE: Part III is now available.

In this series of blogs, I'm going to follow the development of an RSS Data Source. I'm going to use Visual Studio 2008, but I'll be using .Net 2.0 features so you should be able to follow along in Visual Studio 2005. You can also use the Express editions of Visual Web Developer (both 2005 and 2008 versions should work). All the code will be in VB.Net, but it should be straightforward enough for C# developers to understand (after all, its all .Net)

Continued from Part I.

Part II - WebRequests, XPath, and Data Tables, oh my!

In this part, we're going to add the code to retrieve data from the RSS feed. First, we need to create a folder to hold our code. We're going to put our code in the App_Code folder, so it will be compiled automatically by ASP.Net. That way we can save a few extra steps and get straight to the point. You could also put this code in a separate .Net Class Library, and put that library in the Bin folder of your website.

We'll create a sub-folder inside the App_Code folder for our code and call it RSSDataSource:

Next, we need to tell ASP.Net to compile code found in this folder. Open the web.config file, in the root of the website, and find the <codeSubDirectories> section (its inside the <system.web> section). In my version of DotNetNuke it looks like this, but yours may have different <add> entries:

We need to add an entry to this list for our new subfolder. On my system, it looks like this (again, yours may vary slightly):

Now that we have somewhere to put our code, let's create our Data Source! We'll create a class inside our nice new App_Code folder called RSSDataSource.

I'm not going to list the code for the Data Source in this post, because I've attached it to this post. However, I'll go over the general steps.

1. First, we use the System.Net.WebClient class to download the RSS feed. For now, I've hardcoded it to one of my favourite blogs: Scott Hanselman's Computer Zen
2. Next we create an ADO.Net DataTable with three columns: Title, Link and Description
3. Then, we use the classes in the System.Xml.XPath namespace to add a row for each item in the feed to the DataTable.
4. Finally, we wrap the DataTable in a DataView. The Reports Module expects us to return a DataView in order to allow us to do filtering and sorting if we wanted to. We aren't using that feature, so we just create a simple DataView to wrap our table.

There's only one last step to hook everything up. We need to tell the Reports Module how to find our Data Source code. To do that, open the code-behind file for DesktopModules/Reports/DataSources/RSS/Settings.ascx and change the DataSourceClass property to the following code:

And with that, we have a working RSS Data Source! Go back to your browser and go to the Settings page for the Reports Module instance we created in Part 1. Select the RSS Data Source as the Active Data Source, and click update. You should see a very wide grid containing the data from the RSS feed (assuming you are using the Grid Visualizer, which is the default):

Well, that doesn't look very useful does it? Let's start by getting rid of that HTML junk in the Description field. To get rid of that, go back to the Settings page, and add "Description" to the list of columns to HTML Decode.

That should clean up the HTML, but it's still a big grid. Let's use the HTML Visualizer to clean it up a bit. Put the following code in an HTML file and place it in your Portals/[PortalID] folder:

Then, go back to the Settings page, select the HTML Template Visualizer and the HTML file you just uploaded:

Click Update and you should see a much more readable display. It's almost like a real RSS Reader!

Conclusion

Well, that's all for part two. Next, we'll cover Data Source settings so that we can point our Data Source at any RSS feed we want, rather than hard coding it. Then, we add an HTML Decoding feature directly into the Data Source so we don't have to configure the module to decode the Description field. Finally, we'll package it all up so that others can download and install it.

Download the code so far.

UPDATE: Part II is now available.

In this series of blogs, I'm going to follow the development of an RSS Data Source. I'm going to use Visual Studio 2008, but I'll be using .Net 2.0 features so you should be able to follow along in Visual Studio 2005. You can also use the Express editions of Visual Web Developer (both 2005 and 2008 versions should work). All the code will be in VB.Net, but it should be straightforward enough for C# developers to understand (after all, its all .Net)

Part I - Setting Up

First things first, you'll need to install a Source distribution of DotNetNuke. I'm not going to cover that here because there are some other resources out there. You'll also need to install the Source package of the Reports Module. Once you've done this, open your DotNetNuke website up in Visual Studio

After opening it, expand the DesktopModules/Reports/DataSources folder. You should see something similar to the following

Each of the folder under the DataSources folder represents a different Data Source. So, lets get started and create a folder for our Data Source and call it RSS. Inside that folder, we need to create an App_LocalResources folder. Visual Studio provides a special menu option to do that:

Inside there, we must create a Resource file. Even if you aren't planning to translate your Data Source into different languages, the Reports Module uses this file to determine the name of your Data Source, so you must create it. In this sample, we aren't going to use the DotNetNuke Localization framework, so this is the only time we'll need to delve into Resource files. Add a new Resource file to the App_LocalResources folder called "DataSource.ascx.resx".

Open this file and add a new resource key called "DataSourceName.Text" with a value of "RSS".

We've almost got a running, albeit useless, Data Source. There's only one more file to add. Back in the "RSS" folder, add a Web User Control called "Settings.ascx". Open the Code-behind file (Settings.ascx.vb) and replace the contents with the following code:

Save everything and open your Web Browser. Add an instance of the Reports Module to a page and open the Settings page. You should now see the "RSS Data Source" in the Active Data Source drop-down. You can select it, but it doesn't do anything, so don't click Update.

Conclusion

That's all for part one. I know there isn't anything really useful yet, but I want to keep these parts short. Tomorrow, we'll add the code to retrieve data from an RSS feed.

Download the code so far.

Well, I just signed my offer letter so I'm going back to Microsoft for another summer! This time, I'll be working on the ASP.Net team, which is exciting. It's going to be a lot of fun having a chance to contribute to a framework I've been using for the past 2 years (I've almost forgotton what a Windows Form is :P).

I just thought I'd share that exciting news with my readers. However, I do have a few other updates:

1. The Reports Module 5.0 User Guide is almost "content-complete" so I'll just need to get it formatted properly and it should be ready to go live
2. I'm starting a Blog series on Developing for the Reports Module. For now, this is going to have to stand in for a full Programming Guide, but hopefully it will be a good starting point for those of you thinking of writing Visualizers or Data Sources.

Anyway, look for my first post in that series soon. I'll be crossposting it on my DotNetNuke blog, so feel free to check it out there.

So, I'm chilling in my hotel in Redmond watching MythBusters (best show ever!) while I await the start of my Microsoft Interviews at 8am tomorrow morning.

Now, on to things my readers would be interested in :). I'm going to start a series on Extending the Reports Module in the next few days that's going to start by developing a custom Data Source for the module that extracts data from an RSS feed. I'll probably move on to developing a custom Visualizer and even more tutorials.

I'm also going to try to set up a documentation Wiki for the module and pre-populate it with some basic documentation for Reports 5.0.

Anyway, now that the holidays are over, I'll be getting back into blogging regularly, so keep an eye on your RSS readers!

A common question that comes up in the Reports Module forums is "How can I display data relevant to the current User in the Reports Module?". So, I figured I should write a blog post about a feature that has been in the Reports Module for a few versions. When writing your SQL Scripts for the Reports Module, you automatically have access to four parameters: @PortalID, @TabID, @ModuleID and @UserID. When the SQL Script is executed, these are replaced by the ID of the current Portal, Tab, Module and User (respectively).

So, if you wanted to display a list of Roles for the currently logged in user you could use this script:

When you run this script, the current user's ID will be substituted in the place of the @UserID parameter. (Note: This is done by SQL Server itself, which avoids SQL Injection attacks). Also, the {oQ} token is replaced with the Object Qualifier configured for your database (if you configured one in your web.config file)

Here's another example. It's a script that retrieves the Website profile property for each user in the current portal.

The italicized section is the part that actually retrieves the property value, you can replace the PropertyName and PropertyCategory values as you like and repeat this section multiple times to bring back multiple profile properties.

One of the planned future features for the module is to support user-specified parameters. This means you could place a text box, drop down, calendar or other control on the view page for the module and the value of this control would be used as a parameter to the Report. At the moment you're limited to these four parameters, but there's still a lot you can do with them!

After a few delays, version 5.0 of the Reports Module has been released to the Module Release Process. This means that it should be released shortly (though given the time of year, it may take a couple of weeks). I'll be posting some How-To screencasts walking through the new features (and some old ones too) in the next week or so. I'm also working on a full User's Guide to be released shortly.

One important note regarding Reports 5.0: The module requires at least v4.6 of the DotNetNuke core, it will NOT run on a previous version of the core. This is because of the new Visualizer and Data Source installers which use the Package Installer introduced in v4.6. I hope to release a version of the module with the installer portions removed which will be referred to as "Version 4.9".

To give you an idea of what's coming, here's an excerpt from the release notes containing a list of resolved issues in this version (The same list can be found here: http://support.dotnetnuke.com/project/RoadMap.aspx?PROJID=36)

• RPT-5634 JavaScipt error when first configuring Reports DNN _04.05.01
      A JavaScript error was occuring on the main settings page, this has been corrected
• RPT-5676 HTML Decoding in XSL Visualizer
      Fix through RPT-6514
• RPT-4698 Clean up interface for Reporting Services Visualizer
      Interface for Reporting Services Visualizer has been improved significantly the Visualizer has also been renamed to the "Microsoft ReportViewer Visualizer"
• RPT-5715 Include {databaseOwner} token in upgrade SQL scripts
      Scripts have been corrected
• RPT-5791 Run Reports on Demand
      Reports can now be run "on-demand" rather than automatically on load
• RPT-5806 Support the EnableExternalImages property of ReportViewer control
      The EnableExternalImages and EnableHyperlink properties are now supported, along with many others (see RPT-4698)
• RPT-3994 Alternate Data Sources
      Data Sources Framework allows Reports to run queries against other Databases (SQL Server, Access, Oracle, etc.)
• RPT-6466 Disable the Use of Parameters while Caching is enabled
      Paramaters are disabled when Caching is enabled due to a serious privacy risk
• RPT-6514 HTML Decoding and Encoding of fields retrieved from database
      Fields can now be individually HTML Encoded and HTML Decoded before being passed to the Visualizer
• RPT-6516 Report Info Pane
      An info pane displaying the title and description of the report can now be displayed on the main screen
• RPT-6454 Allow Users to specify custom CSS Styles and Classes for the Grid in the Grid Visualizer
      Users can use custom CSS to style the Grid Visualizer
• RPT-6438 Add a setting to enable/disable Grid Lines in Grid Visualizer
      Grid Lines can now be configured in the Grid Visualizer

Keep an eye on the blogs for more updates, I'll make sure to post here when the module is released!

While attempting to avoid infringing on the name from a segment from a popular internet audio talk show, I had an idea for a "quick tip" when I was reading a recent .Net Tip of the Day.

Throughout the product development cycle, occasionally certain methods become obsolete. If you can't modify those methods, will need to write another implementation of the method using a slightly different name or signature. To maintain compatibility, you do not want to remove the old method and break your code. This is where the .NET Obsolete attribute comes in handy:

[Obsolete("Use the new LogRequestEx instead.")]
public static void LogRequest(string feedUrl, string referer)
{
    ...

Setting the Obsolete attribute as above makes a warning message appear in the Visual Studio's Error List stating that the particular call to a method is obsolete. The warning message also includes your personalized message that you pass as the attribute's argument (such as, "Use the new LogRequestEx instead").

So, I figured I'd start of this semi-frequently series of .Net tips with an extension to this one :). Not only can you have Visual Studio display a warning, but if you really don't want people using the method you can configure it to display an error message if the user tries to use the method. For example, in the example above you need only add a boolean value for the second constructor parameter "error":

[Obsolete("You must use the new LogRequestEx instead.", true)]
public static void LogRequest(string feedUrl, string referer)
{
}

More details can be found on MSDN

One of the big concepts in Object Oriented Programming, is the Single Responsibility Principle (SRP), which essentially states that every object in a computer program should have a single responsibility. I recently started thinking about where OneQuery fits in to the whole ORM landscape. OneQuery is designed for a very singular purpose. It is a Database-agnostic Query engine. That alone is its responsibility and I think it should stay that way. So, in fact, OneQuery doesn't fit into the ORM landscape, because it isn't an ORM. OneQuery is directly focused on the problem of writing queries against any database and receiving tabular results (i.e. IDataReader).

Does this mean that you should ignore it if you are looking for an ORM? No, I don't believe so. Just because OneQuery isn't an ORM, doesn't mean it can't work with ORM tools. One of the ideas sitting at the back of my head is to create an ORM called "OneMapper" which would sit on top of OneQuery and add ORM features. The fundamental difference between the combination of OneMapper and OneQuery and other ORM tools is that you could use OneQuery without OneMapper. Tools like SubSonic and NHibernate have a tight coupling between their ORM components and their database query components. The point is, I see OneQuery as being an example of SoC/SRP being applied at a "Product" level, rather than at a Class level. I want OneQuery to be a really good query engine, not a pretty good ORM and I think that separating those concerns makes that much more possible.

The main problem I was thinking about when I dreamt up OneQuery is how DotNetNuke could achieve true Database-agnosticism in its Data Access Layer. One option would be to use a tool like NHibernate or SubSonic to completely rewrite the Data and Business Layers with a true ORM. However the problem there is that it would be a wholesale change and would probably introduce some major breaking changes.

Another option would be to use something like SubSonic's Query Tool (which actually inspired me to develop OneQuery), which allows you to build database-agnostic queries and execute them, receiving tabular data in return (rather than objects). Then, the existing DotNetNuke infrastructure could handle the ORM stuff. This would basically mean replacing the existing "SqlDataProvider" with a "SubSonicDataProvider" and basically avoiding any breaking changes by just scooping out the old SQL Server-specific guts and injecting a tasty cream...oops, I mean Database-Agnostic...filling.

So, why not do that? Well, I realized that SubSonic is, first and foremost, an ORM and it will always be focused on that. The Query Tool is a great feature, but it feels like it's just tacked on to the main ORM component. This has two ramifications: First, the ORM will be the primary focus of development and new features in the Query Tool will be fewer and far between. And second, if you just want the Query Tool, you have to bring along the entire ORM system as well (unless SubSonic does some refactoring). At 644KB, SubSonic isn't huge but it isn't tiny either (though, I don't have exact numbers on what portion of that is the ORM and what portion is the Query Tool).

So, that leads me into the primary difference between OneQuery and other tools like NHibernate and SubSonic: OneQuery is not actually an ORM! Its a query engine, and hopefully it will be a darn good one too. That is its primary responsibility and any other cool features (like ORM components or LINQ support) are totally separate concerns.

Now, having said all that, this is just what I've been thinking about recently. Maybe it's all crazy talk. Feel free to sound off in the comments and tell me that :).