Typically, a module is written as three user controls: a View, an Edit, and a configuration Settings combination view/edit. The View control might present a grid or list of entities (blog posts, say), and then the Edit control would be used to edit one existing entity or create a new one. Or the View module might just be a widget that encapsulates content from another source, like a stock ticker or a Google map, and there would be no Edit module.
DotNetNuke (ugly name, that) is open source, and the weak API documentation reflects this fact. The search engine is often overloaded, so I've taken to using Google to search within the site. And it's usually the case that a method or property just isn't described in sufficient detail. Sometimes the only hits are someone's unanswered question in a forum: "Does anybody know how this thing works?" There is a book from Wrox of middling quality, Professional DotNetNuke 4.
One of the services that the DotNetNuke framework provides is caching of module content. If your module is serving semi-static text (like a Welcome box) or slowly-changing data like automobile traffic reports, you probably don't need the content to be refreshed second-to-second, and the admin can configure an appropriate cache timeout. But if your module provides any interactivity and validation (for instance, a new user registration control that collects name and address), you really don't want anything to be cached. When you, the developer, prepare a module for deployment, you can specify a default cache timeout of 0 seconds. But you can't count on that value being used in all deployments. I predict that a lot of our support calls will center on caching issues.
We've also noticed some problems, not well-described, with ASP.NET validator controls running client-side, and so we've specified