-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose ContentItem props - Data and Elements #15923
Comments
This was fixed recently, could you try the main branch? |
Do you please know where is commit / PR that fixes that? I can not really use current main branch in given project, so I could try to look at it atleast. But anyway, if this was fixed for indexproviders, it still does not cover custom importer scenario. Is it a problem making these props public? |
It seems that this issue didn't really move for quite a while despite us asking the author for further feedback. Is this something you'd like to revisit any time soon or should we close? Please reply. |
@MikeKry please try the latest bits, then close if it's fixed |
This PR surely fixes given example that I provided for Elements property. Anyway it is not what I wanted to point out. My main goal is to increase flexibility of content handling by making Elements and Data property publicly accessible. Another way might be keeping Data and Elements private, but provide constructors that can create content item and set custom data. I want to create same logic as is here but from outside module (https://github.com/OrchardCMS/OrchardCore/blob/main/src/OrchardCore/OrchardCore.ContentManagement.Abstractions/ContentItemConverter.cs). But instead of deserialization of json, I would just insert my JObject into Data property. But I will try to revisit this on my side once more, maybe I will be able to utilize logic from ContentStep.cs |
btw. difference between our importer and #14630 |
It seems that this issue didn't really move for quite a while despite us asking the author for further feedback. Is this something you'd like to revisit any time soon or should we close? Please reply. |
Closing this issue because it didn't receive further feedback from the author for very long. If you think this is still relevant, feel free to reopen it with the requested details. |
Is your feature request related to a problem? Please describe.
This feature request aims to provide easier custom implementations on project side without modifying core. Application can be in custom importers, typed fetching of elements on project side etc. Right now I have problems with creating custom implementations that work with elements.
Example on Elements property:
I have a blog post type defined in CMS (so it is a dynamic content type). It has some fields that I want to fetch, but I do not want to register it in code. So I have concrete class, that inherits ContentPart and exposes some fields (dont want to use deserialize/reflection/..).
But there is a problem - when I use contentItem.Get("BlogPost") in controller, it works okay. But when I call it at indexprovider level, it throws exception.
Exception is thrown because at IndexProvider, Elements array is already filled up. And it contains "BlogPost" entry with a different type (ContentPart) that can not be casted to my type (BlogProps). So what I can do now is to clear Elements array and it will work again. But I cannot do that from project level, so my only way to clear it, is to call self referencing merge - "contentItem.Merge(contentItem, replacesettings..);" because it contains this Elements.Clear().
Example on data property:
I have created a custom importer that transforms CSV data from old solutions like Joomla and I am using contentManager to handle data operations. But that means I need to transform data to ContentItems.
Currently, there is no option to create and customize data of ContentItems from outside of OC libraries. Only possible way to initialize ContentItem with data that I need is:
This approach uses predefined JsonConvertor from OC that will transform data to form I need, but it is not very elegant.
Describe the solution you'd like
In my opinion, properties on ContentItem should be public, so it is possible to play with them as needed. It is well designed for usecase that currently OrchardCore needs, but for customization, it becomes very challenging when I do not want to customize core packages.
Basically it is about making ContentElement.Data and ContentElement.Elements public
Describe alternatives you've considered
Dont know any, feel free to suggest something else. I know many other people did their importers, so maybe there is other way.
For elements, solution might be also some parameter "UseCache" that allows to ignore fetching from elements.
Related also to #15530 (reply in thread)
The text was updated successfully, but these errors were encountered: