I have a custom basic CMS I put together (work in progress) for some of my clients that allows developers to build CMS plugins that auto-install on application startup. The plugins can deploy both content pages and view pages (and use ServiceStack plugins and CMS plugin interfaces to configure, and add capabilities to the CMS at startup), similar to how NopCommerce and Orchard work.

Currently, I have to rely on view pages to be unique, but I would like to be able to modify the lookup algorithm to take advantage of paths to the razor/markdown pages in the Views folder, so that page name uniqueness isn't required (each plugin right now that wants to take advantage of View pages has to preface their view right now in their Views directory with a plugin prefix, i.e.: blog-index.cshtml, events-index.cshtml, instead of Views/<pluginfoldername>/index.cshtml).

Content pages don't have this issue...

Maybe in it's most basic form enhance with another attribute [DefaultViewPath(~/blog)], or [DefaultViewPath(<regex>)] that we can tag our DTOs or services with (or enhance the existing DefaultView attribute) ... Better maybe, an interface that can be implemented and registered that would control how the view pages (name and path) are registered in the lookup dictionary, and also how they are queried to determine the one to use at runtime.

This ability to have my own implementation would be beneficial. I have some theming in the CMS built-in for example, so that the path could look like this Views/Themes/<themename>/<pluginfolder_name>/index.cshtml. If a path doesn't exist, the child theme algorithm kicks in to resolve the proper path, until it reaches the root default theme path (similar to Wordpress), where every page always has a version of itself.

Right now I have various workarounds that make all this work, but I've had to re-write some classes in ways that wouldn't be beneficial to the community, too custom for my scenario ...

I will also probably be looking into leveraging paths in special localization cases, still brain-storming that.

Just an idea, probably not gonna top the list, but thought I would throw it in. If nothing is done, I will make do. I'm very curious to see if anyone is leveraging the awesome ServiceStack Razor code base and running into issues like this.

I'm dubious about whether to suggest this, but something that enabled easier high availability for a SS Service would be great. This would maybe be more like a recipe than a feature, but possibly with features to help support it.

E.g.
We run a ServiceStack API Service which depends on redis and postgres, each with replication to secondary nodes which are readonly until we manually execute a failover command. Running multiple ServiceStacks on VPSs (or whatever) is easy, but having them co-ordinate is slightly trickier. So the type of thing I'm suggesting would include

• Digital Ocean recipe for running up multi-region VPSes with ServiceStack


• Endpoints for inter-node communication (for availability checking)


• DNS Setup guide (assuming this will be the simple HA technique)


• Each node having independent, but possibly co-ordinated config


• Support for "routing/proxying" back to master node (depending on DNS setup), so if slave node receives a request, it will execute as if on master, but with extra latency


• Live config reload (for automated failover) (e.g. change postgres connection string to x.x.x.x)

Imagine you have large DTOs that are ushared for GET, POST and PUT.

Some properties might only be used for display purposes, and cannot be updated (i.e. denormalized fields).

You might also allow the setting of a property on POST, but not on PUT. For example, you might not allow the Id of an object to be set on POST (because it will be the primary key identity insert), but if you want to update it, you can pass it in a PUT:

We currently are doing this using a custom attribute and interface on the models and model properties.

[ReadonlyRequest(ApplyTo.Post, null)]
public int? Id { get; set; }

Before each request we build up a list of warnings that we add to the request context. We also remove / set the default on any properties using this attribute.

After the request is processed, we automatically add a list of warnings to the ResponseStatus.

The calling client then knows based on the response, which of the data they have passed will simply be ignored.

When creating immutable objects, it's common to not have a default constructor. ServiceStack.Text supports this presently with the use of FormatterServices.GetUnitializedObject. However, GetUnitializedObject does not do any field initialization. The DataContractSerializer works around this with support of the OnDeserialized attribute; but why would we want to write the initialization code twice? Instead, We should change ServiceStack.Text to fall back to private constructors. Here is some proposed code.

    public static ConstructorInfo GetEmptyConstructor(this Type type)

    {

if NETFX_CORE

        return type.GetTypeInfo().DeclaredConstructors.FirstOrDefault(c => c.GetParameters().Count() == 0);

else

        var ret = type.GetConstructor(Type.EmptyTypes);

        if (ret != null) return ret;


        // attempt to use constructors with all default values

        var ctors = from ctor in type.GetConstructors()

                    let prms = ctor.GetParameters()

                    where prms.All(p => p.IsOptional)

                    orderby prms.Length

                    select ctor;

        ret = ctors.FirstOrDefault();

        if (ret != null) return ret;

        if (JsConfig.UsePrivateConstructor)

        {

            ret = type.GetConstructor(BindingFlags.Instance | BindingFlags.NonPublic, null, Type.EmptyTypes, null);

        }

        return ret;

endif

    }