For the last year and half I have increasingly turned to one module as my goto solution when building out new capabilities. For me the
Reports Module is proving itself to be the Swiss Army knife of the DotNetNuke module world. With some of the features coming up in future releases of the Reports module this will become even more evident to anyone who takes the time to learn how to use the module.
So why do I feel so strongly about the reports module? It is mainly because of the architecture that Andrew Nurse put in place to allow you to create custom data sources and custom visualizers. This architecture makes it easy to get data from almost anywhere and then to have complete control over how it is displayed.
For most people the built in DotNetNuke Data Source, and XSLT Visualizer can handle most of your needs. You can query any data in DotNetNuke and then use XSLT to display that data. If you have not used XSLT before, you are missing out on a very powerful tool. Whether it is displaying a blogroll, the MarketPlace Monitor or even building an entire eCommerce site, XSLT gives you a lot of capability to take XML data and transform it into as simple or complex a page as you can imagine.
[more]
Right now there are three core modules with extensive XSLT capability built in: Forms and Lists, XML, and Reports. Forms and Lists is a great module, but it forces you to store data in the tables it defines. XML also has great XSLT functionality, but it only handles XML that is stored in a file or that is retrieved from a URL. If I want to report on Data, no matter where it is stored, my only option is the Reports module. The Reports module includes a custom data source that allows you to read UDT data, and it wouldn’t be hard to write a custom data source to read an XML file.
Even though I love the Reports module, the Forms and Lists, and the XML modules both have some features that are not currently supported by the XSLT engine in the Reports module. They all have their place in your DotNetNuke arsenal.
So if your need is just to display some data on the page, and you want something more than a simple table, then the Reports module is the tool for you. In the rest of this post I’ll walk through a recent requirement I had for our company intranet.
One common requirement in many intranets is that it should be easy for employees to find out basic contact and organizational information on other employees. DotNetNuke includes much of this information in the default user profile. For my purposes I wanted to display the following pieces of employee information:
Name Photo Job Title Department Manager Phone Numbers (Work, Cell, Fax) IM Email Location (Region, Country and Time Zone) With my data elements identified, I can use the built in User Accounts screen to access the Manage Profile Properties page. From here I can add any profile elements I want to capture. The default set of profile elements cover most of my requirements, and it is easy enough to add any fields which are missing. Now employees can edit their own profiles and we’ll use the reports module to display those profiles.
To configure the reports module, you will need to be logged in with a Host account. The reason for this requirement is that the SQL query we are building could potentially access any data in the database. In a multi-portal environment you wouldn’t want one admin access data for another portal to which they didn’t have access. Since hosts have unlimited access to all data in the system, they are needed for defining the data source. Once the data source is defined then any user with edit permissions will be able to configure the visualizer.
Go to the module settings page and navigate down to the Data Source Settings section. For our example, I can use the DotNetNuke Data Source which uses the default dataprovider defined in the web.config. Then I enter my query. Finally, I will use the Show Xml Source link to display the resulting XML from my data source query. I will save this xml to a separate file so that I can test my XSLT during development.
Notice in my query that I just select all of the data from a custom view. You will not have this view on your DotNetNuke installation. One limitation I found very early with the Reports module is that it stores all of its configuration data in the ModuleSettings and TabModuleSettings tables. This limits the amount of text I can use for the query. I know from experience that querying profile data can get very complex and will easily exceed the size limitation of the settings tables. As a result I almost always create a custom view or stored procedure for my query. Because each piece of profile data is stored in a separate row of the UserProfile table, we have to do a join between the User table and UserProfile table for each property we want to include. As you can see from the query below this quickly becomes quite long, although most of the logic is just repeated over and over.
SELECT ...