Add fallback alternate when a custom stereotype is used, tenant removing - This week in Orchard (16/09/2022)
Add fallback alternate when a custom stereotype is used, validate database connection before allowing a tenant to be added or set up, remove localization workaround in Data Annotation Attributes, and a demo about the upcoming tenant removing feature! Check out our post for the details!
Orchard Core updates
Add fallback alternate when a custom stereotype is used
The idea here is that when you create a stereotype, before this change, you had to create templates for this stereotype if you intended to display or edit items of this stereotype. And now, there is a fallback shape for stereotypes such that if you don't create custom templates, it will use a standard, default template that is valid for any stereotype.
How it works is just to let's use the Content shapes for anything when we don't have a custom template. It prevents showing error messages when you create a stereotype and try to create a content item from this stereotype.
And you can test this one easily. Just navigate to the admin UI of Orchard Core and head to Content -> Content Definition -> Content Types, where you can find the Create new type button to define your new content type. Add a name to it and hit Create. We will not add any Parts to it right now. Set the Stereotype to Cat and hit Save. Now we can create a new Animal content item by clicking on the New button and selecting Animal under Content -> Content Items. And as you can see, Orchard Core now renders the default Content_Edit template as a fallback instead of throwing an exception.
Validate database connection before allowing a tenant to be added or setup
When adding a new tenant, we allow the user to set a prefix to the tables to enable reusing the same database for multiple tenets. However, we don't validate that the prefix isn't already used first. The problem with this is that it throws an exception. Let's say we have a tenant with a URL prefix test and we selected the SQLite database. Now let's create another tenant using the same URL Prefix and database preset. As you can see, now we have a validation error.
But we also have validation for connection strings as well. Let's say we would like to use SQL Server and provide a connection string that is invalid. In this case, you will face an error like "The provided connection string is invalid or server is unreachable".
Remove localization workaround in Data Annotation Attributes
Two years ago, when Hisham Bin Ateya started the support data annotations PO localization PR, there was a long discussion to support localization in data annotations. Back in the day, Antoine Griffard did a workaround to achieve the goal by using IValidatableObject, and now it's time to remove this workaround and use the new way of doing this.
This means we can remove the need of implementing the IValidatableObject from several ViewModel. And from now, on you can use some attributes which help you print localized error messages. And now there is an attribute for email validation and URL validation as well. Let's see an example quickly!
As you can see here, the RegisterViewModel implemented the IValidatableObject to be able to validate the properties inside the class. Now, instead of using the IValidatableObject, we can add attributes to these properties, and here comes the new EmailAddress attribute as well. As you can see from the screen, the new implementation of the ValidationAttribute can be used to validate your model by returning a localizable error message.
Demos
Tenant Removing
The option to be able to remove tenants is a long-requested feature, and for now, we are very close to shipping this feature, thanks to Jean-Thierry Kéchichian. Let's see how it will work! For this demo, we will navigate to GitHub and checkout this branch.
Now, let's add some tenants to be able to try out this feature. As you can see, we have added 3 tenants. The Agency and the Blog ones are tenants that we have already set up, but the tenant called test is waiting for setup.
Here you can see that we have the Sites folder under App_Data where each of the tenants has its own folder containing the Media files for example. And now we also have a wwwroot folder under OrchardCore.Cms.Web, which contains a folder per tenant like in the previous case. This means now each tenant can manage their own cached files under wwwroot. When we remove a tenant, the logic will also remove the folder of the tenant under the wwwroot and the Sites folders.
And now it's time to delete a tenant! To be able to delete a tenant, we should disable it first, which means it will be not served, and we will be able to compose an internal ShellContext with all the features that the tenant has, even if it is installed or not. You can also remove multiple tenants by using bulk actions.
And this is just the surface, there are still some things to do. If you would like to see the current state of this feature and do a deep dive under the hood, check out this recording on YouTube! This feature is sponsored by Lombiq.
News from the community
Orchard Dojo Newsletter
Lombiq's Orchard Dojo Newsletter has 347 subscribers! We have started this newsletter to inform the community around Orchard of the latest news about the platform. By subscribing to this newsletter, you will get an e-mail whenever a new post is published to Orchard Dojo, including This week in Orchard of course.
Do you know of other Orchard enthusiasts who you think would like to read our weekly articles? Tell them to subscribe here!