ModelPreparedEvent is called after the View starts processing!?

nopCommerce 460.4
The view \Checkout\OpcShippingAddress.cshtml has model CheckoutShippingAddressModel
The breakpoint I placed at the top of the View (.cshtml):

@model CheckoutShippingAddressModel

<div class="checkout-data">
    @if (Model.DisplayPickupInStore && Model.PickupPointsModel.AllowPickupInStore)

gets hit after the breakpoint I put at the bottom of

   public virtual async Task<CheckoutShippingAddressModel> PrepareShippingAddressModelAsync(...

  
but before the breakpoint I set at the top of my plugin's

   public async Task HandleEventAsync(ModelPreparedEvent<BaseNopModel> eventMessage)

My understanding is that the ModelPreparedEvent event handler should be executed first during the model preparation phase before the view rendering process.
What am I doing wrong?


(The ModelPreparedEvent 'examples' in the core source only deal with navigationModel.)

You're right, the event handler should be executed first during the model preparation phase before the view rendering process.
And it works exactly like this in a normal MVC request life cycle. But we have one case where we intervene in this cycle. When one-page checkout is used, we render the view before the action completes and the events are published.
I assume you're using this type of checkout process, so the breakpoint on the view gets hit before your handler.

To fix this, you need to copy this code from the NopViewComponent into RenderPartialViewToString method.

I also created a work item for this, but perhaps we'll leave it just for customization.

I didn't think to try seeing if it would work with regular (multi-page) checkout, but I will.  Although I need it to work for both, since I want to create a plugin for clients that could choose either.  For that same reason, I can't "fix it" by modifying core code (RenderPartialViewToStringAsync).  I'll probably instead override the Prepare...Model method.  (Although it's my preference to handle the event rather than override a method, since others might also override that method :(

done, please see this commit for more details

Thank you.  I will look into it shortly.