Enhance ServiceStack Razor page lookup options
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/<plugin_folder_name>/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/<theme_name>/<plugin_folder_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.
Matthew Cowan
shared this idea
-
Matthew Cowan
commented
Sounds good. Initially I thought I would be able to contribute to the code base in this area, but I haven't come up with something yet that I feel is applicable enough to the larger community, without introducing assumptions that mostly don't belong in the framework, I'm too buried perhaps in my use-cases. I think if more people get interested in visiting this feature set, or related features, we'd get better consensus on specific desired outcomes.
If an injectable strategy can be introduced, that would suit me just fine, better than fine even. I'll be glad to visit it with you if the window of opportunity arises, and anyone else if there's interest.
-
It looks like I'm going to have to go over this use-case with you when I have time Matthew. Issues with this feature is not losing the "auto match" Request/Response DTO with Razor Views and not forcing users to require knowledge of any rules or complex configuration for views structure and layout.
So any solution should be opt-in and not affect existing behavior, I'll have to explore being able to provide an injectable strategy - it might work like you say by just being able to provide a custom fallback strategy for un-matched routes.
