• The bounds factor – proper use of Enum type guarantee that the selected value will fall within the constraints of the allowed value set.
• The ability to treat Enums as flags (and compound them into flag sets) as well as a one-of selector.
• The ease of use and potentially complete separation of the “Enum value” from the underlying machine type representation that ensures the most efficient memory usage.

Surprisingly enough EPiServer as it stands right now does not have an easy facility to turn Enums into properties. To give credit where credit is due, the EPiServer framework provides a nice surrogate that mimic that behaviour to a degree. The relevant property types are:

• PropertyAppSettingsMultiple  – which “creates check boxes with options that are defined in the AppSettings section in web.config. The name of the property should match the key for the app setting.”
• PropertyAppSettings  – which “creates a drop down list with options that are defined in the AppSettings section in web.config. The name of the property should match the key for the app setting.”

You quickly realize though that the properties have some limitations that makes their use a bit less compelling:

• The properties are not strongly typed
• The property entry in AppSettings section has to have the name that matches the property name on the page.
• It’s rather poorly documented, Other than relating to this blog entry or Erik’s post documenting it I could not find any other examples on how to use them. (but then again, who needs docs really when we have Reflector)
• You cannot have the very same property duplicated on the page since you can only have a single property of a given name per page. So you need to have multiple entries in AppSettings that match the name of each of those properties on your pages. I know… semantics but still…
• You are working on strings rather than enums (Did i mention it’s not type safe?)
• The values in the AppSettings are stored in a somewhat DLS-y manner (consecutive options are separated from each other with the ‘|’ character, the name and the value are separated with a ‘;’, for example: <add key = "RegionId" value="First Option;Option1|Default Option;Option2|Disabled Option;Option3" /> ) and I have had on an occasion entered a string there that caused the server to crash.
• The values are not translatable, or at least I could not find how to do it and any Reflector digging rendered no results either.

The solution to the problem:

The solution that the blog post describes is:

• Type safe
• Supports UI localization
• Easy to use in your custom implementation
• Flexible in allowing you to switch between the Enum being multi-choice or a single choice solution
• fully defined in the code – no need to modify web,config.

All you need to do to create your own custom Enum property is declare it.

using Cognifide.EPiserverControls.EnumDropDown;

[PageDefinitionTypePlugIn(DisplayName = "Sample Enum Property")]
public class SampleProperty : PropertyEnumSelector<MySampleEnum>
{
}

That’s it, really!

Now if you want to customize it; obviously you need to provide the information for the property to work with. But let’s stop for a while and think, where does that information belong?

• The property should worry about the mechanics of editing and the tediousness of persistence of the edited value, it clearly is not the place to specify the link between the Enum type and its human friendly drop down text.
• Web.config is for settings, not for describing content types and definitely not to enforce the property names.
• So where should the metadata around your Enum type be? How about we put it around the Enum type itself?

[Flags]
public enum MySampleEnum
{
  [ValueVisualisation(Name="First Option", LanguageKey="/enum/first")]
  Option1,

  [ValueVisualisation(Name="Default Option", Selected=true, LanguageKey="/enum/second")]
  Option2,

  [ValueVisualisation(Name="Disabled Option", Enabled=false, LanguageKey="/enum/disabled")]
  Option3,

  [ValueVisualisation(Name="Hidden Option", Hide=true, LanguageKey="/enum/hidden")]
  Option4,

  [ValueVisualisation(Name="Fifth Option", LanguageKey="/enum/fifth")]
  Option5,

}

What does all that do?

The property using an Enum described this way will look the following way in EPiServer:

Let’s get into the what’s happened here as there’s more than catches the eye.

As you can see the enum values are named like they are in the attributes describing them, Default option is selected just like you could have expected by looking at the Selected=true in its attribute. The Enabled=false in the Disabled option results in an option that cannot be changed. The unchangeable option can be both unselected or selected by default. You may want to disable some deprecated options but still show them in the UI as a legacy but for some reason you might not want users to be able to change their value. Option4 is clearly missing, which is intended and specified by the Hide=true, as you might want to hide options that have been removed form the UI and on the same time you don’t want to loose compatibility with a legacy API that uses the option.

Also There is one thing about the first option on the list – it’s translated! The mechanism to specify the translation is based on the standard EPiServer localization files that you can find in the “lang” folder in your typical EPiServer installation. The Translation for the property looks like the following

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<languages>
  <language name="English" id="en">
    <enum>
      <first>First Option Translated EN</first>
    </enum>
  </language>    
</languages>

so you see the value will take its translation key from the LanguageKey="/enum/first".

Ok, so we have the PropertyAppSettingsMultiple replacement, but what about PropertyAppSettings?

So here I reach the place where I am not 100% certain whether I took the proper path but I am sure I will hear about it if I didn’t :) The place where the property determines if it’s supposed to allow for multi selection or not is whether the Enum is marked with the [Flags] attribute. Obviously Flags mean that the property is a form of a bit flag and should be able to allow the user to flip the bits independently rather than being the “one-of” type. So once you remove the [Flags] form your enum you’re going to see it rendered the following way:

But hey, it’s not a one way trip, if you decide that you want the enum rendered in another type of property and force the opposite behaviour you can always override it in the derived property like follows:

    [PageDefinitionTypePlugIn(DisplayName = "Sample Enum Property Checklist")]
    public class SamplePropertyChecklist : PropertyEnumSelector<MySampleEnum>
    {
        static SamplePropertyChecklist()
        {
            MultiSelectEnum = true;
        }
    }

so even if you think my usage of [Flags] is faulty, the damage can be undone :)

Ok, but what about the enums that we have no control over – like enums form libraries. Obviously cannot retrofit attributes into them. Well, true but we still can have all of the control over the property.

Let’s assume for a moment that this is our legacy enum:

public enum MySampleLegacyEnum
{
  Option1,
  Option2,
  Option3,
  Option4,
  Option5,
}

You can just do nothing and simply use it in the property but the UI will display the not so nice Option1… names. That can be easily fixed – Again, specifying translation is the easiest way of achieving that goal. An xml for that enum would look like follows:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<languages>
  <language name="English" id="en">
    <MySampleLegacyEnum>
      <Option1>First Option</Option1>
      <Option2>Default Option</Option2>
      <Option3>Disabled Option</Option3>
      <Option4>Hidden Option</Option4>
      <Option5>Fifth Option</Option5>
    </MySampleLegacyEnum>
  </language>  
</languages>

The default values can be added by retrofitting the “DefaultValues” list with the elements that you want selected in the scenario where the property is first displayed for editing. You can also modify the inherited AvailableItems list to set the rest of the properties otherwise adjustable by the attributes.

Following is a sample of such retrofitted rules to match our original attribute-defined-enum.

[PageDefinitionTypePlugIn(DisplayName = "Sample Legacy Enum Property")]
public class SampleProperty : PropertyEnumSelector<MySampleLegacyEnum>
{
    static SampleProperty()
    {
        MultiSelectEnum = true;

        // Make Option2 a default selected value
        DefaultValues.Add(MySampleLegacyEnum.Option2.ToString());
        AvailableItems.Where(p => p.Value == MySampleLegacyEnum.Option2.ToString()).First().Selected = true;

        //Disable selection of Option3
        AvailableItems.Where(p => p.Value == MySampleLegacyEnum.Option3.ToString()).First().Enabled = false;

        //Remove hidden Option4
        AvailableItems.RemoveAll(p => p.Value == MySampleLegacyEnum.Option4.ToString());
    }
}

The [code for the EnumProperty] as well as [the compiled binaries] are available as Open Source and you can incorporate it in your projects as long as the Cognifide namespace is used for the code.

What do you think? Is that going to be useful for you?

Also there are other limitations like time to wait for the server to timeout and time between clicks, which I am not sure the tool allowed them to adjust. Talking to them I recalled a tool for grabbing website thumbnails long time ago. one way for them would be to to make a batch file with it. The tool would grab the sites’ thumbnail and stress it, but they would still have to setup a number of clients. Also it creates and tears down an instance of IE every time, making it’s not optimal for that task.

So a couple of evenings later (and a few back-s and forth-s during the testing sessions) out comes SoakIE:

The app uses pretty much the same trick as the tool for grabbing website thumbnails but it does so in a nice UI and allows for some rudimentary settings for profiling the traffic:

You can select the number of IE instances that will do the clicking, you can select a minimum time between clicks – that is how often any IE instance can click (if it already finished with the previous request). this allows you to simulate clients that will stay a minute on your site and only click after they’ve read the page. Additionally if your application can on an occasion encounter a deadlock or a hang, it allows you to specify the maximum time to live of each request. If the request takes longer than the specified time, the application will “Stop” the request.

One thing that we’ve noticed though is that after a long time of soak tests the IE instances get mighty fat and start to slow down dramatically. Therefore I’ve added a maximum number of clicks an IE instance can perform after which the client will no longer recycle it for more click but will tear it down and create a new IE instance to continue testing.

Naturally the application needs to know what to test. This is specified in the “Test setup" tab in the “URLs to stress:" text box. The URLs will be picked in a round-robin fashion. The first browser will get the first url, the next one will get the second and so on, if the list will get exhausted the browsers will get fed it from beginning. You can theoretically put them in the box with some other text (like pasting it from a Skype window without stripping the message decoration around them) – SoakIE should be smart enough to parse the text and get the URLs out of it.

You can download SoakIE here

Well I have… and I’m sure I will. And so did Fredrikj on the our #epicode IRC channel ;).

Basically I had the tool that would convert from one language to another, but Fredrikj requested something that would switch master language of a page from one to another. Since I’ve already had some of the work done, I’ve updated the stored procedure I’ve written some time ago and slapped a nice GUI up on it. Here’s the result:

What the tool allows you to do is perform either language conversion or master branch switching on a selected page and all of its children (if you choose so).

The stored procedure have been updated to work on CMS5 R2 (will no longer work on R1 – but if you need that functionality, comment here or give me a shout and I’ll create a compatible version for you).

A word of caution though – I take no guarantee whatsoever about its operation. Especially, if you wreck your client’s database with it. I did what I could to prevent some of the obvious problems (like switching to a non existing master or converting to an existing one) but I will not be responsible if it won’t work for you. make a database backup and experiment there before you do any changes on the real data. That said – it works for me, so I think it should also work for you.

You can download the archive containing the tool here. unzip it to your EPiServer web application folder keeping the folder structure or the plugin reference will be wrong. Include the *.aspx and the *.cs files in your project and apply the SQL file to your database (The manipulation is performed by a stored procedure located in the file).

Also if you’re performing the change in a load balanced environment, you may need to restart the other servers once you do the changes. I reset the DataFactory cache, but I am not sure it propagates through to other servers.

Well, not really. By default the framework will be run in the “legacy mode”. Thanks to an old article by our own Marek Blotny, I’ve learned how to build Plugin settings which are just perfect for the purpose!

So to configure and enable the new features you need to open your admin UI and in the “Config” click on the “Plugin Manager” item and select our framework plugin as shown in the picture

The available options are:

Setting Name	Meaning	Sample
Default WebParts Path Pattern	The pattern to be used when no pattern is defined for a page.	%inherit%
WebParts Path Patterns	The semicolon separated pairs of pattern;pattern name; This is the part you will want to customize most.	%template%|%pageid%%legacyregion%;Legacy regionalized;%template%|%pageid%;Legacy globalized;page|%pageid%|%region%;Page/region;pagetype|%pagetypeid%;Page Type
Cache WebParts in Memory	Determines whether the WebParts are to be cached  between usages (this is useful for a small set of WebParts (like a number of sidebars) but rather discouraged if you use the legacy mode as there can be a lot of those in such case.	unchecked by default (check to improve performance in sidebar mode)
Legacy WebParts Support (per-page only)	If checked, disables the extensions described by this blog.	checked by default (uncheck to enable the sidebar extensions)

As shown here:

Once you fill in the settings as they are suggested in the above table the context menu (or adjust to your needs) will show you the new options:

The new sub menu will allow you to change the pattern by which the WebParts are selected, while “Edit Web Parts” option will enable you to edit the WebParts for the current effective WebPart set.

First of all – if you want to select a pattern on a page you need a means of storing it. At this moment The framework does it in a property. Which means – for every page type that wants to redefine the web parts rather than using the default pattern (in our case %inherited%) you need to add String property with a “WebPartsPath” name (I may actually add some routines to add the property definition automatically if there will be enough demand for that).

What does “Effective WebPart Set” mean?

Assuming (which is the most interesting scenario) that %inherit% is the default pattern the following is true:

Once you select the effective web parts for the page or just agree with the WebParts pre-selected for you based on the default path you can edit them just like previously. Mind that when you edit WebParts on a page all the pages that have the same “effective path” are going to change as well. (which was our intention in the first place).

The library extension is going to be posted on Epicode as soon as I get a hold of Steve to approve the changes :)

Hmm…

Is sidebar a part of content? No, rather not. We don’t want the editors to have to setup the sidebar for every article they write (and the site has a few dozens of articles created on it every day).

Is sidebar more of a template thing? Well… more like it, but still… we have articles all over the site with different sidebar elements when the articles are in different parts of the site (ok so we could add rules what controls display in which part of the site). But wait! There’s more! The sidebar will be different for every language (region). Now we’re talking a dozen of templates or a rules engine just to make the sidebar different. Customising the template with properties isn’t ideal either as it makes EPiServer UI very cluttered. Additionally we want to change sidebars across many templates so the whole branch/section of the site will be able to share the same sidebar.

To a degree this is an academic discussion as we’ve been through it with the previous version of the site and we already knew that integrating this stuff into templates just won’t work and we will be in a world of pain just changing the templates over and over adding little tweaks and changes while the customer ads promotions and performs ad campaigns. Well, we can do it, of course, but it’s not a work a programmer will enjoy, and we all want to do new and more exciting things, don’t we?

We have an internally developed  module to make something like that, that is fully home-grown by another internal team (we now have 3 “squads” capable or making incredible things with EPiServer and we tend to share a lot of technologies and try to rotate people around to adopt the good habits and experiences) and I was (and still am) VERY impressed by it. The technology uses EPiServer pages for defining every module (which are located somewhere outside the site root branch. and then you can mix and match them either declaratively in the code) or by handpicking them in the UI. It’s really cool, though, during the discussions it turned out that we might have to add big chunks of functionality and might end up with separate branches of module-pages for different languages/regions, but… frankly… about that time an article by Ted Nyberg reminded me about a technology I have read about quite a while ago in an article by Stein-Viggo Grenersen and ooohhhhhh… I got seduced. I really wanted to try if for a long time and Ted’s article made it a snap to try and get convinced, and more important… convince Stu ;) that it’s the right way to explore.

So I started to dig.

Talked with Steve (the original creator of the Framework) a bit and learned that I can “customize a path rewriter” to suit my needs. Great! I just hoped I won’t have to deal with some nasty GUID’s matching, but no! Turns out, all it takes to identify a WebPart set is to have any unique string naming it.

So basically what we needed was a manager to deal with the naming templates and a way to determine the WebParts set to be used per page.

Till now the framework used template file name followed by the page ID, followed by an eventual language/region if a page was not the master branch, for example:

~/templates/Demo/WebPartPage.aspx|26
~/templates/Demo/WebPartPage.aspx|26|en-us

which makes them unique per page, which is not as appealing when you use EPiServer as it for a big part duplicates its functionality. Also a bit of a caveat here for agile programming methodology which promotes an often and early refactoring – if you move your page around or change its name – you lose the WebParts for all pages using it.

What we needed is a flexible and extensible scheme for reusing “WebParts sets” and that’s what our extension allows for.

Also since we’re very performance sensitive, and we operate in a multi server scenarios a lot we’ve added web parts blobs caching. Meaning that the site does not have to reach to the database every time a page is rendered.

The very appealing side of the framework is that it can be extended form the bottom (persistence) from the top (editors, controls, webparts), as well as being pluggable with custom plumbing.

The Sidebar Extensions for WebParts Framework

So to put all the requirements together, we needed the sidebars to be:

• customizable (out of the box)
• easy to use for both developers and editors (out of the box) Wow Steve, I can’t really appreciate enough how cool it is to code for it and how nice it is for the users!
• localizable
• reusable
• inheritable for site branches

WebParts path patterns

The main idea was to free the path names from the restriction they had – being hardcoded for a page. So to do it without hard-coding them I’ve introduced path patterns.

What is a pattern?

Basically a pattern is a way the framework is supposed to encode the WebParts  id for the system to identify. Your site can have any number of “named patterns” and the framework gives you means of switching between them. Pattern allow for almost any string to be a part of it although some tokens have special meaning:

Some sample patterns

The configuration of the module is a descendant of any EPiServer Virtual Path Provider configuration. This aspect is fairly well described on EPiServer pages.

A sample configuration for the TextImageVirtualPathProvider can look as follows

<configuration>
  <episerver>
    <virtualPath
      <providers>
        <add showInFileManager="false"
             virtualName="Text Images"
             virtualPath="~/TextImages/"
             bypassAccessCheck="false"
             name="TextImages"
             type="Cognifide.ImageVirtualPathProvider.TextImageVirtualPathProvider,Cognifide.ImageVirtualPathProvider"
             physicalPath="C:\temp\TextImages"
             allowedReferers="(localhost)"
             allowNullReferrer="false"
             replacementStrings="$colon$,:,$gt$,>,$dot$,.,$quot$,&quot;,$amp$,&amp;,$star$,*,$eol$,&#10;,"/>
      </providers>
    </virtualPath>
  </episerver>
</configuration>

where:

• physicalPath is where the cached version of images will be stored
• shownInFileManager is “false” as there is nothing to present for the user in the file manager.
• allowedReferrers is the regular expression containing the filter for sites that are allowed to access the path provider and get images. This has been added so that your server does not turn into the internet’s text-image open service :)
• allowNullReferrer should be set to false in production environment but allows for testing by directly creating URL’s without using a page to fill in the referrer.
• replacementStrings – this one actually turned out to be very useful since some characters are invalid and not even reaching the VPP if EPiServer or ASP detects them. so to allow for characters like colon or < or even a dot (which would make it hard to form regular expression if it was explicitly available) or * you need to create an escape token for them. The string is a coma separated list of token,value,token,value,…
• virtualPath is something you need to change if you want your VPP to serve images under a different root level folder. (e.g. if you have a page with that name already)

Additionally for IIS6 (most common scenario) you need to add <location> node to configuration for the VPP to work.

<configuration>
  <location path=“TextImages“>
    <system.web>
      <!– Setup the StaticFileHandler for the wildcard mapping to work in IIS6–>
      <httpHandlers>
        <add path=“*“ verb=“GET,HEAD“ type=“System.Web.StaticFileHandler“ validate=“true“ />
      </httpHandlers>
    </system.web>
    <staticFile expirationTime=“-1.0:0:0“ />
  </location>
</configuration>

Unless you want to change the location of the virtual path provider can be found under, there is nothing you need to change here.

The code is accessible on EPiCode, but you can also download a compiled binary here. All you need to do then is to unzip the archive to the “bin” folder within your site and set the web.config values to your preference.

One of the first projects (that I took part in) is CogniScale – an app that allows FlexiScale users to manage their servers. Here’s the story…

Being the agile company taking part in many EPiServer projects we never seem to have enough environments to test our web-apps and software in general in various scenarios. We find ourselves constantly reinstalling and trying to keep our servers in a state that can can at least remotely be called as stable. After all how many deployments and tearing down of various EPiServer, CruiseControl, TeamCity, SQL Server and other "I need to have" apps can a server take before slowing down to a crawl or collapsing all together (that said I bow before our faithful THOTH for taking all the abuse it does). We definitely needed more servers! And we needed them now!

Early this year we’ve started to talk to the guys at XCalibre that came up with a great idea. What if you could have an unlimited amount of servers available for you at any given time? I mean really what if you could have 0 servers one day and the next day have a rich farm of servers for literally no cost, paying only when you power them up and not paying a bit if you take them down.  This turned out to be quite a project for them that turned to materialize as FlexiScale. (you can read more about it here). Looking at all that I’ve mentioned before while eliminating the cost of maintaining the servers locally we decided to give FlexiScale a spin.

Early this year FlexiScale published a set of API’s that we looked at and (being the geeks we are) tried to utilize it in a desktop application with a limited success. It turned out that the initial API was perfectly accessible from dynamically typed languages while statically typed languages like C# didn’t really get their love in the initial release :) So we started opening the support tickets and shortly after that establishing a lively dialogue with the great folks there. Let me tell you, the guys in the FlexiScale support are really an amazing and responsive bunch. Not only did we get the support and the fixes we needed for the language we chose but we also pretty much got all our suggestions implemented and added to the API’s.

Thus CogniScale was born:

The app allows for easy powering up and down the servers (allowing you to describe the reason for the action) from a nice and shiny GUI as well as scheduling it with windows task scheduler through its command line interface. it allows you to connect using FTP or Remote Desktop as well as any other app you can run from command line (it features a custom command editor that allows you to configure any app to work with it) with a single click. The app also allows you to quickly go through the history of servers’ maintenance to determine how often and for what reason were they taken on and off-line.

Should you decide that FlexiScale is your thing, please give CogniScale a whirl and let us know what you think.

Download the control form here. Extract the contents of the zip file to a folder and attach the project to your solution, make sure you have the proper EPiServer libraries referenced form the project or it may complain about the references being broken.

Once you have it compiling, copy the GoogleMapEditor.ascx, GoogleMapViewer.ascx and the contents of the resources folder to a folder named GoogleMap within your project folder. Also copy the contents of the lang folder to the lang folder of your site.

The controls the property instantiate try to be smart about resolving the location of its files, but the property does not know its location thus if you decide to place the scripts in a folder other than just GoogleMaps in the app main folder, you need to add to your web.config the following:

<add key="CogGoogleMapControlLocation" value="\GoogleMaps\" />

And in web.config you define the API keys for all the addresses the control will be available from as “CogGoogleMapApiKey_%HOSTNAME%” values.

e.g. set for my machine localhost (for me) & dune(for access from other computers within our network):

<add key="CogGoogleMapApiKey_localhost" value="A value generated for 'localhost'" />
<add key="CogGoogleMapApiKey_dune" value="A value generated for 'dune'" />

The controls determine by themselves which key to use based on the http request so that the Google API does not complain about the key being improper.

Other than this the control should be self registering and all you need to do is to add it to your Page Type in the Admin section of the site and add:

<EPiServer:Property ID="GoogleMapData" runat="server" PropertyName="GoogleMapData" />

to the template you want to use it with.

The control really needs an improved support for translation the stuff currently there is used for learning more that than to actually be useful. Should we decide to go further with it, it definitely will be extended.

The scripts used for the DOPE editing are released under GPL (the scripts were originally released with the MediaWiki GoogleMaps editor under the same license). Those scripts although modified slightly are also released under GPL and are NOT a part of the control – they just happen to be used by it. I am still trying to decide what license use with the rest of the control, so be aware that this is still a subject to be changed, for now just feel free to use the code and should you make any changes to it, please feed them back so that I can improve the control further. The control will most probably end up as a part of Epicode, as soon as I get a response on the epicode forums from Steve on how to add them.

I am in the process of figuring out how I can contribute it through the Community EpiCode effort on CodeResort. As soon as I get some answers from Steve, I’ll get it uploaded there. In the mean time let me document how to start using it.

For the time being you can get the code here or the compiled library with the intellisense help form here.

Posting comments

the posting is somewhat manual in terms of not having a pre-made control for it. Which if you look at the code does not have much sense to have.

All you need to do is put two edit boxes on a page and a submit button, and then bind the action of the submit button to a code looking somewhat like:

protected void SubmitComment(object sender, System.EventArgs e)
{
    IPageComment newComment =
        PageCommentFactory.createInstance(Guid.Empty,
        string.Format("CommentForPage{0}", CurrentPage.PageLink.ID),
        CurrentPage.PageLink.ID,
        SubjectTextBox.Text, ContentTextBox.Text, DateTime.Now, false, true, false);
    newComment.Save();
}

I honestly don’t feel like making a custom control for creating those would be worthwhile since no one would end up using it anyway.

The listing of comments however…

The comments can be accessed in a number of ways.

Probably the easiest one would be by using the templated control I’ve written in the library, which is a simple descendant of the ASP.NET repeater. The page could would look something like:

...

<%@ Register TagPrefix="CognifideControls"
    Namespace="Cognifide.EPiServerControls.PageComments.Controls"
    Assembly="Cognifide.EPiServerControls.PageComments" %>

...

<CognifideControls:PageCommentsList ID="CommentControl" runat="server"
    PageLinkIdProperty="<%# CurrentPage.PageLink.ID %>">
    <ItemTemplate>
        <b><%# CommentControl.CurrentComment.Title %></b> -
        <%# CommentControl.CurrentComment.SubmitDate.ToString() %><br />
        <%# CommentControl.CurrentComment.Content%><br /><br />
    </ItemTemplate>
</CognifideControls:PageCommentsList>

I’ve chose this way since that’s pretty much the standard way of adding controls that are defined in Episerver and just generally ASP.Net.

But nothing stops you from accessing the comments directly,  and then filling in the data for the repeater yourself like:

<asp:Repeater ID="CurrentComments" runat="server"
    OnItemDataBound="CurrentComments_ItemDataBound">
    <ItemTemplate>
        <b><asp:Label ID="CommentSubjectLabel" runat="server"></asp:Label></b><br />
        <asp:Label ID="CommentContentLabel" runat="server"></asp:Label><br /><br />
    </ItemTemplate>
</asp:Repeater>

And then in the code-behind

protected void Page_Load(object sender, EventArgs e)
{
    List<IPageComment> comments =
        PageCommentFactory.GetCommentsForPage(CurrentPage.PageLink.ID,
        DateTime.MinValue, DateTime.MaxValue, true);
    CurrentComments.DataSource = comments;
    CurrentComments.DataBind();
}

protected void CurrentComments_ItemDataBound(object sender, RepeaterItemEventArgs e)
{
    IPageComment comment = (e.Item.DataItem as IPageComment);
    Label commentSubjectLabel = (Label)e.Item.FindControl("CommentSubjectLabel");
    if (comment != null)
    {
        commentSubjectLabel.Text = comment.Title;
    }

    Label commentContentLabel = (Label)e.Item.FindControl("CommentContentLabel");
    if (comment != null)
    {
        commentContentLabel.Text = comment.Content;
    }
}

That’s pretty much what my implementation does anyway.

I hope to be able to put it up on CodeResort soon so that we can see what else could be done. Additionally my library allows for replacing the persistence provider, which we will probably have implemented using nHibernate to test its speed versus the ObjectStore. Should you be interested in providing some help with this, or adding come moderation code to the admin side of the site on top of the interface, it would definitely be greatly appreciated.

I have started implementing the Property based on the code so that it can be easily displayed on the editor’s page, but for now, I’ll have to delay it since we’ve got some other stuff to do related to the project I’m currently working on.

Introduction

It’s a real joy to work in a international company, the problem we face are hardly ever matched by some locally based endeavours…

As some of our friends here at work, you may choose to reveal your current location to your skype buddies. This is nice and easy since you can just put it in your name or description and everyone will see where you are.This poses a problem should you really travel frequently, it is more likely than not, that your location tag will be out of sync.

As this is a something that happens for them once in a while I found it an interesting concept, fun enough to be worth solving it :)

So how does one establish his location? Short of installing a GPS on your machine, I would suggest checking your IP address and translating it based on one of the available databases.

The thought process goes as follows… [Read about the technical guts of the application in my article at Code Project]

The Convergence – The Application

The application helps you maintain your location tag in your name so that whenever you travel to a different town your skype name/description will reflect it.

Disclaimer: The application uses GeoIPTool as its source of IP and geo-location. Visit GeoIPTool for a wide variety of web based geo-location tools.

It does not contain either any kind of tracking abilities other than it letting you to maintain your location tag. The application will not even change your location tag by itself but rather it will notify you that your location has changed and will allow you to change your tag with a simple press of a button.

Usage
In your skype account set your name or description so that it has [] in it or press “Add location tab to…” in the application. Whenever the application will find those it will check if the text in the parenthesis matches your current location., if it does not it will suggest a new one and will highlight the relevant field red. You may set for this operation to be performed on every boot, you will however only be notified when/if your location actually changed.