EPiServer vNext Falcon Seminar

The Swedish hospitality has been great, in the form of lunches and drinks and also borrowing a work desk at the Nansen office. Thank you very much, Martin Söderlund and Leif Boström!

So then, EPiServer vNext Falcon! There were three key points in the presentations, I will go through each one and state my thoughts. EPiServer made it very clear that this is all work in progress, and things might (and probably will to some extent) change. So to you reading this blog post two years from now: These are my private opinions based on how I interpreted what was said during the presentations.

Add-Ons

The Add-On system is a piece of functionality that I think will be loved by editors and potentially frowned upon by developers if EPiServer don’t play their cards right.

The Add-On system can be compared to an “App Store” where editors can install Add-Ons to their website without involving any developers. The Add-Ons will be available through a NuGet feed and will probably have to go through an approval process in order to become available.

There are quite a few interesting challenges when it comes to this, and these possible challenges were made clear in the Q&A after the presentation:

-  How will EPiServer deal with Add-Ons and load-balancing?
-  How will EPiServer ensure that a site doesn’t break when an editor installs an Add-On?
-  Will contributing developers be compensated for creating an Add-On?

In addition to the Add-On system, there was a short presentation on Localiation. EPiServer announced that their language files will be included as embedded resources in vNext. I quite like this, as it removes EPiServers files from the developers files, and I can’t remember ever having to edit one of the EPiServer language files.

Typed pages

This is a huge one!! We’re all familiar with PageTypeBuilder, every developers dream and every editors nightmare, and EPiServer has come to the terms that they need to include typed pages in order to make us all just a little bit happier.

One of the things I found quite interesting is the concept of Blocks (another term for property groups). Grouping of properties into Blocks (for example an image, and alternative text and a link) will diminish the need for custom properties. This in connection with allowing complex property types such as Lists or Dictionaries will in the long run mean that we won’t need custom properties at all. Oh joy!

EPiServer also suggested that properties defined in code should be made hidden (or not editable) for editors. One of the issues we’ve had with PageTypeBuilder is when a property’s attribute (such as SortIndex) is set in code, and the editor changes this attribute, the change made by the editor will be overridden when a new deploy is done. Hiding properties defined in code from the editors will (hopefully) solve this issue.

MVC Support

This is another case that deserves a large Woho! I’ve been drooling over ASP.NET MVC for quite a while, but creating Gadgets doesn’t quite dry up the drool. We were shown how MVC Routing will be implemented to work with EPiServer friendly URLs. The fact that a site can contain both web forms and MVC is even better.

There are a couple of downsides for the editors though. On-page-edit won’t work with MVC and neither will the right click menu.

Disappointments

I was hoping I wouldn’t need this section of the blog post, but sadly I do. I’m very disappointed that EPiServer isn’t giving the File Manager any love. It’s a pain for the editors to work with, and it’s quite outdated compared to how everyone have gotten used to managing files.

Unconfirmed rumors and possible bogus

- Will edit mode “disappear” in the long run to be replaced with an on-page-edit like UI with Widgets?

- As a result of the previous point, will on-page-edit disappear?

- Will edit and admin mode be rewritten to MVC?

- Are the developers at EPiServer superheroes who will be able to deliver all of this in Q1?