EPiServer

EPiCode Awards

Dan Matthews — Mon, 17 Nov 2008 12:35:04 GMT

EPiServer Norway are associated with an EPiServer community project called EPiCode which had its annual awards on the 12th of November as part of the Christmas Tech Forum. I was really pleased to see the Module of the Year award went to my pals over at NetworkedPlanet for their EasySearch module. Unlike some of the other modules on EPiCode, it isn't free to use commercially - but it is free to download and try out and fills a nice gap in the EPiServer search space.

A bunch of other 'active contributors' were lucky enough to get an iPod Shuffle in the awards - including me for contributing CloudCuckoo and HyperThumbnail on behalf of Interakting. Thank you EPiServer Norway!

You can read more here.

EPiServer vs. Open Source

Dan Matthews — Tue, 11 Nov 2008 10:58:05 GMT

Introduction

Interakting use both Open Source and proprietary products to deliver solutions for many companies. We always try to select the best tool for the job, and when it comes to Content Management it is no different. We have a range of tools we consider using including various Open Source tools (e.g. Nuxeo, DotNetNuke) and also our proprietary offerings (EPiServer, ADXSTUDIO). In the context of many projects it would certainly be possible to deliver a ‘successful’ project in either a proprietary or an Open Source solution. However, when we consider budgetary, functionality, deadline, support and longevity constraints, all of these areas are problematic in the Open Source arena, whereas proprietary systems such as EPiServer can provide an arguably better and more cost-effective solution. This article discusses some of the reasons for this. The majority of 'pure CMS' sites we deliver are on the EPiServer platform and so this will form the basis of our discussion. Interakting is an EPiServer Solution Partner.

Budgetary

With a proprietary CMS such as EPiServer, the main costs are ‘up front’. The client would be buying a licence to use EPiServer CMS, and the cost of this covers the effort and time taken by the vendor to develop and support the product. This means that the vendor does not need to find other ways to recoup their costs beyond the licence fee and an optional small annual support fee. The client can therefore budget for the outright licence as a clearly transparent and defined cost.

Open Source costs are far less clear, as companies who ‘own’ an Open Source initiative may give the software away ‘free’ but then seek to recoup their costs, even if only running costs. This is usually done by support contracts, consulting or selling additional ‘modules’. It is easy to be trapped into a ‘free’ product and then find that the actual cost is far higher.

Functionality

As proprietary systems are designed to be sold as widely as possible to reach the maximum number of customers, functionality in proprietary systems is usually excellent and if additional functionality would assist their sales then the company owning the product will often update their core product or provide value-add modules at low or no cost. This is very much the case with EPiServer, who have grown rapidly due to their responsiveness to customer demands and now have many thousands of seats worldwide. The CMS is particularly user-friendly and intutitive and can be used by novice users without the need for costly training.

In the Open Source arena this becomes more complex. The popular view is that the community ‘works together’ to build a product for the good of the community. This works well, to a point, but ultimately people are not entirely altruistic. Sooner or later (and sometimes always) they only contribute to things that benefit themselves. This means that the ‘out of the box’ product is often minimal functionality, and even if it is fairly well featured then those features are often not very flexible and designed for the use of the company that commissioned them with specific needs. It is unlikely the community will help add or update functionality and therefore it is left to the project team to do so, which can be fairly hard and time consuming. User training is likely to be required, particularly post deplyoment when users change jobs and new users need to work with the CMS.

Deadline

As a general rule, any proprietary systems must be designed to provide a very rapid solution as this is a key selling point since the market is very competitive and unforgiving. In this regard EPiServer stands up very well which is one of the many reasons that Interakting has selected this tool. The well-featured out of the box nature of EPiServer, together with the well-documented and supported APIs, mean that a robust solution can be built rapidly and efficiently. The tools are built with the clients business needs clearly in mind as much as the developers.

In an Open Source project, it has generally built by developers with a very code-centric approach. There is an expectation that the basic product will be customised by developers as needed, and the out-of-the-box functionality capability is usually minimal. Even with ‘starter’ kits for a particular tool, there is often a large amount of code and customisation to be done. Agencies promoting open source solutions capitalise on this aspect as it is very lucrative to develop the added functionality needed for more complex reqirements such as multi-lingual non-Latin support

Support

With EPiserver, as part of the licence agreement, the vendor undertakes to provide support and their reputation relies on this support being accessible and effective. The support is also usually rapid and efficient to respond with managed Help Desks staffed by knowledgeble individuals. They are able to respond with authority on support issues as they designed, wrote, maintain and own the codebase.

For an Open Source tool, the support is either an expensive add-on from the company providing the tool or is community based. If a company is supporting a tool this is often not so much of a problem, although there is an issue that they are supporting code that they quite possibly did not write. From our experience (remember that we also work with Open Source solutions when we feel it appropriate), support from the community is often slow and inadequate for projects that have a critical path.

Longevity

EPiServer is committed to the products they sell and even if they discontinue a product will generally provide migration or upgrade paths. Generally speaking, it will also be clear in advance whether a product will be passing out of support and therefore a proper exit or migration strategy can be planned well in advance. EPiServer is also helpful in that, in the event of it ceasing to trade, it has made its code available to its licensees through an escrow arrangement at a nominal annual cost (although this is optional).

Open Source projects are often left unfinished or unsupported once the community using them has moved onto something different. As a general rule, Open Source projects have a limited time in which they are actively updated and maintained and once a critical inactivity threshold is reached then they effectively become ‘legacy’, are taken into closed source or amalgamated into something larger. It can also be harder to plan an exit strategy as the ‘lifetime’ of a product is usually unclear.

Summary

In summary, we believe that for the many projects, the unknowns and variables involved in taking the Open Source route will result in a slightly higher initial cost of development and deployment and a significantly higher cost of ownership over a two year period following the initial go-live.

By choosing to use a well-proven CMS which uses the .NET framework, a project is grounded on a solid, well defined and tightly costed product and the real cost of deployment and support over a 2-5 year lifetime can be estimated with a far higher degree of accuracy. Ongoing maintenance, functional enhancements and support will also be easier to define and budget. Finally, a large pool of .NET developers able to work with EPiServer and are readily available at competitive day rates meaning the client has total flexibility and would not be locked into any single supplier in the future.

If you're looking for a CMS solution for your web site, shouldn't we be talking?

NickServ and HydraIRC

Dan Matthews — Mon, 23 Jun 2008 10:11:59 GMT

I've been hanging out on the #epicode IRC channel for the past few months, and over time I've played with several IRC clients such as XChat, Mibbit (for the Web) and HydraIRC. One of the things that you do most often on IRC is /msg people. The server that I use for #epicode is FreeNode. This server requires you to register you nick before doing a /msg. If you try to /msg without registering, you get an error message back from the server. XChat, annoyingly, didn't show me the IRC error and I spent quite some time trying to figure out what was wrong. Mibbit behaves nicely, but you have to enter your credentials every time which is a pain. (tip: on Mibbit, click the 'Auth' link next to the server dropdown on the main page and you can enter your NickServ password straight in there!) HydraIRC behaves nicely too, but I've been having problems getting it to store my NickServ password so I don't have to enter it every time.

In theory, the password is saved by HydraIRC when you create a favourite, but it doesn't seem to work for channel favourites, only server favourites. No, I've no idea why. If you look in the XML profile file in the HydraIRC installation directory all the information looks correct. Maybe they work for you but they sure are a pain for me. Thankfully, there is an easy workaround. HydraIRC has a bit of a hack called Command Profiles. I wouldn't describe them as a well-documented feature but they do the trick. Essentially a command profile is just a set of IRC commands that can be run automatically when you connect to a particular IRC server. You can find the command profiles by going Options -> Prefs... -> Command Profiles. In there, you create a profile using a special name so that is picked up on logging in to a server. The name, in my case, is FreeNode_OnLoggedIn. Within that I simply put in my NickServ identification.

When I go to my #epicode channel favourite now, it automatically runs my identification with NickServ so that I can /msg people without the pesky error message and having to register myself manually with NickServ every time!

New module on EPiCode

Dan Matthews — Tue, 10 Jun 2008 12:13:32 GMT

At the EPiServer Partner Summit I was chatting over dinner to Andy Brodie of Networked Planet. He was remarking that it would be nice within EPiServer to have the capability to show site thumbnails when you hovered over hyperlinks. This intrigued me so when I got back to the UK I did some investigation. There are sites on the internet that do provide a service for this, such as websnapr, but ideally I wanted something that I had full control over.

Time to start coding :)

After some investigation on the web I found a great article about the WebBrowser control and ASP.NET. I tailored it to my needs and got a little thumbnail generator working. I also built a set of JavaScript functions that would show the thumbnails on hyperlinks using DHTML. Next I built a Control Adapter that would pick up EPiServer properties and parse them for hyperlinks. If it found hyperlinks it would insert references to my JavaScript functions. Lastly I wrapped all this in an assembly complete with my Single-Assembly VPP method and using dynamic web resource references.

And so HyperThumbnail was born. Go check it out on EPiCode or see the sample on B&D EPiLabs (hover over the hyperlinks in the content). Deploying to your own site couldn't be easier - simply drag-and-drop the DLL and a .browser file into your website folders.

Google Translate and .NET

Dan Matthews — Tue, 20 May 2008 15:20:26 GMT

Google have released a lovely little API for their Google Translate service. It uses a RESTful interface and returns a JSON object in the HTTP Response. The usual way to use this would be AJAX-style in client side JavaScript. This might not always be what you want to do though. For example, if you have a server resource in English and you want to show it in the page as Spanish you wouldn't want to render it in English and then have some page load event client side to translate it. You really want to do it server side and render it on the page as Spanish straight away.

Of course, Google know this and so they have provided a couple of snippets on their Google code site for PHP and Java. It should probably be expected, but they decided not to provide a nice .NET snippet. Looking around on the web, I can't find any .NET snippets for it and so I did some digging myself to put together a solution.

Before I throw out the snippet, it's worth explaining briefly what JSON is and what libraries are available. JSON is an object definition 'language' similar conceptually to XML in that it is effectively name tags / value pairs but it has the added advantage that it is part of the JavaScript language definition and can be 'eval'ed in JavaScript to give you a client-side object. This is great for AJAX websites. Whilst you could cook your own JSON handler, there are a few JSON libraries out there for .NET. In fact, Windows Communication Foundation has some JSON support built-in. The only problem is that most of the libraries out there are to do with serializing and deserializing .NET objects as JSON objects. That's fine as far as it goes, but it relies on you already having a well-defined .NET type. With Google Translate, we are getting a JSON object as a string that has no well-known .NET type to deserialize to. It might be possibly in theory to map it to an object or even map it to XML but I explored those options and found them incredibly convoluted.

Thankfully you don't need to write your own little JSON parser though because I did find one library out there to do the job, LitJSON. It has a couple of the usual serializer/deserializer features but in addition it also has a feature to parse JSON into a simple hashtable/array. I tried to do something similar with JSON to XML with WCF but couldn't get it to work. One of my colleagues, Stephen Horsfield, did - and I've included his technique after mine.

And so to the code. The snippet below assumes that you are running this in a web form with the following four web controls:

txtSource - textbox for source text
txtTranslated - textbox for translated text
ddlFrom - drop down list with the 2-letter language values for the source language
ddlTo - drop down list with the 2-letter language values for the destination language

Of course you could easily swap these with command line args or whatever you like. I have put the snippet in C# and the .NET 2.0 framework, but of course you could rework it for VB.NET or even for .NET 1.0.

        1: // do a check to make sure that we aren't making Google unhappy

       2: if (txtSource.Text.Length > 500)

       3: {

       4:     throw new Exception("Google Translation license forbids more than 500 characters to be translated at once!");

       5: }

       6:  

       7: // create the web request to the Google Translate REST interface

       8: WebRequest oRequest = WebRequest.Create("http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q=" + HttpUtility.UrlEncode(txtSource.Text) + "&langpair=" + ddlFrom.SelectedValue + "%7C" + ddlTo.SelectedValue);

       9:  

      10: // make the web call

      11: WebResponse oResponse = oRequest.GetResponse();

      12:  

      13: // grab the response stream

      14: StreamReader oReader = new StreamReader(oResponse.GetResponseStream());

      15:  

      16: // put the whole response in a string

      17: string sContent = oReader.ReadToEnd();

      18:  

      19: // parse the string into the litJSON simple object model

      20: JsonData oData = JsonMapper.ToObject(sContent);

      21:  

      22: // write out the translated text

      23: txtTranslated.Text = oData["responseData"]["translatedText"].ToString();

You could enhance this by using the Google Translate API call to auto-detect the source language, but for simplicity I haven't bothered with that extra step.

So lets see what it would look like with WCF. You'll need to include a using statement for System.IO, System.Xml and System.Runtime.Serialization.Json (and reference the appropriate DLLs):

       1: XmlDocument doc = new XmlDocument();

       2: XmlDictionaryReader xr = JsonReaderWriterFactory.CreateJsonReader(s,

       3: XmlDictionaryReaderQuotas.Max);

       4: doc.Load(xr);

       5: xr.Close();

       6: s.Close();

For more details see the complete post on Steve's blog.

And that is how easy it is to call Google Translate from .NET! I'm currently thinking of some funky ways that I could integrate it with the EPiServer Edit mode. There are all sorts of possibilities. Suggestions on a postcard of how you might want it to look. Maybe a right-click option on the navigation tree? Maybe an extra button in the editor? Maybe something that catches the event when a language for a page is created?

Lastly, a tip on the 2-letter languages. I used the System.Globalization feature of .NET to create the drop down lists with their names. Snippet below:

       1: CultureInfo [] aCultures = CultureInfo.GetCultures(CultureTypes.NeutralCultures);

       2:  

       3: foreach (CultureInfo oCulture in aCultures)

       4: {

       5:     if (ConfigurationManager.AppSettings["SupportedLanguages"].IndexOf(oCulture.TwoLetterISOLanguageName) >= 0)

       6:     {

       7:         ListItem oItem = new ListItem(oCulture.EnglishName, oCulture.TwoLetterISOLanguageName);

       8:  

       9:         ddlFrom.Items.Add(oItem);

      10:         ddlTo.Items.Add(oItem);

      11:     }

      12: }

All that is needed after that is a line in the web.config like so:

       1: <appSettings>

       2:   <add key="SupportedLanguages" value="ar,bg,zh,hr,cs,da,nl,en,fi,fr,de,el,hi,it,ja,ko,no,pl,pt,ro,ru,es,sv"/>

       3: </appSettings>

Hope this is useful to someone. There's a whole load more that could be done such as error checking and catching but that is for a later post once I work out how far I can take this.

Interakting - Sneak Peek

Dan Matthews — Mon, 14 Apr 2008 14:09:10 GMT

The company I work for, Business & Decision, is launching a new brand for their global digital agency function; "Interakting". Apparently "Business & Decision" works better as a brand in their other areas (Business Intelligence, Customer Intelligence and Management Consulting) than it does in E-Business. No shock there then :)

It's not officially launched in the UK yet, but you can get a sneak peek of our branding at our shiny new Interakting UK website.

The site was built in our Interakting office here in Oxford, and is running on EPiServer 5. Any feedback let me know and I'll get them through to the team. You may also recognise the tag cloud - it's CloudCuckoo - and we've put it in a little wrapper to make tagging only available to site editors!

Partner Summit '08

Dan Matthews — Fri, 04 Apr 2008 08:44:31 GMT

My flight is booked and I'm looking forward to the summit! The agenda looks packed and I'm especially interested to see what is put on the developer second day 'stream'. At the moment it's just TBA... although there's plenty of other tasty tidbits on the other days too (like the MOSS/EPiServer slot with Mats Hellström).

I'm flying out on the early doors SAS flight from Heathrow on the 29th. If there's any other UK partners out there on the same flight, give me a shout and maybe we can link up on our way.

VPP Initializer not firing properly

Dan Matthews — Wed, 02 Apr 2008 12:10:43 GMT

Whilst building the CloudCuckoo module, I used a neat trick to register my custom VPP on-the-fly by using an attribute flag to mark it as an EPiServer plugin. This would cause EPiServer to find it and intialise it when I first hit the EPiServer site. This worked fine on my machine and some others, but I was finding that on one specific machine it wasn't firing properly. EPiServer was calling it to initialise it, but the problem was when I tried to access the HttpContext. In a nutshell, for some reason when this machine fired up the plugin to initialise it, it was losing or not passing in the HTTP context. Typically, this would happen if there was a funny AppDomain issue or if something was being recycled, but all the configuration looked fine. The code causing the problem is below:

        1: if (HttpContext.Current == null)

       2: {

       3:     // Running from the scheduler, skip registration

       4:  

       5:     System.Diagnostics.Debug.Write("VppInitializer called without HttpContext. Exiting");

       6:  

       7:     return;

       8:  

       9: }

      10:  

      11: // Register

      12:  

      13: Assembly lateBoundAssembly = System.Reflection.Assembly.LoadFrom(HttpContext.Current.Server.MapPath(@"\bin\BusinessDecision.CloudCuckoo.dll"));

When I ran DebugView I could see that the plugin was bombing out due to no HTTP context and never getting to the registration. After trying for a while to get the HTTP context and failing, I decided to tweak things around. First I changed the way the plugin was detected to using inheritance, as described in this post by Allan Thræn. That worked insofar that it did exactly the same thing - but I preferred to use inheritance so left it in there anyway :) I then decided to eliminate the need for the HTTP context at all. The only reason it was there was to get the path using Server.MapPath, but it occurred to me that given my Single-Assembly-Plugin approach, all I had to do was grab the codebase property of the current assembly! That had the added advantage that I was no longer limiting the DLL to having to reside in the BIN folder. In theory it could now even go in the GAC. The updated code looks like this:

       1: Debug.Write("VppInitializerX Loading CloudCuckoo VPP from: " + typeof(VppInitializerX).Assembly.CodeBase);

       2:  

       3: // now binds without using HttpContext

       4:  

       5: Assembly lateBoundAssembly = System.Reflection.Assembly.LoadFrom(typeof(VppInitializerX).Assembly.CodeBase);

As you can see, this code is much cleaner and, most importantly, it works on that machine that was being problemmatical. This is probably a good thing to bear in mind for any EPiServer plugins called in this way - using HTTP context might be risky.

CloudCuckoo for v5 SP1

Dan Matthews — Wed, 02 Apr 2008 09:55:48 GMT

I've recompiled the CloudCuckoo binary against EPiServer v5 SP1 to save you having to recompile the project yourself. (it was originally built against vanilla v5) Enjoy!

Get CloudCuckoo here

EPiCloud > CloudCuckoo > Released!

Dan Matthews — Tue, 25 Mar 2008 15:53:38 GMT

The EPiCloud module that I've been working on for a while is finally ready for release! Due to the EPiServer preferred module naming policy (no EPi.... please!) we had a few thoughts around the office here and one of my colleagues, Alan Bartlett, came up with CloudCuckoo. The name appealed to me because it was rather different and also has mild amusement value. The best part is this though - I have obtained clearance to release the module for FREE on EPiCode!

The module and sourcecode is available on EPiCode here.

I also finished off the tag moderation part of the plugin, which can be seen on the screenshot below:

There's a few more things that might be nice to add, but for now it's good to get version 1.0 out there and let people start to play with it. If you decide to evaluate/use it and have any feedback at all please let me know.