On Monday we discussed how to save setting information for our modules. Today we want to pick back up where we left off and deal with retrieving that information, both in the LoadSettings() method and in the view module.
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
Since each instance of a module that we put on a page should be able to have it’s own configuration information, it is necessary to have some place that will allow us to configure it.
For example, you may have a module which could display itself in a number of different ways. You need some way to set this and the settings ASCX file and the associated codebehind file is the place to do this.
< (more…)
Last week we talked a bit about Inter Module Communication, the ability of one module to notify another module on the page that something needs to happen without requiring a post back. The other need you may have is something I refer to as Cross Page Communication. This is not a DotNetNuke term, I just made it up today.
Here’s the problem. In some cases, you may have a module that you’ve placed on a page that should only ever be on one page. In my case, this was the checkout module. I needed some way of retrieving the page that that module was on so that I could create a hyperlink to that page from my modules that displayed my products and my “mini cart” module that displayed a summary of items in the shopping cart.
Here’s how I did it:
We’ve been through most of the basics now with respect to creating the View module of the DotNetNuke module set. We will be moving on to the Settings module next. But before we do, we need to review a few important properties and methods of the PortalModuleBase class that the view module inherits from.
This list will not be a complete list, but it will cover the most important APIs for this class.
Everyone knows (or should know) that handling exceptions is a fundamental feature of the .NET environment. And most of the time if we don’t handle the exception ourselves the .NET environment will handle it for us. However, letting the environment deal with the exception leaves us with absolutely nothing intelligent for our customers to report back to us when they call to report an error.
So, at a minimum, every application should have some way of getting some of the critical information back to the developer about what happened when the exception happened. Log it to a file. Log it to a database. Send an email. But do something.
Fortunately, DotNetNuke has an API call that we can make that will do all the hard work for us. All we need to do is to make sure we call it.
