ServiceStack Templates is now #Script

Would like to give everyone a heads up on the new changes to ServiceStack Templates which has now been re-branded to in the latest v5.4.1 on MyGet.

Effectively all the classes in ServiceStack.Templates is now available under ServiceStack.Script, to preserve as much source code compatibility as possible the existing “User Facing” ServiceStack.Templates classes are now stubs in ServiceStack.Templates which inherit from the re-named classes, which are all obsolete with the deprecation message containing the new class name.

In most cases this should retain source-code compatibility where the existing Template* classes continue to exist, except they’ve all been deprecated. Some classes which couldn’t be duplicated like if you were using PageResult in your Services, it would now require adding a using ServiceStack.Script; import which is effectively all the changes that needed which is the old docs site for ServiceStack Templates (documenting all its features) needed to run its now deprecated APIs with the latest v5.4.1 containing the latest changes. To help verify this change would be minimally disruptive I’ve extracted all the source code using the old APIs and added them in BAK_CompatTemplateTests.cs to verify they still run.

Migrating to #Script

As the re-branding was effectively a renaming exercise migrating to the new classes is fairly straight forward:

  • Change using ServiceStack.Templates; to using ServiceStack.Script;
  • Any classes with TemplatePage* has been renamed to SharpPage*
  • Any other class with a Template* prefix has been renamed to Script*

This change doesn’t affect your existing Templates/#Script source code whose existing syntax and available filters/methods remains unchanged.

New Feature Names

The primary reason for the change was that “Templates” ended up being a horrible feature name to try and document, whereby moving to a different “label” makes it much easier to document its various features.

This lets us now use #Script when referring to the language itself (i.e. JS Expressions + Vue/Angular template expressions + handlebars blocks).

In this case using it as a dynamic scripting language using a ScriptContext is more appropriate than a TemplateContext, e.g:

var context = new ScriptContext { 
    ScriptMethods = { new DbScriptsAsync() },
    Args = {
        ["id"] = 1
} .Init();

var result = context.Evaluate<Customer>(
    "{{ `select * from customer where id=@id` | dbSingle({ id }) | return }}");

Likewise using ScriptMethods instead of TemplateFilter sounds more appropriate for injecting methods into your script, same for TemplateBlocks which are now called ScriptBlocks.

It also means that other features are easier to label and document, so when referring to the Templates as a View Engine we’re now calling Sharp Pages which is a better corollary to “Razor Pages” which it provides an alternative to.

Other re-branded features include:

A collection of script methods you inject in your scripts like TemplateRedisFilters and TemplateDbFilters have also been renamed to RedisScripts and DbScripts.

I hope that captures all the changes to ServiceStack Templates, please note if you’re migrating from v5.4.0 be aware that Request Params now need to be explicitly accessed.

Happy to answer any questions about any of the changes in this Thread.

This topic is now pinned globally. It will appear at the top of its category and all topic lists until it is unpinned by staff for everyone, or by individual users for themselves.

This topic is now unpinned. It will no longer appear at the top of its category.