Download DOWNLOAD
Forums FORUMS
Blogs BLOGS
Forge FORGE
Help HELP
Marketplace MARKETPLACE
DotNetNuke Home
You are here >   Development > Forge > Module - Reports
Register  |  Login
Purchase

DotNetNuke® Project :: Reports Module

The Reports module provides a simple, but flexible, view on data from your DotNetNuke Database. SuperUsers (aka "Host" users) can develop Reports by building a SQL Query and visualizing it with one of the Visualizers built-in to the module or a 3rd-party Visualizer.

How can you use the Reports Module?
  • Display a table of custom data from your Database
  • Display a list of Users in a specific Role
  • Display advanced queries that pull data from multiple tables
  • Display a chart of the number of users in each role
  • Display a report from SQL Reporting Services (EXPERIMENTAL)
Features: What can the Reports Module do now?
  • Display the results from any SQL Query in one of many ways:
    • a Grid
    • a Chart
    • an HTML-based template
    • an XSLT-based transformation
    • or anything else you want with the extensible Visualizer framework
  • Display reports from SQL Reporting Services
  • Import/Export Report Definitions through standard Import/Export Content
Roadmap: What are the future plans for the Reports Module?
  • Full support for the ASP.Net ReportViewer Control and SQL Server Reporting Services
  • Custom Parameters such as @PortalID, @TabID, @UserID that are filled in when the query is run
  • Custom Data Sources to enable the module to display reports containing data from:
    • Your DNN Data Provider
    • Other SQL-based Databases
    • XML Data
    • UDT Module Data
  • Allow SuperUsers to predefine a set of Reports that Admins can use (at this time, only SuperUsers can create Reports)
The project can be downloaded here

View_Blog

Sep 2

Posted by: Jon Henning
9/2/2005 

I am happy to announce that the ability to do Whidbey style client callbacks (Asynchronous Javascript And XML - AJAX) is coming in the next version of DotNetNuke.  Check out the document here.  Here is an exerpt from the document's sidebar.

It is a common practice to have client side script need to send data to the server.  Within a web browser this is typically accomplished by either a POST or a GET.  Both of these commands usually require a repainting of the page, since it is usually the form within the page that does the post, or the document’s location being changed to do the GET.  Over the years, there have been many attempts to improve the interaction between the client side code and the web server.  Technologies like Remote Data Services (RDS), Remote Scripting, Javascript Remote Scripting (JSRS), and the Webservice Behavior were developed to address this interaction.  RDS is outdated since it relies on COM and ActiveX.  Remote Scripting was introduced and was quite successful since it utilized a Java Applet to initiate the request to the server.  Unfortunately, Netscape decided to not support unsigned Java Applets starting with version 6, thus making it about as useful as an ActiveX control.  Additionally, the JVM is no longer being included with the Windows platform.  The Webservice behavior is a very cool way to have the client-side code interact with the server, however, since it relies on a behavior and the MSXML parser, it is an Internet Explorer only solution.  That leaves JSRS, which works by creating a hidden IFRAME object on the page with a FORM embedded in it that can be posted to the server.  This makes it the most widely accepted standard for the interaction, since it only requires the browser to support the IFRAME object and FORM elements. 

 

 

Tags:

9 comment(s) so far...

Re: DotNetNuke ClientAPI Callbacks

This just too good to be true........ Great!!! Fantastic.

I really think this will open up DNN being more accepted as a small/medium business platform. Developers will be able to do so much more with custom modules and keep performance at a more acceptable level if those modules are complex

and... Thank you.

Now I can hardly wait for version 3.2

By Hooper on   9/5/2005

Re: DotNetNuke ClientAPI Callbacks

This is great news! I've been wondering over the last year-plus whether DNN would go the way of the xmlhttp call-backs. This will make DNN *very* hot indeed!

By dagilleland on   9/7/2005

Re: DotNetNuke ClientAPI Callbacks

I have read that AJAX is not stable

http://ajaxblog.com/archives/2005/05/25/synchronous-requests-bad
http://richui.blogspot.com/2005/09/ajax-latency-problems-myth-or-reality.html
http://www.jonathanboutelle.com/mt/archives/2005/09/jep_castelein_o.html

By shadis on   9/10/2005

Re: DotNetNuke ClientAPI Callbacks

Not sure what you mean by not stable. Lets review the articles you linked.
1) This deals with synchronous calls, which could hardly be called AJAX, since the A in AJAX stands for asynchronous. It is a known fact that the javascript that executes in the browser is synchronous by nature. By coding a synchronous call that could take some time to finish it will therefore appear to be locked up. The same would hold true for any long running javascript you have (for example write a loop that iterates a variable 10000 times).

2) Didn't review the entire article, but it struck me as odd that they are trying to pin the latency problems on being AJAX specific. The entire internet browser experience can have issue with latency. If your users will have issue with this, worrying about AJAX should be your last worry... worry about writing any internet application.

3) This article again discusses synchronous calls... my response is the same as 1)

Your post seems rather vague in nature... is there some specific question you wish to ask?

By jhenning@solpart.com on   9/10/2005

Re: DotNetNuke ClientAPI Callbacks

We are doing this already using DNN 2.1.2, custom modules and AJAX.NET (http://ajax.schwarz-interactive.de). Suffice to say we have had no stability problems, it works a treat and our only issue is non-compliant browsers.
Having it built-in will give us an incentive to move to DNN 3.x

By verdant on   9/11/2005

Re: DotNetNuke ClientAPI Callbacks

I was confused myself by the "Asynchronous" part, where I felt like you that it meant the nature of the actual RPC call. I have since come to understand from Jesse James Garrett that he meant that the RPC is happening asynchronously to the page flow. It seems from my experience that people who never did Javascript RPC before almost universally understand this to be the meaning, whereas those of us who cut our teeth on it before the Ajax name was coined assume the deeper technical meaning.

At any rate, the Asynchronous in AJAX does not mean that the RPC call waits for the response before the script continues. On the contrary, most people I've talked to would consider it loony to use a synchronous RPC call in a web page, although I do it all the time on intranets and the world has yet to come to an end.

By bashley on   9/13/2005

Re: DotNetNuke ClientAPI Callbacks

ComponentArt just released their latest version of controls with AJAX support and so far I'm very pleased with their performance and stability. Having now "tasted" AJAX, I immediately began to wish that DNN supported AJAX. All I can say is I'm delighted to hear this announcement that DNN's next version will support client callbacks.

This will hopefully enhance performance of applications, especially ones like mine that are becomming increasingly complex and heavy. To not have to repaint the page very time will be nice.

By databasedude on   9/14/2005

Re: DotNetNuke ClientAPI Callbacks

Harish Nair -
I am new to Dotnetnuke and I should say, it is a wonderful piece, however i am not new to AJAX and a combination of AJAX and DNN would be a great combination.
thanks

By nairharish on   10/26/2005

Re: DotNetNuke ClientAPI Callbacks

Jon,
I have an complete AJAX framework build on namespaces I am working on getting into the client API section. Email me at gleonardo@laacware.com and I can help with this.

Greg

By gleonardo on   1/5/2006

Sponsors

DotNetNuke®, DNN®, and the DotNetNuke logo are trademarks of DotNetNuke Corporation

Hosted by MaximumASP