One thing I tend to do, if you haven’t noticed on my other blogs, is time lapse videos. Here’s one I did tonight
It’s actually pretty easy to do, I use a GoPro HD Motorsports HERO Camera
on the time lapse setting, taking a photo every 2 or 5 seconds depending on what I am doing (generally I do 5).
I then take these photos and import them into a new Windows Live Movie Maker. Movie Maker allows you to import photos. If you select all photos and then click on the EDIT tab of the ribbon bar. There’s a duration option there. I typically set the duration for my videos at .05 (.03 being the lowest you can set them to).
One thing of note though, occasionally Windows Live Movie Maker will tell you that the images included are corrupt. If you run into that, you should save your project, close Movie Maker and then reopen the project. That should fix the problem.
Now go out and play with Windows Live Movie Maker and create some cool time lapse videos!
The other day I posted on how to add the new Facebook Comments to your DotNetNuke website. This worked okay for basic modules that only had one content display, but for a module like DNNSimpleArticle this didn’t work well as the URLs for each article didn’t come across as individual URLs because of the way the Facebook code is formatted. When displaying the Comments I also only wanted to show them on individual articles, not on the main article listing.
There is actually a pretty easy fix though, a number of options, you could write a very simple module to do this, you could embed some of this into your Skin, or the method I chose. I wanted to make this work using Razor with the new Razor Host module in DotNetNuke 5.6.1.
For instructions on how to get the Razor Host module installed you should watch the following Video.
You can also watch a brief video showing you some of the included Razor scripts.
What I wanted to do with a custom Razor script was two fold.
- I wanted to only show the comments when we were displaying an Article in DNNSimpleArticle, which in this module’s case would mean there was a querystring parameter being passed in the URL (aid)
- I wanted to have the comments be specific to the article, not to all articles in the module, so I needed to customize the URL for the comments code.
Using Razor this was easy to do. Here’s the code
1: @{
2: object o = this.Request.QueryString["aid"];
3: if(o!=null){
4: var currentPath = this.Request.Url;
5: <div id="fb-root"></div><script src="http://connect.facebook.net/en_US/all.js#appId=#####################&xfbml=1"></script><fb:comments href="@currentPath" num_posts="5" width="600"></fb:comments>
6: }
7: }
The first line starts off the Razor script. Line 2 reads a querystring parameter. Line 3 checks to see if that parameter had a value. Line 4 gets the current URL. Line 5 writes out the Comment script provided by Facebook with the currentPath argument passed in. Line 6 and 7 close out the if statement and the razor script.
To get this to display I setup the Razor Host module to be visible to all users on the site, but I end up hiding the container for the module. You can see this in action on an article I have posted over on SCCAForums.com
Last week Facebook announced a new feature that websites can use to get Facebook Comments onto their web pages. I thought this was interesting as I have a few car racing sites that are using Forums, but also have the DNNSimpleArticle module for main page content. The forums are active, but the DNNSimpleArticle module doesn’t allow for comments as of right now (or in the foreseeable future) so I started to look into the Facebook comments a bit.
From a quick read of their blog post/announcement it looked like the process would be pretty straight forward. Grab some HTML content and stick it onto your page. So I did this for one of the websites, here is specifically how I achieved this, though I ultimately didn’t get the result I wanted (not yet).
Grab the code from that blog post
<div id="fb-root"></div>
<script src="http://connect.facebook.net/en_US/all.js#xfbml=1"></script>
<fb:comments href="YOUR_CANONICAL_URL"></fb:comments>
Change out the YOUR_CANONICAL_URL with the URL for the page you are trying to attach comments to. Insert that into an HTML module at the end of your content. Pretty simple really, EXCEPT that the HTML module will strip the SCRIPT tag right out of the content you try to save. So then what?
I pasted the code into the FOOTER module setting, that puts it after the content in the module, and before the end of the container (right after the CONTENTPANE in the container). The HEADER and FOOTER settings in the module settings don’t get parsed and stripped for security (at least from what I see) so it is a great place to put JavaScript that you need to include.
So now you can have Facebook Comments after the content of your HTML module
That works fine for HTML modules, but unfortunately it doesn’t work for modules that have multiple views associated with them. DNNSimpleArticle for example. It has a VIEW control for the module definition, but that control loads an Article Listing, and loads an Article View if there is an “aid” querystring parameter passed in the URL. The problem with inserting the above Comment code into the FOOTER of the module is that the Comments apply to whatever Canonical URL you put into the code, and that would need to differ for the Article Listing and EACH Article when viewing individual articles in the DNNSimpleArticle module.
I’ll be posting another blog post later this week with a way to get around that, without having to put the Facebook Comment code into the DNNSimpleArticle module itself. (Assuming I can make my idea work)
For more on the Comment system you should check out the Comments page on Facebook for Code Generation and details on how you can utilize Facebook applications to distribute the moderation of comments for your website.
If you didn’t see Shaun’s blog post earlier this week you should give it a good read through. The post announced the fact that starting with Version 6.0 (targeted for Q2 2011) DotNetNuke will no longer be developed/released as a VB.NET Application. All development of the core platform will be in C# (this does not mean that the community modules for the platform will change languages).
Most of the feedback I have seen so far has been rather positive, most folks who use DotNetNuke on a regular basis understand that the language that the framework itself is written in really doesn’t make a bit of a difference to 99.9% of all DotNetNuke based websites. The framework is there for you to build on top of, and while it is open source, it is actually recommended by all experts that you don’t modify the “core” code of the framework, if you need to make changes you do it through the use of modules and custom providers.
Extensions (modules, providers, skins, etc) for DotNetNuke have always been language independent, you can develop your extensions in whatever language you want. I personally have developed all modules for the past 4-5 years (besides the Wiki module) in C# rather than VB.NET out of personal preference.
So the framework being VB.NET or C# shouldn’t make a difference to most people.
People have questioned the decision still, why would DotNetNuke Corporation bother spending time with the conversion? Aren’t there plenty of other things in the platform that could use the attention? What about all the “bugs” this will introduce into the platform? That is the biggest question I have seen from people so far, and I’ll be honest with you. I was one of those people, I had the very same concerns.
When the discussion to convert to C# began I was very much against it. Every one of those folks listened to me and heard my arguments. Having worked at DNN Corp for a year now, and having been part of the community for 8+ years, I know there are plenty of things in DotNetNuke that could use attention to make them better, easier to use, etc. I told Shaun, I told Rob (VP of Engineering), and I told Navin, our CEO.
Before the final decision to convert was made I made some phone calls to engineering and got myself a copy of the C# version of the upgrade package, with VERY VERY early DotNetNuke 6.0 code. I wanted to test this code out myself, I wanted to prove that moving to C# at this point in time was a bad idea.
So I downloaded one of my production websites, I got it up and running locally, and then I upgraded from v5.6.1 6.0.
Do you want to know what happened? The damn website worked….. The upgrade worked. I was very surprised. Sure there were a couple of very minor issues, a problem with the ADMIN pages, but digging through the website, my custom modules worked, my pages worked, my content was all there. My event viewer (event log) was fine, it wasn’t throwing errors, things were working.
This was very early code, sure there were a few things that still needed to be worked on (removing old VB files, etc) but the website was working, and it was working far better than I had expected it to be.
I was sold. I called Rob, I called Shaun, I apologized, I told them I was wrong, and I told them I supported the move to C# because I knew the ultimate benefits would be worth it (see Shaun’s post for those).
So, for all of you doubters out there, I totally and 100% know where you are coming from, I’ve been there, but I think that you will ultimately find that this move is going to be great for DotNetNuke.
That’s not to say there won’t be issues, there are always issues, but DotNetNuke Corporation strives to make each and ever release of the platform better, future releases won’t be any different.
If I haven’t eased your mind, or even if I have, I would encourage you to check out the CTP for V6.0 when it is available later this month. Test out the C# version, run some of your production websites through upgrades in a test environment.
We definitely need your help making sure things work, I will sure be doing a lot more testing of my websites before the official release, far more than I typically do as I generally am limited in time. I will make the time over the next month or two to make sure that I can do all that I can to make 6.0 the best release yet.