I was reviewing the MSDN guidelines on naming your namespaces, which hints at the solution to an issue I see a lot, namely “in which namespace do I put non-specific members”? If you’re wondering what I mean by that, take a look through your own hierarchy of namespaces and look for any that end .Common, .General, .Generic, .Core, .Universal, .Wherethehelldoesthisgo etc.
The MSDN guidelines state “A nested namespace should have a dependency on types in the containing namespace”, so to turn this on its head, members which are used throughout many nested namespaces should go in the parent. To give an example, say you’ve got some classes to deal with accountancy business rules in these namespaces:
and you’ve got some helper methods in a static class which help you work out taxes, which would potentially be used across all three of these namespaces, don’t put them in
instead put them in
You’ll find your namespace hierarchy is much cleaner and suddenly makes a whole lot more sense.
User controls (.ascx files) are a great way of re-using chunks of HTML and logic, easing maintenance overheading and ensuring you don’t repeat yourself, but used poorly they have exactly the opposite effect and vastly overcomplicate applications.
Take this scenario; you open up an .aspx page to fix a reported bug, only to find only a set of references to .ascx files. Undeterred, you open the control you believe contains the offending code, only to find… more .ascx references! In a page I came across recently, not only were there multiple levels of nested user controls, but in some cases those controls were used only once in the entire application. As a general rule, if you’re not going to re-use it, don’t extract it out into a separate file.
Don’t believe the blurb, it took me hours. In fairness, I think the two issues that slowed me down were down to hosting it on a Windows box.
Firstly I encountered “specified CGI application misbehaved by not returning a complete set of http headers”. I eventually found my answer via this post on the WordPress forums. It turns out that there’s a database access .php script (/wp-includes/wp-db.php) which needs to be replaced in version 2.3.3 if you’re running on a Windows server, although I notice the page mentioned in the forum is now unavailable so I’ve attached the .php file in case anyone else needs it.
The second error I encountered was something familiar to me as a more general IIS exception, namely “This virtual directory does not allow contents to be listed” when viewing the root directory of the site. In other words, IIS has been through its list of ‘default’ pages and hasn’t found a match in its configured list. Adding index.php to the list brought things to life instantly.
I have to say I’m very impressed now that everything’s up and running. I made the choice to use this particular engine because the feedback I’d read seemed to be mostly positive, and I can see why. The content management UI is slick, and I haven’t even scratched the surface of what it’s capable of.