Stefan Forsberg
Oct 18, 2010
  5399
(1 votes)

A blog post from the future

Hello Stefan. This is you writing a blog post in DateTime.Now.AddYears(yearsItTakesToCompleteVNext). I just thought I’d let you know how you develop with EpiServer nowadays.

If the development process won’t look like this something horrible has happened with the space/time continuum and you should be worried. Chances are a guy named Biff is involved.

/Future Stefan

 

Model first

There is no PageData. At least not as far as you or your site is concerned. Instead you work with a model that makes sense to your current user stories, whatever they may be. This probably remind you of you used to work with PageTypeBuilder but taken a step further.

Let’s say you have a Person page that should display  a Name, Phone number and mail address of the person. The class that handles this looks like this:

   1: public class Person : IAmAPageType
   2: {
   3:     public string Name { get; set; }
   4:     public string PhoneNumber { get; set; }
   5:     public string EmailAddress { get; set; }
   6: }

Since your class implements the marker interface IAmAPageType EPiServer knows that it specifies a page type and will sync property info as well as data for you.

Usually this isn’t enough though since you often want to specify more information about your properties like help texts etc. EpiServer uses a fluent mapping interface for this.

   1: public class PersonMap : IMapPageType<Person>
   2: {
   3:     public PersonMap()
   4:     {
   5:         Map(x => x.Name)
   6:             .HelpText("Name of the person")
   7:             .AvailablePageTypes(new {typof(SomePage)});
   8:  
   9:         Map(x => ...)
  10:     }
  11: }

 

Display templates

Since you know that you you need to show “contact info” on many other pages it makes sense to group to this functionality into a sort of custom property.

   1: public class Person : IAmAPageType
   2: {
   3:     public string Name { get; set; }
   4:     public ContactInfo ContactInfo { get; set; }
   5: }
   6:  
   7: public class ContactInfo
   8: {
   9:     public string PhoneNumber { get; set; }
  10:     public string EmailAddress { get; set; }
  11: }

EPiServer uses the type to try and figure out how your control should be rendered and since we’ve specified a new type here (ContactInfo) we need to tell EPiServer how to display it in, for instance, Edit mode. We do this by using the standard Asp.Net MVC functionality called Display Templates. By placing an Asp.Net MVC user control called ContactInfo in a folder called Views/Shared/DisplayTemplates/EditMode/ContactInfo.ascx we can define the view behavior of our custom property in edit mode.

We can of course do the same for the rendering of our page in our normal views. To display the control you again use standard functionality as such

   1: <%: Html.DisplayForModel("ContactInfo") %>

 

IoC-based development

IoC is used internally by EPiServer and if you don’t care about it you don’t have to. if you do, good for you! Let’s say that you on the Person page need to list the persons who are also working in the same department as the person you’re viewing. To get that list you need to do some sort of query based on the current page as well as some sort of structure information.

To access these two separate sort of data you need to instruct your class that you’re interested in this information. You do this by taking a constructor dependency to the interfaces IDataFactory, IStructureInfo and IPageMetaData.

   1: public Person(IDataFactory dataFactory, IStructureInfo structureInfo, IPageMetaData pageMetaData)
   2: {
   3:     this.dataFactory = dataFactory;
   4:     this.structureInfo = structureInfo;
   5:     this.pageMetaData = pageMetaData;
   6: }

Using these interfaces which EPiServer automatically injects concrete classes for us enables us to access data (IDataFactoryFacade), relate to some form of page structure (IStructureInfo) such as what my parent(s) is/are and finally information about the page itself  (IPageMetaData) such as it’s Id, LinkUrl and whatnot.

   1: public IList<Person> GetRelatedPersons()
   2: {
   3:     return dataFactory.GetChildren(pageMetaData.ParentId);
   4: }

And naturally, as long as you’ve told the IoC-container how to resolve them you can add additional dependencies to the constructor and EPiServer will make sure that the concrete implementations are injected.

 

Testability

These features makes it really easy to test EPiServer without having to setup a database, custom page providers or any other magic stuff.

 

Bye bye present-Stefan

Oct 18, 2010

Comments

Per Hemmingson
Per Hemmingson Oct 18, 2010 09:32 AM

+1. An EPiServer "Magic Unicorn Edition" would be nice!

Oct 18, 2010 03:55 PM

Awesome! Maybe future-Stefan has started a trend and other people from the future will try to contact us :-)

Marthin Freij
Marthin Freij Oct 18, 2010 06:27 PM

Great stuff!

Arild Henrichsen
Arild Henrichsen Oct 18, 2010 08:07 PM

Great post, entertaining twist :-) Please bring me back a sports almanac.

Oct 19, 2010 02:09 PM

Hmm... I'm not sure that hard coding a relation between a class and a page type is the best way to go.

It will is perfect if you are providing all functionality and have total control over the whole environment but it makes a future with more plug-able 3rd party module harder.

My future self probably sees the page type as a composition (or property bag) where your model class is only one perspective of the page. If you install a 3rd party module (maybe from the future EPiAppStore ;) it might need additional properties.

But I do agree that Code First is a good way forward! And I like the idea with interfaces to EPiServer Services.

Oct 20, 2010 09:36 AM

I really like your ideas. When you read this in the future, could you privately send me back all the winning lottery numbers?

Please login to comment.
Latest blogs
Opti ID overview

Opti ID allows you to log in once and switch between Optimizely products using Okta, Entra ID, or a local account. You can also manage all your use...

K Khan | Jul 26, 2024

Getting Started with Optimizely SaaS using Next.js Starter App - Extend a component - Part 3

This is the final part of our Optimizely SaaS CMS proof-of-concept (POC) blog series. In this post, we'll dive into extending a component within th...

Raghavendra Murthy | Jul 23, 2024 | Syndicated blog

Optimizely Graph – Faceting with Geta Categories

Overview As Optimizely Graph (and Content Cloud SaaS) makes its global debut, it is known that there are going to be some bugs and quirks. One of t...

Eric Markson | Jul 22, 2024 | Syndicated blog

Integration Bynder (DAM) with Optimizely

Bynder is a comprehensive digital asset management (DAM) platform that enables businesses to efficiently manage, store, organize, and share their...

Sanjay Kumar | Jul 22, 2024

Frontend Hosting for SaaS CMS Solutions

Introduction Now that CMS SaaS Core has gone into general availability, it is a good time to start discussing where to host the head. SaaS Core is...

Minesh Shah (Netcel) | Jul 20, 2024

Optimizely London Dev Meetup 11th July 2024

On 11th July 2024 in London Niteco and Netcel along with Optimizely ran the London Developer meetup. There was an great agenda of talks that we put...

Scott Reed | Jul 19, 2024