SwedeGarden is aimed at swedes going to CodeGarden, but all attendees are of course welcome to join in.

You can read more over at SwedeGarden.

Please note, that this is a social event, no 'puters allowed. Leave your geeky stuff at the hotel, and just bring your geeky self. We'll have a few beers, network, and be merry. Also note, that SwedeGarden is in no way affiliated with Umbraco or CodeGarden.

See you there!

In EPiServer, we get all PageData objects from the DataFactory, since EPiServer implements a factory pattern. It's also implemented as a singleton, making it very simple to interact with. We get the page by passing a PageReference to the factory, getting the page we want. By default the DataFactory returns the currently published version of a page. In Umbraco, we instead call the constructor on the Document object, by passing it an ID of the page we want. A big difference here is that the Document API by default returns the latest version of that page, regardless if it's published or not, if a certain version is required, specify it by passing the version Guid.

Another difference between the PageData and Document objects, is caching. The PageData object you get from the DataFactory is always cached (except when getting pages with FindPagesWithCriteria, but more on that in another post), whereas the Document object is never cached. For this reason, we only work with the Document API when we want to programatically change data. For a cached page in Umbraco, we use the Node API.

In EPiServer, the PageData object is read-only, when we want to change a page, we call CreateWritableClone() on the PageData object, getting a writeable copy of our object, that we can change all we want. When we're done, we pass it back to the DataFactory for saving and/or publishing. In Umbraco, this is not as straight-forward. The Document is always open for changes, and changing a property will persist that change to the database immediately. Properties for an EPiServer PageData object is accessed throught its index property, by property name, like MyPageData["MyProperty"]. Getting a property on the Document object is done with a call to MyDocument.getProperties("MyProperty"), however, this performs a call to the database as soon as you access the Property.Value property. What this essentially means, is that each proeprty is saved as soon as you set its value, calling Document.Save() fires the BeforeSave and AfterSave events, updates the UpdateDate property, and the preview XML. This is important to know. Calling Document.Publish() performs different task related to publishing, but it doesn't push your data to the content cache, for this you need to call umbraco.library.UpdateDocumentCache(int) passing it the ID of the Document. This also ensures that any other servers, if your site uses load balancing, also performs the cache update.

There are a number of methods to get cached content in Umbraco, the old-school way is to use the Node API, most commonly used via XSLT in Macros, but it's also available from code. Another way is to use Linq2Umbraco, that gets cached, typed, instances of your content. It has excellent performance, and if you're more comfortable with using C#/VB for your coding, this is probably the way for you. As I write there is also support for using Razor in Umbraco, and I dare say that it may make XSLT in Umbraco obsolete. It's the new black, and it's friggin' awesome :)

There's a great set of wiki-articles called The Umbraco API Cheat-sheet. Amongst others, it clearly describes the difference between a Node and a Document.

As usual, all and any comments, suggestions and additions are more than welcome.

The default sections of Umbraco are Content, Media, Users, Members, Settings, and Developer. When you first log in to Umbraco, what you see is normally the "Content" "section", this roughly translates to the EPiServer CMS Edit-mode, and it features the functionality needed to edit, save, publish and work with permissions for content. WHen you have a clean install of Umbraco, there won't be anything here, since, just as in EPiServer, you need DocumentTypes (PageTypes) in order to have Documents (Pages).

The Media section is an ordered structure for Media, i.e. files and folders, that can be used , and re-used, from Documents. It's the equivalent of the file browser in EPiServer, although, not implemented in the same way.

The Users section is where Users for the Umbraco UI are managed, and their respective access rights.

The Members section is where Users for the website are managed. In Umbraco, this is the MembershipProvider that you configure. The Members section is used to manage Members, and it can be used to edit both the User, called a Member, and the Profile for that User.

The Settings section is where you edit the base for your website, such as Document Types, Media Types, Languages and Globalization and Templates. It can also be used to manage Stylesheets and Scripts for your website.

The Developer section is used to manage the most technical parts of the website, such as Data Types and Macros.

The rationale behind the decision to divide the building blocks for your site in Settings and Developer, can be discussed, in fact I can imagine it has been on several occasions. One could argue that Macros are on par with Templates in technicality, but I suppose there had to be a line drawn somewhere, and here it is.

There is also a dashboard, that roughly corresponds to the EPiServer OnlineCenter Dashboard, where you can load custom controls and functionality for each section, however, it doesn't have the same granular security features that EPiServer has, nor does it rely or ASP.NET MVC to build these "gadgets", they are simple (or, in some cases, not so simple) UserControls, but they can be used for really powerful stuff. Your imagination sets the limits here.

To sum it all up, coming from EPiServer, the Content- and Media sections corresponds to the EPiServer CMS Edit-mode, and Users, Members, Settings and Developer correspond to the Admin-mode. Also note, that some tasks that are handled in EPiServer configuration, are done from the UI in Umbraco, and vice-versa. I'll try to amek sure to point these out as I get there.

In my experience Umbraco is seen as a competent OSS alternative to EPiServer. In my opinion, EPiServer is a very competent product, although, the license costs often excludes it from consideration by many organizations. Umbraco, too, is very competent. They employ similar patterns for some of their functionality, and completely different approaches for some.

I've planned the disposition for the series according to the list below, but it may change as I write. I'll update this post as the series progresses.

Part 1. The administration user interfaces.

Part 2. Document vs. PageData

Part 3. DocumentType vs. PageType

Part 4. DataType vs. PropertyType

Part 5. Property vs. PropertyData

Part 6. Media vs. the VPP

Part 7. Members vs. Users

Part 8. Event hooking

Part 9. Scheduled tasks

Part 10. Building a Custom DataType, vs. Building a Custom PropertyType

Part 11. Extending and customizing the UI.

Part 12. Template vs. PageTemplate

Part 13. Macros vs. DynamicContent

Part 14. Macros (XSLT/Razor/UserControl/Python) vs. WebControls/UserControls

Part 15. Searching with Examine vs. FindPagesWithCriteria

I have been working with both platforms for many years, and I think both offer excellent performance and functionality. However, regardless of that experience, I may have gotten some things wrong, and I hereby invite anyone to correct me, add information, or otherwise express their opinions.

• The base object for Umbraco content is CMSNode, it is constructed with an ID, and that goes to the database.
• Content is derived from CMSNode
• The Content.getProperty methods goes round-trip to the database. All derivatives of the Content class (e.g. Document, Media, Member),and thus behave the same way.
• Members. The Member object itself can be cached, but getting property values is just the same as for any Content.
• Media is also a derivative of Content. (As Jeroen Breuer mentioned in his comment, when working with Media in XSLT (via the umbraco.library.GetMedia method), the returned XPathNodeIterator is cached).
• Document is Content. But it can be published, and thus pushed to the Node API, which is cached.
• Templates. Programmatic access to the templates always result in a round trip to the database.
• ContentType.GetByAlias and GetAll goes to the database, getting it by ID via ContentType.GetContentType is cached.
• PropertyType.GetPropertyType is cached, but all other ways of instantiation goes to the database.

I'll edit this list as needed, I haven't worked wnough with 4.6.1 to know what's changed, so this applies to 4.5.2, at least.

As Jeroen Breuer accurately pointed out, there's a big difference between a Node and a Document

Before EPiServer CMS 5 R2, whenever you wanted to have a property with multiple links, you used the MultiPage property by Intergen. It was excellent, it still is, that's why EPiServer chose to include it in the product, but I like to keep EPiServer standard properties as much as possible. Then main reason for this is upgradeability, and I like to do minimal amount of work to keep my clients happy. It costs less for them, and I get to spend more time doing stuff that I find interesting.

I ran into this issue when upgrading a EPiServer CMS 5 site to EPiServer CMS 6, mainly because the MultiPage property looks like crap in EPiServer CMS 6. I found out, using the EPiServer World Forums, and after checking myself, that both property types use the same data structure for their data. This is great. But as always there's a snag.

If you simply switch the property type in the Admin UI, all stored data is wiped. I don't know why, but I can imagine it is to ensure data integrity, so that you can't mess the property data up by accident.

I chose to get at the problem using a bit of T-SQL. I'm no DBA, so someone can probably write to code shorter, faster and prettier. But in most scenarios this is quickly run anyway.

As usual, make backups BEFORE, and I give no warranty. The code is provided as-is.

BEGIN TRANSACTION MultiPageToLinkCollection;
SET NOCOUNT ON;
DECLARE @linkcol int;
DECLARE @linkcolcount int;
DECLARE @multipage int;
DECLARE @multipagecount int;
SET @linkcol = (SELECT TOP 1 [pkID] FROM [tblPageDefinitionType] WHERE Name = 'LinkCollection');
SET @multipage = (SELECT TOP 1 [pkID] FROM [tblPageDefinitionType] WHERE Name = 'MultiPage');
IF @linkcol <> ''
BEGIN
    SET @linkcolcount = (SELECT COUNT(1) FROM [tblPageDefinition] WHERE [fkPageDefinitionTypeID] = @linkcol);
    SET @multipagecount = (SELECT COUNT(1) FROM [tblPageDefinition] WHERE [fkPageDefinitionTypeID] = @multipage);
    IF (@multipagecount > 0)
        BEGIN
        PRINT 'Beginning upgrade...';
        PRINT 'Properties using LinkCollection: ' + CAST(@linkcolcount AS varchar(5));
        PRINT 'Properties using MultiPage: ' + CAST(@multipagecount AS varchar(5));
        UPDATE [tblPageDefinition] SET [fkPageDefinitionTypeID] = @linkcol WHERE [fkPageDefinitionTypeID] = @multipage;
        SET @linkcolcount = (SELECT COUNT(1) FROM [tblPageDefinition] WHERE [fkPageDefinitionTypeID] = @linkcol);
        SET @multipagecount = (SELECT COUNT(1) FROM [tblPageDefinition] WHERE [fkPageDefinitionTypeID] = @multipage);
        PRINT 'Finished.';
        PRINT 'Properties using LinkCollection: ' + CAST(@linkcolcount AS varchar(5));
        PRINT 'Properties using MultiPage: ' + CAST(@multipagecount AS varchar(5));
        END
    ELSE
        BEGIN
        PRINT 'No properties using MultiPage were found.';
        END
END
ELSE
BEGIN
    PRINT 'Unable to find LinkCollection property type. Please make sure your database is for EPiServer CMS 5 R2 (5.2.375.7)';
END
COMMIT TRANSACTION MultiPageToLinkCollection;

Edit: Obviously, you'll need to look in your code and make sure it doesn't do anything funky to get the data from the property. The code in my project did, and it was awful.

Heavily inspired (and with some borrowing), I've converted the PageTreeIcons project to a collection of attributes that you can use to alter the icons for page types and properties. It's still an early draft, but it works.

This way, it's really easy to keep track of the icons for your properties, and there's no need to keep an extra section in your web.config. Some features have been removed, since EPiServer CMS 6 already contains some of the functionality (i.e the PageLinkTypeHandler).

It's applied like this, on page types

[PageTypeIcon("~/UI/Images/PageTreeIcons/page.png", typeof(ContentPage))]
[PageType(AvailablePageTypes = new[] { typeof(ContentPage) },
   Filename = "~/UI/Pages/ContentPage.aspx",
   SortOrder = 20,
   Name = "[Public] ContentPage",
   DefaultSortIndex = 100,
   Description = "An ordinary content page.")]
public class ContentPage : PageTypeBuilder.TypedPageData { ... }

and like this, on a property

[PropertyEmptyIcon("~/UI/Images/PageTreeIcons/warning.png", 
   "/pagetreeicons/property/missingkeywords", 
   "MetaKeywords", 
   new [] { typeof(BaseModule), typeof(ModuleContainer), typeof(Contact) })]
[PageTypeProperty(EditCaption = "Keywords",
   HelpText = "A comma-separated string containing keywords used for this page.",
   Searchable = true,
   UniqueValuePerLanguage = true,
   Type = typeof(PropertyString),
   SortOrder = 10)]
public virtual string MetaKeywords {
   get;
   set;
}

Again, kudos to Henrik Nyström, http://thisisnothing.wordpress.com/, for writing this in the first place.

Please let me know if you have any comments, improvements, or questions.

Download the code here.

Don't have any icons? Try FamFamFam Silk!

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.ComponentModel.DataAnnotations;
using EPiServer.Core;
using PageTypeBuilder;

namespace Development {

    ///
    /// Specifies the allowed type of pages selected in the property.
    ///
    [AttributeUsage(AttributeTargets.Field | AttributeTargets.Property, AllowMultiple = false)]
    public sealed class AllowedPageTypeAttribute : ValidationAttribute {

        ///
        /// The allowed types of pages.
        ///
        public Type[] AllowedPageTypes {
            get;
            set;
        }

        public AllowedPageTypeAttribute(Type[] allowedPageTypes)
            : base() {
            this.AllowedPageTypes = allowedPageTypes;
        }

        public override bool IsValid(object value) {
            var reference = value as PageReference;
            // Check if the property ReferenceContainer has a value
            if (PageReference.IsNullOrEmpty(reference))
                return true;

            var page = reference.GetPage();
            if (page == null)
                return false;

            var pageType = page.GetType();

            foreach (Type t in AllowedPageTypes) {
                if (pageType.IsAssignableFrom(t) || t.IsAssignableFrom(pageType) )
                    return true;
            }
            return false;
        }
    }
}

And it's simply implemented on the Page property thus:

///
/// Name: Office
/// Description: The office associated with this container.
///
[AllowedPageType(new[] { typeof(OfficePage) }, ErrorMessage = "/errors/OfficePagePageType")]
[PageTypeProperty(
EditCaption = "Office",
HelpText = "The office associated with this container.",
Searchable = false,
UniqueValuePerLanguage = true,
Type = typeof(PropertyPageReference),
SortOrder = 15,
Required=true)]
public virtual PageReference OfficePage {
        get {
                var value = this.GetPropertyValue(page => page.OfficePage);
                return value ?? PageReference.EmptyReference;
            }
        }
}

It's also very easy to do e-mail validation etc. on properties. Like this for example.

[RegularExpression(@"^\b[\w\.-]+@[\w\.-]+\.\w{2,4}\b$", ErrorMessage = "/errors/EmailFormat")]

It's so simple it almost hurts.

I did what I've been telling people not to do. I copied code, and I expected it to work as advertised. Needless to say, it didn't. The general idea was to hook into the UrlSegment.CreatedUrlSegment event, and make sure that the URL was lowercase. It works fine every time you edit a page, and alter the URLSegment property. However, if you go into admin mode, and decide to rebuild all URLs, you're in for a treat. The Rebuilding of URLs doesn't fire the UrlSegment.CreatedUrlSegment event, since it just alters the property on the PageData object, and creates a new version of the page. This circumvents the event model for URLSegements, I'd call it a bug, others might call it a feature, but I leave it up to more intelligent people than me to decide what to do. In the meantime, I've moved my logic to the DataFactory.Instance.SavingPage event, since that is fired every time the page is saved, no matter where you alter the page from. It's in the DataFactory, it's "unfuckwithable".

I copied code, I'm sorry. I will never do it again. Never. At least not without testing the results throughly first :)