There is a lively discussion on the DotNetNuke Core Team forums about DNN stylesheets. If there is one area of DNN that I don’t care much for, it would be in how DNN handles stylesheets. It’s a bit messy and leaves even the most CSS-savvy designer scratching their head about how/where/why a particular style was inherited by a particular element.
Personally, I don’t think there is a need for host, portal, skin, container and module stylesheets. There should be one stylesheet used on the page and that is the skin stylesheet. All classes required by a page where the skin is applied should be defined in this stylesheet. While this may require a bit more work, it is definitive and portable.
Continuing my quest to have a fully-integrated version of DasBlog with DotNetNuke, I have made some progress.
My original intent was to leave the DasBlog core untouched, but as I poked around, it became clear that this is not to be. I started by putting the DasBlog source in a folder structure that would allow seamless conversion of the DasBlog aspx pages to DNN controls. I created something like this:
/DotNetNuke/DesktopModules/Speerio_DasBlog/{main DasBlog web files}
After several false starts in getting the IIS application mapping correctly, I had a DOH! moment. I moved the DasBlog web.config into /DotNetNuke and made /DotNetNuke into an application. That worked…almost…got a bunch of compiler errors, but at least I was making progress.
The source of the errors was that in several places in the code, DasBlog uses Server.MapPath(“somefolder/somefile”). Of course, this doesn’t work too well if it’s not in the app root. Time to break out the trusty and hard-working Search and Replace and replace all such instances with “~/DesktopModules/Speerio_DasBlog/”. Lift-off!? Nope…no such luck. Ran into an annoying VS.Net bug that prevents strong-named assemblies from working properly some of the time. Google says lots of people are having the same problem and the known solution is to not have strong-named assemblies (what kind of solution is that?) or build twice. The assembly in question is FTB and since I am not at the point where I can yank it out, I opted for the build twice.
After more of this, I now have DasBlog working using the revised folder structure. Next step, blow away the DasBlog security and have it look to the HttpContext instead.
As I prepare new releases of my modules for DNN 2.x, I am trying to add as many features as possible that will make the transition to DNN 3.x easy. One of these is localization. DNN 3.x uses non-compiled .resx files to store localized resource strings. The files are stored in sub-directories of the control to which they apply.
This is all quite good because it allows different modules to be installed with their supporting resx files. However, after careful consideration, I decided I am not going to follow this route for any Speerio products. There are two reasons for this:
1) The resx format is too verbose for my needs and does not offer any significant advantage to a standard XML file other than the ability to store binary resources.
2) The location of files is difficult to manage. I think grouping of files by locale is more logical than grouping based on the control the file belongs to.
So, I have created the Speerio.Web.Globalization class which I can use interchangably in DNN 2.x and DNN 3.x. The file format is very simple:
The file is named {AppName}.locale.xml (example: FileManager.en-US.xml)
All files go into ~/Controls/Speerio/Globalization/{locale}
Now, when I am ready to have a Spanish version of my modules, I have to copy the contents of the en-US folder into es-US, rename the files to include the correct locale, zip up the folder and email it to the translator. With a handy batch file and using the cool command line WinZip add-on, I can do this in about a minute. When the translated files arrive, I unzip them back into the folder and I am done.
I am assigning each Speerio control a “Locale” property. Once set, this will ensure that the correct language file is read and cached (by a class that inherits from DictionaryBase and caches based on a filedependency on the xml file). The property also
I am not sure my way is better. From a performance standpoint, there is no difference since after first request strings are read from cache. But I do think my way is easier to manager and more intuitive. Besides it gets me localization in DNN 2.x and DNN 3.x.
I recently switched to Das Blog as my blogging software and so far I am loving it. It has all the features one expects and then some.
Since DotNetNuke lacks a good blogger, I have started a project to make Das Blog into a DNN module. There are several challenges to this, and over the coming weeks, as I delve deeper into this project, I will document my findings here.
Just to be safe, I asked Omar Shanine for permission, and he was kind enough to grant it.
