Dette er CodeArts blog. Vi deler thought-leadership og tekniske tips og tricks - men som regel på engelsk.
Over the years I have been involved in quite a lot(!) of Episerver addons and integration projects. A key to a successful add-on is to get the entire project and environment correctly setup and working from the start. This is my recipe.
Sidebar extensions is a great way to add tools, widgets and integrations to editors, without relying on a specific field. In this post I'll explore them a little, and also test out how much crazy stuff we can actually do with the javascript SDK.
In this post, I'll show how to make a field editor that will let you have any kind of syntax highlighted code in a long text field, as well as taking a look at command line interface (CLI) and Github distribution.
Contentful has a handful of extension points, where you in a fairly straightforward and simple manner can extend the editorial experience with minimal development effort. In this post-series I'll show some examples of this.
Having the right content model (the structure of your content types) is very important in order to end up with good, usable (and reusable) content. I believe that is something that most content management aficionados can agree on. But what is a good content model? And who should be modelling your content? In this blog post I will try to discuss a few opinions on this topic.
The move in the market towards headless could also be seen as a tendency towards a deeper decoupling between content and experience delivery. Inspired by a few discussions, I've tried my hands on an uncommon combination: Contentful providing content delivered through an Episerver web experience layer.
In 3 previous blog posts I compared various azure storage technologies with regards to performance and scalability in typical web usage scenarios. I was actually done with the series, but with all that interesting data, I decided to throw my current favorite search/storage/no-sql technology into the mix to get an idea about how it all compares. So - ElasticSearch enters the competition!
This is the 3rd post in my Azure Storage Performance comparison. So far we've examined the typical scenario of storing/retrieving data that most dynamic websites of today deal with. In this post, we'll take a closer look at Update and Delete - and finally review the financial aspects.
In this second post of my performance series looking at Azure storage we're going to take a good look at Read speeds for the various storage types.
Almost every project has some data you want to persist, then read, search through, update and eventually delete. With Azure there are loads of great possibilities - for example Blob Storage, Table Storage, CosmosDb, SQL Azure. I've decided to do some simple and fairly naive tests to compare these for some typical usage scenarios and see how they perform.
Azure Storage has a new cool feature in preview - Static Website. But what exactly does it do - and how can I connect my Episerver installation to it? I decided to find out.
