Would like to give everyone a heads up on the new changes to ServiceStack Templates http://templates.servicestack.net which has now been re-branded to https://sharpscript.net 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 http://templates.servicestack.net 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;tousing ServiceStack.Script; - Any classes with
TemplatePage*has been renamed toSharpPage* - Any other class with a
Template*prefix has been renamed toScript*
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:
- API Pages are now called Sharp APIs
- Web Apps are now called Sharp Apps
- Template Filters are now called Script Methods
- Template Blocks are now called Script Blocks
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.