Define tabs in code with Page Type Builder 0.8.5

The latest version of Page Type Builder for EPiServer CMS which was just released features a new way of working with tabs plus a few minor fixes and changes.

A new way to work with tabs

In previous versions of PTB you would define which tab a property would reside in by specifying it’s name, like this:

[PageTypeProperty(Tab = "NameOfTab")]
public virtual string MainBody { get; set; }

If no tab name was specified the property would be put on the first tab, usually the one named Information. This is still the case but the way to explicitly specify a tab for a property has now changed from specifying a tab name to specifying a type. The type must inherit from an abstract class in PTB called Tab. It must also be concrete. Both of these requirements are validated at start up.

An example of the new way to specify a tab for a property:

[PageTypeProperty(Tab = typeof(MyTab)]
public virtual string MainBody { get; set; }

Creating tabs

When you inherit from Tab you must implement three properties, Name, RequiredAccessLevel and SortOrder. By doing so you gain the same control over a tab as you get in EPiServers admin mode. An example tab can look like this:

namespace MySite.PageTypes.Tabs
{
    public class MyTab : Tab
    {
        public override string Name
        {
            get { return "MyTab"; }
        }

        public override AccessLevel RequiredAccess
        {
            get { return AccessLevel.Read; }
        }

        public override int SortIndex
        {
            get { return 11; }
        }
    }
}

Note that the key used to identify tabs is the name. This means that you can define the standard tabs, such as Information, Advanced and Categories in code by creating tab classes with the same name. One caveat of this, which follows the same pattern as for page types (unless you specifiy a GUID) and page type properties, is that you can’t rename a tab from code. To do that you should first rename it in admin mode and then in the code.

Other changes

This release also features a fix for a bug in version 0.8 which caused the startup validation of page types to fail if you had a automatic property that wasn’t virtual, even though it didn’t have a PageTypeProperty attribute, in a page type class.

I’ve also renamed the GetTypeForPageType method in PageTypeResolver to GetType and added a new method to the same class, GetPageTypeID. GetPageTypeID takes a type as parameter and returns a nullable int with either the corresponding page type ID as value or null. While nothing in PTB requires this method I found myself needing it recently when I was creating a custom page provider.

Feedback

As usual I greatly value any and all feedback. This time, in preparation for version 0.9, I would especially like feedback about what exceptions those of you who are already using PTB are getting at startup so that I can put in validation for those things and make PTB throw exceptions with more explaining messages.

PS. For updates about new posts, sites I find useful and the occasional rant you can follow me on Twitter. You are also most welcome to subscribe to the RSS-feed.

Comments

  1. Erik Nordin's avatar

    Erik Nordin 1 years ago

    Great work Joel! It's much more fun to work with EPiServer with the PageTypeBuilder! :)

    Seems like there's a bug if you make bool and using the proxy classes. If the bool is empty and you try to access it through stronged type it throws an exception.

    Keep up the good work!

  2. Joel Abrahamsson's avatar

    Joel Abrahamsson 1 years ago

    Thanks Erik!

    Have you tried with nullable bool?

    As EPiServer has two possible states for value types, having value and being null, while a value type normaly can have only one state, that is having value, I'm not sure if this should be considered a bug or not. The only possible fix that I can think of is returning the default value (ie false for bool, 0 for int etc) and I'm not to fond of doing that. I'm leaning towards using nullable types for properties that isn't mandatory for the editor to enter and non-nullable for those that are manadator for the editor.

    What do you think?

Add a comment

Allowed tags: <b>, <em>, <quote cite="">, <code>, <c-sharp-code>, <css-code>, <sql-code>, <xml-code>, <javascript-code>. If you want to display code examples, please remember to write &lt; for < and &gt; for >.

Follow me on Twitter

  1. Bookmarked: Google Scribe http://bit.ly/9iDp8s 2 days ago
  2. Blogged: The future of EPiMVC http://bit.ly/ck6EPg #episerver 2 days ago
  3. At Skånegläntan, as always #parentalleave 2 days ago
follow me

Latest comments

  1. Svante wrote "Yes, I noticed that it was a singleton, and I guess the real..." on Something to beware of when using EPiAbstractions and an IoC container
  2. Joel Abrahamsson wrote "Well, first of all you wont get any arguments from me regard..." on Something to beware of when using EPiAbstractions and an IoC container
  3. Svante wrote "Hmm... Since the issue really is with the public instance co..." on Something to beware of when using EPiAbstractions and an IoC container

About this site

This blog is built with EPiServer Community, EPiServer CMS, ASP.NET MVC and a bunch of other great products. The source code is available for download at the projects page, where you also can read more about this site and my other projects.

read more