OrchardCore
OrchardCore copied to clipboard
OrchardCMS
Allow invariant type/part definition lookup in ContentDefinitionManager
Is your feature request related to a problem? Please describe.
When using the AdminMenu module, the content-type is provided in the URL. For example, /Admin/Contents/ContentItems/Event where Event is the content type. Changing that to event will return "The page could not be found". Also, when creating a new content item using the Contents module, the URL will be wrong in the UI if the case changed.
Similar issue when editing content types or content parts in the UI.
Describe the solution you'd like
The ContentDefinitionManager should do invariant definition lookup to prevent this issue.
Why does it needs to be invariant? You use what you created. If you created as Event than you should use it as Event and not event
Because when the user provide event in the URL it would fail. I think Event is the same as event and should be handled the same. Why would we treat Event any different than event
Not sure if this request might add breaking changes as type systems are case sensitive - in C# event and Event can be represented differently and technical names are tied to C# types
Not sure that I follow you. This has nothing to do with c# code. This is a string comparison. So we would be treating String.Equals(“event”,”Event”, StringComparison.OrdinalIgnoreCase) so the content type that is called “event” will be the same as the content type that is named “Event”
Just being on safe side, Try creating EventPart and eventPart with different properties in c# and create event content using evenyPart and Event content using EventPart
if the requested change is not returning expected type/part then it will be breaking changes for someone
I guess if a user already use content type called “Event” and also another content type called “event”, then yes it’ll break his code. But why would one do that? And how easy will it be to tell the difference between the two.
@CrestApps love OrdinalIgnoreCase ;)
Yes, as we did for tenant/shell names, okay no problem if we don't allow to create "duplicate" that only differ by case, which is the case for type/part names through the admin, but to be fully consistent the inner dictionaries would need to be case insensitive (as we did for the shellHost inner dicos). So looks like to be a little bit more complex in this sensitive area.
@jtkech I do like to use OrdinalIgnoreCase when it make sense. :)
If you look at #12102, you’ll see now that the dictionaries are case insensitive, including the name lookup in the definition builder and the UI. Previously, we did some validation in the UI by using OrdinalIgnoreCase. Now, it’s consistent across the board “unless I missed something”
I guess if a user already use content type called “Event” and also another content type called “event”, then yes it’ll break his code. But why would one do that? And how easy will it be to tell the difference between the two.
I don’t know :-) - all I can see is someone might create as if it’s allowed
@ns8482e actually, I just tried it. The UI prevent you from creating “event” if “Event” already exists.
The line prevent the user from creating the name using UI. The good news is that this isn’t going to be a breaking change. It’s more of making all the rules the same :)