Content Items event handler, UpdatingAsync method: property "part" and "context.UpdatingItem.Elements" has always null properties

[MarGraz]

Hi everyone,

I already discussed a similar topic here. Last time, when I used the UpdatingAsync method, I was able to achieve my goal.

Now I have implemented a module with a CustomBagPartHandler : ContentPartHandler<BagPart>, which I intend to use to validate the number of items passed inside a BagPart contained within a new ContentType (e.g. a User).

Here is my handler implementation:

    public class CustomBagPartHandler : ContentPartHandler<BagPart>
    {
        private readonly IContentDefinitionManager _contentDefinitionManager;
        private readonly IActionContextAccessor _actionContextAccessor;

        public CustomBagPartHandler(IContentDefinitionManager contentDefinitionManager, 
            IActionContextAccessor actionContextAccessor)
        {
            _contentDefinitionManager = contentDefinitionManager;
            _actionContextAccessor = actionContextAccessor;
        }

        public override async Task UpdatingAsync(UpdateContentContext context, BagPart part)
        {
            BagPartCustomSettingsList? settings = await GetSettingsAsync(part);

            if (settings?.ContentTypeSettings != null)
            {
                foreach (BagPartCustomContentTypeSettings contentTypeSetting in settings.ContentTypeSettings)
                {
                    // Filter content items by the current content type setting
                    IEnumerable<ContentItem> contentItemsOfType = part.ContentItems.Where(ci => ci.ContentType == contentTypeSetting.ContentType);
                    int count = contentItemsOfType.Count();

                    // Validate against the min and max settings for this content type
                    // Allow the possibility to have Min and Max = 0
                    if (count < contentTypeSetting.MinItems || (contentTypeSetting.MaxItems > 0 && count > contentTypeSetting.MaxItems))
                    {
                        _actionContextAccessor.ActionContext?.ModelState?.AddModelError(nameof(CustomBagPartHandler), $"The number of {contentTypeSetting.ContentType} items in the bag must be between {contentTypeSetting.MinItems} and {contentTypeSetting.MaxItems}. Current count: {contentItemsOfType.Count()}.");
                    }
                }
            }

            await Task.CompletedTask;
        }

        private async Task<BagPartCustomSettingsList> GetSettingsAsync(BagPart part)
        {
            ContentTypeDefinition contentTypeDefinition = await _contentDefinitionManager.GetTypeDefinitionAsync(part.ContentItem.ContentType); 
            ContentTypePartDefinition? contentTypePartDefinition = contentTypeDefinition?.Parts?.FirstOrDefault(x => string.Equals(x.PartDefinition.Name, nameof(BagPart), StringComparison.Ordinal));

            return contentTypePartDefinition?.GetSettings<BagPartCustomSettingsList>();
        }
    }

The handler correctly retrieves the BagPartCustomSettingsList, but it seems impossible to access the User fields and parts. Exploring context.UpdatingItem.Content or part, the object appears to have all null values.

Here is what's inside context.UpdatingItem.Content:

And here is what's inside part:

I suspected that during the UpdatingAsync, the model is not yet bound, so I attempted to use the ValidatingAsync and ValidatedAsync methods, but they are never triggered 🤯🙃

This is how I implemented the ValidatingAsync method:

public override async Task ValidatingAsync(ValidateContentContext context, BagPart part)
{
    var settings = await GetSettingsAsync(part);

    if (settings?.ContentTypeSettings != null)
    {
        foreach (var setting in settings.ContentTypeSettings)
        {
            var contentItemsOfType = part.ContentItems.Where(ci => ci.ContentType == setting.ContentType);
            int count = contentItemsOfType.Count();

            if (count < setting.MinItems || (setting.MaxItems > 0 && count > setting.MaxItems))
            {
                context.Fail(string.Format("The number of {0} items in the bag must be between {1} and {2}. Current count: {3}.",
                    setting.ContentType, setting.MinItems, setting.MaxItems, count));
            }
        }
    }
}

Unfortunately the IContentPartHandler interface (here) doesn't have any summary for each method, which could have offered some guidance.

What am I doing wrong? I have spent several hours trying to fix this, also searching for an example in the Orchard Core solution, without success.

Thank you

[Piedone]

I don't have a solution from the top of my head, but here's a video with voice about how I'd approach figuring it out.

2024-05-03_01h14_33.mp4

[MarGraz]

Is it possible to ask the developer who created those methods to explain the best practices for using them?

I know I might be asking a lot 🫠, but I think it could be useful for everyone to have a clear set of best practices to follow. Then, we could also create a reference or add summaries to the IContentPartHandler interface.

Thank you

[Piedone]

I'm getting a bit overloaded here. Could you please formulate what you need help with and couldn't figure out from the OC source as as a single question in a paragraph?

[MarGraz]

Hi @Piedone,

Yes, I have done a complete overview of what I have done with the encountered issues. Perhaps it's a bit much 😅

Summary:

In OC 1.8.3, in the DefaultContentManager class, methods like NewAsync (here) and UpdateAsync (here) do not call ValidateAsync. This explain why my handler overrides for ValidatingAsync and ValidatedAsync are never triggered.

I have implemented a new approach (you can find it in the message above). Here's what I observed:

• CreatingAsync is called only the first time a new Content Item is created, which is the expected behavior.
• UpdatingAsync is always called, even when creating a new Content Item. This is strange.
• When creating a new Content Item, in the UpdatingAsync method I receive a null value part and context.UpdatingItem.Elements (as shown in the screenshots in the first message).
  Instead, when updating an existing Content Item, UpdatingAsync retrieves in the part and context.UpdatingItem.Elements the previously saved version, not the new one I need to validate.

Could this be a bug?
How can I add a validation handler for my bag part content items?

Thank you

Update: fixed the misused "Content Type", with the correct word "Content Item".

[Piedone]

I believe when you say new/existing "Content Type", you mean "content item" instead.

• The Validate* handlers are only called from ContentManager.ValidateAsync(). This seems correct.
• UpdatingAsync being called for a new content type also seems correct if you check out where it's called.
• UpdatingAsync receiving null in its part parameter for new content items doesn't seem correct. However, that's not what I see in your screenshot. It being empty (but not `null) is expected, since this event is called before the content item is updated with new data from POST. Due to this, it's also expected that you'll see some value (the old one, before the update) for an existing content item.
• You can add custom validation by injecting IUpdateModelAccessor in your handler, and adding model state errors to it in UpdatedAsync. Orchard Core Commerce has a lot of examples of this.

[MarGraz]

Thank you for your answer, as always 😊
Yes, I meant "Content Item". I have updated the previous post, thank you for noticing it.

• UpdatingAsync being called for the creation of a new content item sounds odd to me, because it's not an "update", but a "create" event 🤔
  When I checked the DefaultContentManager in the OC solution, I didn't find UpdateAsync being used in the NewAsync and CreateAsync methods. I'm using the OC NuGet package, so it is impossible for me to use breakpoints inside the DefaultContentManager (to do that, I would need to replicate the same module and content items in the local OC solution).

• Injecting IUpdateModelAccessor and using UpdatedAsync works 🥳
  It seems that using UpdatedAsync does the validation after the first save, and if the validation fails, the changes are reverted, right? If that is the case, I wouldn't have written to the database, to perform later a revert. This could save at least two database calls. However, given the architecture of OC, this was evidently the only way to do it (I'm curious).

Here is the updated code:

    public class CustomBagPartHandler : ContentPartHandler<BagPart>
    {
        private readonly IUpdateModelAccessor _updateModelAccessor;
        private readonly IContentDefinitionManager _contentDefinitionManager;
        private readonly IStringLocalizer<CustomBagPartHandler> S;

        public CustomBagPartHandler(
            IUpdateModelAccessor updateModelAccessor,
            IContentDefinitionManager contentDefinitionManager,
            IStringLocalizer<CustomBagPartHandler> stringLocalizer)
        {
            _updateModelAccessor = updateModelAccessor;
            _contentDefinitionManager = contentDefinitionManager;
            S = stringLocalizer;
        }

        public override async Task UpdatedAsync(UpdateContentContext context, BagPart part)
        {
            BagPartCustomSettingsList? settings = await GetSettingsAsync(part);

            // Ensure settings are correctly retrieved
            if (settings?.ContentTypeSettings != null)
            {
                foreach (BagPartCustomContentTypeSettings contentTypeSetting in settings.ContentTypeSettings)
                {
                    // Filter content items by the current content type setting
                    IEnumerable<ContentItem> contentItemsOfType = part.ContentItems.Where(ci => ci.ContentType == contentTypeSetting.ContentType);
                    int count = contentItemsOfType.Count();

                    // Validate against the min and max settings for this content type
                    // Allow the possibility to have Min and Max = 0
                    if (count < contentTypeSetting.MinItems || (contentTypeSetting.MaxItems > 0 && count > contentTypeSetting.MaxItems))
                    {
                        // Return error and revert changes
                        _updateModelAccessor.ModelUpdater.ModelState.AddModelError(nameof(CustomBagPartHandler), S["The number of {0} items in the bag must be between {1} and {2}. Current count: {3}. All changes will be ignored", contentTypeSetting.ContentType, contentTypeSetting.MinItems, contentTypeSetting.MaxItems, contentItemsOfType.Count()]);
                        return;
                    }
                }
            }
            await Task.CompletedTask;
        }

        #region Private methods

        private async Task<BagPartCustomSettingsList> GetSettingsAsync(BagPart part)
        {
            ContentTypeDefinition contentTypeDefinition = await _contentDefinitionManager.GetTypeDefinitionAsync(part.ContentItem.ContentType);
            ContentTypePartDefinition? contentTypePartDefinition = contentTypeDefinition?.Parts?.FirstOrDefault(x => string.Equals(x.PartDefinition.Name, nameof(BagPart), StringComparison.Ordinal));

            return contentTypePartDefinition?.GetSettings<BagPartCustomSettingsList>();
        }

        #endregion
    }

Thank you

[Piedone]

"Update" in this context means updating the content item object from the HTTP request. This happens for freshly created content items too.

Since OC uses SourceLink, you can actually step into it even with NuGet packages, and put breakpoints in OC code. You need to uncheck “Enable Just My Code” in VS for this to work.

Since updating the whole content item is usually a single query, at the end, canceling it in the middle from a handler doesn't cause anything excessive.

[MarGraz]

Thank you for the explanation 😊