PDC 2008 - Here I Come

Travel time again. Destination Los Angeles. There I'll spend the next week learning everything that Microsoft will try to teach me - and probably then some.
See you all at the parties! I'll be the guy in a gray t-shirt, with a laptop and a high-tech phone. If you find me, I'll buy you a beer or something!

Flash Rss Reader

Another little flash gadget I just made... An RSS reader. Yes, I know it's an original idea - but it seemed like a good, comprehensible, and to some degree useful thing.

For fun I made iPhone style navigation - in the sense that you need to drag right or left to move between items.
It lists the blog feed from labs.episerver.com.

The trickiest thing was to handle all the security around loading a URL in flash. Flash can only load data from the same domain as it is located on (or another domain that has a crossdomain.xml file in the root, allowing flash access). Anyway, the simple solution was to make a small rss proxy in c# (around 3 lines of code) and put it on my test-domain together with the flash app.

Allan version 1952

Just stumpled upon Yearbookyourself.com. What a cool feature! You can see how you would look like on a high-school yearbook picture from 1950-2000.

In case you're wondering, here's how I would have looked in 1952 (when I was -27 years old).

Oh, the power of DHTML

I spend Sunday visiting Copenhagen's Zoological museum with my wife and son. Great museum, even my 14 months old son loved it - all the stuffed animals to look at and pet! Nevertheless, I came across some stuffed lemmings there and quickly found myself floating back memory lane to that wonderfully 90-something game that I used to spend so many hours enjoying.

I figured someone probably had put it online by now - but I hadn't imagine a DHTML+Javascript only version of it. Check it out! Very cool.

Wiki vs CMS - the difference is psychological

When I started in EPiServer AB one of my first tasks was to "make a wiki plugin for EPiServer". Naturally, being new in my job, I enthusiastically started working. However, it pretty soon dawned on my that I didn't know what a Wiki really was. Sure, I use wikipedia daily and understand how it works, I know that "Wiki" means "fast" in Hawaiian, but it wasn't really that obvious to see what the difference is between a CMS like EPiServer CMS and a Wiki. I ended up writing an internal RFC on the subject, and awaited comments while I moved on to tons of other tasks, piling up on my brand new desk.
Around half a year later, I'm in a small but luxurious hotel in the Stockholm archipelago together with the rest of the EPiServer Research team, brainstorming on which new prototypes we should make for our big partner event in june. Again, the Wiki came in to play, and I spend a week or so making a working prototype of it, which I later demo'ed at the Partner Summit and hopefully soon will find time to finalize and ship as open source...but I digress. After reading Deane Barkers excellent blog post on the subject I figured I might share my views as well. So here goes:

 

"A wiki is a medium which can be edited by anyone with access to it, and provides an easy method for linking from one page to another." (Wikipedia)

"Contrary to their reputation, Wikis are content management systems that can be managed. They simply take a different approach to content management by choosing to emphasize speed and flexibility rather than strict controls." (CMSWatch)

So, what I really see initially is that a Wiki is a Content Management system focused on collaboration and knowledge sharing. A typical CMS has a some editors and many readers, where a Wiki has many editors and many readers. Not all that much of a feature. Just as Deane I've also looked at some of the key wiki features:

1. The name of an article is embedded in the hyperlink.
2. Articles can be created or edited at anytime by anyone (with certain limitations for protected articles).
3. Articles are editable through the web browser.
4. Each article provides one-click access to the history/versioning page, which also supports version differencing ("diff") and retrieving prior versions.
5. The most recent additions/modifications of articles can be monitored actively or passively.
6. Easy revert of changes is possible.
   On top of those features I would also include:
7. Easy linking
8. Easy creation of new pages

(Wikipedia's list of Wiki features)

All features that's either out-of-the-box or just a matter of configuration in any state-of-the-art CMS, like EPiServer CMS.
So, is a CMS = Wiki ? I didn't really see the difference until after I made a prototype and allowed my coworkers to start to use it.

The prototype I made was based on EPiServer CMS, and consisted of the following:

• A UI that looks like wikipedia
• View-mode editing of pages
• Support for WikiSyntax ( like [[links]], etc.)
• Ability to create a new page on-the-fly if there's a link to a page that doesn't exist.
• Each page consists of X elements that can be edited independently
• View-mode version control
• Discussion Forum for each article
• Handling of multiple concurrent edits
• etc.

The moment I had a prototype up and running it didn't take me long to see the strength of these relatively small changes. It's addictive.
So, I realized that the difference between a CMS and a Wiki is really psychological. A Wiki's strength is fast and quick knowledge sharing - with everybody contributing to gather all their knowledge together. Why? A CMS is typically used for websites and/or intranets. Text-writers and editors use it to publish and structure their perfectly written articles. And here is the core of it all....A wiki doesn't need to contain perfect, complete articles. In the nature of a wiki anyone can add their knowledge instantly - either to existing articles or by beginning new ones - but without the obligation to finish them. And hence people are much more likely to start sharing their information. Still not with me? Here's an example: My knowledge of about the country of Norway is limited. If I were to write an article (or a blog post) on Norway I would have to do a lot of researching and then spend a lot of time writing and compiling all this knowledge. End result: I'd never get it done (mostly because I'm lazy, but also because I'm busy and not all that interested in the subject (sorry, Steve)). However, on a Wiki I wouldn't mind at all adding the few things I know about Norway to an existing (or non-existing) article. It would be something like this:

"Norway is a good place to go skiing. They have a lot of oil-money. Beers are rather expensive there. The capital is Oslo." 

But the point is, that I would share the little I know. And maybe someone else with access to the same wiki knows something else about Norway and will add it. Because they are not obliged to writing a complete, perfect article. That's why Wikis work efficiently for knowledge sharing - and that's the difference to typical websites built with a CMS (in my humble opinion).

But of course Wikis can be based on a CMS like EPiServer. Just wait for it :-)

My first attempt at a banner ad - enjoy :-)

Really annoying Live Messenger bug

I guess we all know those weeks where everything seems to break down at the same time.....Harddisk recorder stops recording, light bulbs burst, car smells / sound unhealthy, tax authorities make a mistake that costs you a bundle, emails gets lost - and whichever direction you're driving there seems to be a traffic jam. For some obscure reason these weeks always happen at the most inconvenient times - and always several problems at the same time.

This week is so far proving to be one of those weeks for me. I had a suspicion that this would be such a week already monday morning when I finally got my laptop running Vista (yeah - I know what you're going to say - I'm asking for it) kicked alive and got one of my most important work tools Windows Live Messenger running. As I opened my Live Messenger windows I could actually see all my 150+ contacts drop from their respective groups down to "Other Contacts" one by one - without there was anything I could do about it. After whining for a bit, and running around in desperate circles, I finally tried to appreciate the humor of the practical joker at Microsoft who implemented this amusing feature. Ah well, after spending a lot of time organizing my contacts again I thought I was good to go....UNTIL TODAY - when I open my messenger to see all my friends, colleagues, business partners, bots all having a party in the "Other Contacts" group again!

Dear Microsoft: this is where it stops being funny, please fix. And while you're digging into the source anyway, could you have a look at the vista core - there's a couple of things that also needs a looking at.

Multiple Templates for a PageType

It looks like a Dev / Partner summit is the perfect birthplace for ideas to grow. Here is yet another idea that grew out of discussions with partners, eMVPs and other Guru's at the summit: It could be cool to have multiple renderings (templates) for a page type. Today several PageType's can share the same template, but it's not possible to specify more than one template to use for a given PageType - a feature which would be very handy when for instance you wanted to make a special set of templates to show your site to mobile users. Or perhaps just special templates for IE or Firefox. Or maybe just a "Printable" set of templates. In any case I think this can be an important building block in making flexible websites.

So, naturally the day after the summit (a bit hungover I must admit) I sat down and began coding. There's several ways to achieve this goal - VPP's being one of them, but to keep it simple I decided to just hook into the UrlRewriting and change the internal url for the pages before they were executed. I ended up with this simple prototype that can change the executing template for a page depending on the User Agent of the client. I'll supply both the source and the compiled versions below - but keep in mind that it's just a prototype and it IS PROVIDED AS IS.

In order to use it, place the assembly in your bin, and add the following to the section-registration of your web.config:

<section name="multiRenderings" type="EPiServer.Research.MultiRenderingSection, MultiRenderingPlugin" allowLocation="true"/>

Then, After the "episerver" section you can add a list of the renderings:

<multiRenderings>
  <renderings>
    <rendering name="IE" userAgent=".*MSIE.*"/>
  </renderings>
</multiRenderings>

This rendering above will try to execute the IE template for userAgents matching the regular expression: ".*MSIE.*" - meaning that all IE browsers will be sent to templates located in the "IE" subfolder (if such templates exist).

On my test site I have the following folder structure:

/
	Templates
		MyPage.aspx
		MyPage2.aspx
		IE
			MyPage.aspx

 

When looking at a page that uses "MyPage.aspx" IE will be using the "MyPage.aspx" located in the "IE" folder, but since MyPage2.aspx doesn't exist there, MyPage2.aspx will fall back to the one in "Templates".

This will probably become a lot more elegant as the plugin evolves - but I think it already now might proof useful to some of you, which is why I post it here.

Download from labs.

Busy Times

A lot of people has been asking me what I'm up to lately - and complaining that my posts aren't as frequent as they used to...
I know it's been way too long since I blogged on this blog. It's not because I have nothing to blog about - in fact every day a new interesting blog-topic springs to mind and I begin writing it...But before I finish it, work or family-life or another idea interferes and break away my concentration.

I just got back last friday from Sweden where I had spend more than a week. First I went to a terrific(!) partner summit and after that I stayed to work at the office with the rest of the Research team. Unfortunately I learned the hard way that I should stay away from local food when traveling to exotic places like Stockholm, so that took a couple of workdays out of my calendar.

At the summit I presented a Wiki built on EPiServer - one of the projects that's been taking a bit of my time lately. Soon I'll do a dedicated post about it - and put it public somehow.
Meanwhile I'm also working on a ton of other stuff - like a new version of EPiDiff, Defining design patterns for EPiServer, LINQ, and a couple of gadgets that I'll reveale in the coming weeks.

Sunday I'm leaving DK again and once again heading for Ukraine, where I'll get to meet our new team in Kiev as well as some developers from a Partner in Kharkov.

Mixing ASP.NET MVC with an exisiting WebForms web application project

I had a chance last night to integrate the new cool asp.net MVC with a "normal" web application - it went rather painless. Read the recipe on my work-blog.

Nightly Fun with 301

WARNING: GEEKY STUFF.

 

Do you ever have difficulty falling asleep at night, because your brain begins to code the moment your tired body hits the bed? Well, I do every once in a while. And then I know that I can either toss and turn all night or sneak downstairs and code for a while - just to get it out of my system.

Last night was one of those nights. This time, though, I decided to make something simple but useful. The idea had been in the back of my head ever since I visited a large client recently who was getting ready to move a big and popular web site in the media industry to EPiServer CMS 5.

Basically this is the classic problem that I'm trying to solve: When moving a web site to a new platform it often happens that the url to the individual pages changes which breaks links, search engine ranks and results in a lot of 404 errors. For instance, with Friendly URLS in EPiServer a page that used to be called "/articles/article124145.html" might now get the friendlier path"/News/New+Website+Launched/". So, my solution to this problem is simply a generic HttpModule that loads a series of old-path / new-path sets from a text-file when the web application is started and then makes a quick check for every request to see if it's actually an old URL being requested. If it is, it'll do the correct thing and send back an HTTP 301 Permanently Moved reply with the new location of the document. That way both global search engines and various caches should get updated and no links will be broken. Simple, but it seems to work - and to my luck it was so easy to code that I still got most of a good nights sleep.

 

    public class RedirectModule : IHttpModule
    {
        private Dictionary<string, string> map;

        public void Init(HttpApplication app)
        {
            app.BeginRequest += new EventHandler(app_BeginRequest);
            map = new Dictionary<string, string>();
            //Load from file
            StreamReader sr = File.OpenText(ConfigurationManager.AppSettings["UrlMapping"]);
            string s = null;
            while ((s = sr.ReadLine()) != null)
            {
                string[] parts = s.Split('|');
                if(parts.Length==2)  map.Add(parts[0], parts[1]);
            }
            sr.Close();
        }

        void app_BeginRequest(object sender, EventArgs e)
        {
            HttpApplication app = (sender as HttpApplication);
            if (map.ContainsKey(app.Request.Url.LocalPath))
            {
                app.Response.Status = "301 Moved Permanently";
                app.Response.AddHeader("Location", map[app.Request.Url.LocalPath]);
                app.Response.End();
            }
        }

        public void Dispose()
        {
        }
    }

 

As said - it didn't keep me up all night.

In order for it to work the following adjustments needs to go into web.config:

<appSettings>

  <add key="UrlMapping" value="c:\\inetpub\\UrlMapping.txt"/>


</appSettings>

<system.web>

  <httpModules>


    <add name="RedirectModule" type="EPiServer.Research.RedirectModule.RedirectModule,EPiServer.Research.RedirectModule"/>


  </httpModules> 
</system.web>

 

And the mapping file should just be a series of [path]|[new path], one on each line like this:

/oldpath/article.html|/newpath/newarticle.aspx

/oldpath/oldpage|http://www.google.com/?q=oldpage+topic

WebResource.axd gives 404

My colleague, Michael Knudsen, has been struggling with a customer & partner for several hours now with an annoying problem on an EPiServer 4.62 site just moved to a production server. Finally, after browsing through half the web and getting valuable feedback from most supporters / developers known to man, a simple solution was discovered.

To save other people the agony he's gone through he persuaded me to post the solution here...

 

Problem symptoms:

When clicking on a button in a webform the following javascript error occurs: Webform_Postbackoptions is undefined. A little simple debugging later it turns out that the page in fact did get a 404 when requesting a web resource (javascript) from the server - which is where the method is defined.

<script src="/WebResource.axd?d=14ZW9Y1So0D_eFk6_pguuw2&amp;t=633359999849186250" type="text/javascript"></script>

If you don't know what webresources does there's a good intro here. This problem had us all stunned for a while - lots of theories going through our heads...."It must be a web.config problem - some handlers are interfering with each others", "Perhaps asp.net isn't properly installed on the server", "But it's working on my machine", "Is this using AJAX?", "Can't we just put the dev. server where it works into production", etc. were some of the thoughts going through our heads as the problem took over our common sense.

 

Solution:

Uncheck this checkbox in IIS:

 

 

Skype and Port 80

This is probably old news to a lot of people, but I just ran into an error message in IIS7 on my Vista saying that "The process cannot access the file because it is being used by another process" whenever I tried to start my default website.
Ah well, I thought...Better shut down various other applications although I was wondering what file it could possibly be that there was a sharing conflict on. So, all other app's seemingly shut down, but I still couldn't start my website.
Before I got the error I had been spending numerous hours getting more and more annoyed at IIS7 so I concluded that this was probably something caused by yet another pseudo-paranoid default security setting somewhere - and I guessed that the error was probably misleading and in fact not related to files at all.
Luckily at this point Ruwen came to my rescue and pointed out the obvious that I somehow had missed:
Ruwen: "it could be skype blocking the port 80"

And it turned out that he was (as always) right. Skype listens by default on port 80 and thereby blocks the device (LISTEN on 80) that IIS is using when starting a site.
After visiting Skype's advanced settings and turning off that obscene feature saved my day.