Managing Non-Web Content in Episerver
This code is a supplement to a blog post on episerver.com: Episerver Content Has Always Been Headless
This code represents a proof-of-concept and sample code for manipulating non-visual/non-web content in Episerver. The content object definition (Person.cs
) and controller (PersonController.cs
) effectively form a very limited, bespoke headless endpoint for a specific type of content.
This is not a new feature. It's not even new code. This functionality has been in the product for years.
IMPORTANT NOTE:
Episerver has a Content Delivery API. Use that instead of this.
This code exists merely to prove how easy it is to manipulate "pure" content in Episerver, and to demonstrate how Episerver content doesn't need to be traditional "web" content. In no way is this being presented as the correct way to work with Episerver content headlessly.
That said...
In data terms, Episerver content is based on a hierarchy of classes. The traditional "web" content is actually built on a foundation of more pure content representations. ContentData
is the abstract representation of content. The BasicContent
class extends from this and allows you to create, manipulate, persist, and delete content objects that have no URL and provide no web rendering.
(For web content, ContentData
extends into PageData
and BlockData
. There are also classes for MediaData
and ProductData
.)
The Person
object in the sample below can be persisted to and retrieved from the repository. It implements IVersionable
, so it will accumulate versions as you edit. It must exist as the child of a parent object (page, folder, root, whatever -- defined in the ROOT_ID
constant), and it can have children of its own.
The Person
object has two properties:
Name
is inherited fromContentData
Age
has been added directly toPerson
Any property type in the Episerver library is available. From a modeling perspective, classes extending from BasicContent
perform like any other objects.
These objects will never appear in Edit Mode, nor will they have URL -- and they shouldn't, because they're not web content.
They're just...well, content.
(You could effectively "hide" content under pages this way. If you implemented, say, blog comments as BasicContent
, for example, you could make them children of the page they were entered on, which would make them easy to find from code, and they would delete with an "owning" page, but they would never appear in Edit Mode.)
These objects can be managed in Content Manager, since that UI is designed in part to service content outside the web channel. You can create a custom view for the content type, then create, edit, and delete them from the Content Manager UI. Additionally, the content is fully available from C# via IContentRepository
or IContentLoader
.
Again, I want to stress -- this is not a demonstration of Episerver's headless capabilities (see our Content Delivery API). This is simply to prove that Episerver is very good at managing content, and any web-specific functions and features are layered on top of that foundation.
Installation
These two files should "just work" if compiled into an Episerver installation, with two small changes:
- Change the
ROOT_ID
constant to represent the parent of where the new content should be created - Ensure the content object represented by
ROOT_ID
allows thePerson
type as child objects via itsAvailableContentTypes
attribute
When functioning, the following URL patterns will become available (assuming no prior conflicts):
/person/new?name=[name]&age=[age]
/person/edit/[id]?name=[name]&age=[age]
/person/delete[id]
/person/delete
(deletes allPerson
objects underROOT_ID
)/person/show/[id]
/person/show
(shows allPerson
objects underROOT_ID
)
Some notes:
- There is absolutely no authentication on this. If you deploy this as-written, you deserve what you're gonna get.
- The format of the return value is created in the
GetSimplePerson
method. This is a completely invented format. It's assumed you have your own format you want to return. Go nuts. - All actions are implemented as GET requests to make it easy to demo and test. Most of these (anything other than
Show
) should be re-implemented as POST.
The code is relatively solid and has been reviewed, but this is not something you should deploy to production.
Finally -- and I know I've said this before -- this not representative of Episerver's headless API or capabilities. This is very specific code meant to illustrate a very specific thing.
Deane Barker
August 2020