15 February 2008

DotNetNuke: Early returns

We did our first code drop to QA last week on our first project that employed DotNetNuke. DotNetNuke is gaining popularity because it allows developers and administrators to take a Chinese menu approach to web site design. It's a framework for developing apps within ASP.NET: developers code modules of functionality (traditionally in VB.NET, but C# works just fine) which can be rearranged on web site pages without recoding.

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 EnableClientScript="false" for everything.

1 comment:

David Gorsline said...

Derek on my team has been working some of the caching-related problems that QA has turned up. He writes that a setting of -1 disables caching altogether. I don't know what the difference between settings of -1 and 0 might be.