Skip to content
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

Closed
MikeKry opened this issue Apr 30, 2024 · 9 comments
Closed

Expose ContentItem props - Data and Elements #15923

MikeKry opened this issue Apr 30, 2024 · 9 comments

Comments

@MikeKry
Copy link
Contributor

MikeKry commented Apr 30, 2024

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:

var json = JsonConvert.SerializeObject(importModel);  // transforming custom object that has same structure as ContentItem into json

var model = JsonConvert.DeserializeObject\<ContentItem\>(json); // deserializing json into ContentItem as it is only way to create content item with data and elements filled.

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)

@sebastienros
Copy link
Member

And it contains "BlogPost" entry with a different type (ContentPart) that can not be casted to my type (BlogProps).

This was fixed recently, could you try the main branch?

@MikeKry
Copy link
Contributor Author

MikeKry commented May 31, 2024

@sebastienros

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?

@sebastienros
Copy link
Member

#15974

Copy link
Contributor

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.

@github-actions github-actions bot added the stale label Jun 16, 2024
@hishamco
Copy link
Member

@MikeKry please try the latest bits, then close if it's fixed

@MikeKry
Copy link
Contributor Author

MikeKry commented Jun 16, 2024

@hishamco @sebastienros

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

@MikeKry
Copy link
Contributor Author

MikeKry commented Jun 16, 2024

btw. difference between our importer and #14630
is that our importer simply creates objects/jsons from import data and then transforms them into content items and relies on content manager to validate fields. Which is way easier/less code than creating items field by field, part by part. So not sure, if it would not be possible solution also for content transfer module..

@github-actions github-actions bot removed the stale label Jun 18, 2024
Copy link
Contributor

github-actions bot commented Jul 3, 2024

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.

@github-actions github-actions bot added the stale label Jul 3, 2024
Copy link
Contributor

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.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants