Vulnerability in EPiServer.Forms
I have a problem which I probably can solve by hooking up a handler for the TemplateResolver.TemplateResolved event, but I wanted to check if anyone have a different suggestion for how to solve this.
A client of mine currently have a number of country-specific sites. It started with only one, and when the time came to release the site in a new country, it was decided at the time to simply copy the UI project of the first site, and use the copy for the second site. Then came the time to open up in a third country, so repeat the process. Although most of the code is more or less identical, there are differences, such as different countries having different payment providers when creating accounts.
Now we want to merge all these sites into a single UI project. However, we would like to NOT have a million if-statements in the code, to run different things depending on which site is currently being rendered (and we want to avoid the hassle of having a bunch of copies of each page template).
My current thinking is to have mulitple controllers registered for the same template (e.g. the CreateAccountPage), name the country specific controller something like CreateAccountPageSeController, and then select that controller in the TemplateResolved event (based on which site is being rendered), and if there is only a single controller implemented, simply let it handle it.
I was first thinking about changing templates depending on the FQDN of the request, but it's probably better to change depending on the language of the page being rendered.
Now, my question is - does anyone have a better solution for this particular problem?
Believe me - it will be a mess at the end :)
What if one of the countries provides content in the same language that another site has - like English? How would you resolve this case from the perspective of having a controller (or in general site request context where the denominator is only a language)?
Have you looked into asp.net mvc areas? That might be one of the ways to organize your site. Country specific stuff could be under the area, global shares ones - in the root. There are also some plugins out there to relieve your pain to work with areas.
Dynamically resolving templates also might work - depends on how many countries and how many customization each of the country has..
It's currently only 3 countries, but will soon expand to 2 more, and no-one knows when additional countries will be launched.
The problem I see with areas is that areas doesn't exist in .Net Core/.Net 5+, so choosing that alternative means we have to re-work everything again the day we migrate from .Net Framework to .Net 5+. Not really something I look forward to (the re-work-everying-again part, I would love to upgrade to .Net 5! :) ).
Content-wise, each country has their own node in the tree, we will currently not be using the language/translation support in the CMS. However, all sites will run as a single site in IIS, which means the same code base for all sites.