This week in Orchard - 9/14/2018
Check out our current post for the Dynamic compilation with C# 7.3 support in Orchard 1.x and for a lot of exciting Orchard Core improvements!
On Orchard 1.x
Demos
Dynamic compilation with C# 7.3
First of all, let's mention two notion in a nutshell:
- Static view compilation: you can build your Razor files without needed to build the solution
- Dynamic compilation: you do not need to build your solution if you modify a cs file for example, you just need to hit save in your IDE and you can test your newly implemented features
You can find dozens of documents about Static view compilation and Dynamic compilation in the web, so if you are interested in this topic just fire up a web search engine.
Orchard 1.x not just supports dynamic compilation, but the Roslyn compiler has also been updated, so you can use the newest language features of C# that comes in the version 7.3.
You can find a great demo about the Dynamic compilation in the latest Orchard podcast thanks to Benedek Farkas from Lombiq. In this demo he showed the working of the Static view compilation, the Dynamic compilation and he also overwrites a Razor file via FTP to a site that has been deployed to Microsoft Azure.
On Orchard Core
Crate a Font Awesome Icon Picker
The idea is to create an editor for the TextField that would show a Font Awesome editor. In this page you can see an example for a dropdown where you can search and filter icons: https://farbelous.io/fontawesome-iconpicker/
David Ouwinga has an existing implementation for this feature in Orchard 1.x, that works in the following way:
It could be a very useful feature for Orchard Core, so after making a PR and other small changes, it could be in Orchard Core as well.
Injecteble IOrchardHelper to Razor views
If you take a view you have access to Orchard helpers, because in the _ViewImport.cshtml file, we inherit from the base RazorPage, that we defined in our OrchardCore.DisplayManagement project. The RazorPage contains lots of properties, like New, ShapeFactory, DisplayAsync, T, etc.
In a decoupled scenario we didn't have access to this helper, because we cannot inherit from that base RazorPage. Now if you inject OrchardCore.IOrchardHelper you will have access to every property defined in the RazorPage.
@page@inject OrchardCore.IOrchardHelper Orchard<body dir="@Orchard.CultureDir()">
...
</body>
So now the IOrchardHelper is injectable.
Introduce ContentItem.DisplayText
The idea is when we show the popup to select the elements, any module can provide search result providers. So, the content picker can find content items from specific providers, for example, Lucene being one. The issue was that when you type some text and get the content items, the providers use the Title of the content item, but not only the TitlePart can provide the Title. Also Title is only technically availabe and searchable in the Lucene index, because it can index any display text from any content item. So, if you search for some text that doesn’t have a TitlePart, you may not find what you want.
Instead of making the DisplayText a ContentItemMetadata, make it common so we are sure that every content item will have DisplayText and anyone can search for this property, because we will also index that in the SQL database. Therefore, we don't require Lucene anymore to search something by its Title.
So, let us introduce you the ContentItem.DisplayText, that will make ContentItemMetadata.DisplayText obsolete and we don't require Lucene anymore to search something by its Title, so the TitlePart is not needed for every content item that we would like to search in. The TitlePart is just for to render and edit the Title of a content item, its a behaviour that is reusable. The idea is that we always have issues with TitlePart being optional and not being able to use it to order items. As we mentioned it's also an issue to search for content items, most often requiring Lucene to be configured.
Also realize that the ToString() method of a content item is the DisplayText instead of seeing "ContentItem".
Show Login pages on the admin theme
Last time we mentioned that the login controller (AccountController in OrchardCore.Users.Controllers) redirects us to a front-end page to login. Then it tries to find the theme and it will fail, because in a Decoupled CMS that is not necessary to have a shape. The login can't be decoupled right now, because it's completely coupled to the front-end.
In WordPress, the Log In page has a different theme than the front end. Maybe Orchard Core could have the same approach here: have a different back-end theme for the Log In page. In this case when you design your front-end theme you should not have to care about to style the Log In page.
User management: separate admin users and front-end users?
When we authenticate on the Log In we can see all the users on the admin page. The users we show in the admin is a mix of the admin users (who has access to manage content) and the front-end users.
Let's say we have an e-commerce site where we have customers. The question is should be the customers and the administrators of the site being stored in the same database/table and showing in the same list of users?
Listen the conversation about the pros and cons of the concept of separating the admin and the front-end users at the end of the latest Orchard podcast!
On Lombiq
Win a year of free custom domain usage: Still time to fill out the developer survey!
As we've written about before we ask you to tell us everything you wish DotNest would do differently. The DotNest developer survey is still on, but not for long: We'll close it on the 23rd. If you haven't filled it out here's the time, because you may also win a year of custom domain usage!
So tell us your thoughts in the survey, enjoy an improved DotNest and win!