We ran into some issues with the existing model for setting the static event handlers like GriddlySettings.GlobalBeforeRender. What happened was:
1) We were setting it to an async handler in the Startup class (which is the natural place to hook it up)
2) The Startup code is run on the primary thread.
3) Therefore, when an exception occurred in the handler, it was unhandled and crashed the entire site
4) This caused the app pool in IIS to restart
This is a classic example of the problems with statics and especially async static functions.
So this PR is a rewrite of the static defaults into a request-scoped class. Changes made:
1) You hook up griddly services by calling services.AddGriddly<TMyConfigClass>() in ConfigureServices()
2) Since the IGriddlyConfigis scoped, it can have a constructor accepting IHttpContextAccessor which allows it to get the HttpContext without needing to be passed in to each event handler.
3) services.AddGriddly() adds the GriddlyHttpContextAccessor and ActionContextAccessor so this no longer has to be done manually.
4) Added a GriddlyOptions class which is a stub allowing the (safe) static default properties to be set in a more conventional way. This is an optional parameter of services.AddGriddly()
5) Made all templates be asynchronous (return Task<IHtmlContent>) and accept an IHtmlHelper parameter so they can support a handler which returns await Html.PartialAsync(...), that being the preferred way to render views.
6) Implemented FilterModalHeaderTemplate and FilterModalFooterTemplate in the .NET Core view as this had been apparently neglected when these properties were added.
7) Some methods (e.g. IsCookiesDisabled()) may no longer need to accept an HttpContext since they are now on a class that's request-scoped. However, I didn't remove them (in the NetFX implementation) to avoid breaking changes.
Soliciting feedback/suggestions on this approach/implementation.
We ran into some issues with the existing model for setting the static event handlers like
GriddlySettings.GlobalBeforeRender. What happened was: 1) We were setting it to an async handler in the Startup class (which is the natural place to hook it up) 2) The Startup code is run on the primary thread. 3) Therefore, when an exception occurred in the handler, it was unhandled and crashed the entire site 4) This caused the app pool in IIS to restartThis is a classic example of the problems with statics and especially async static functions.
So this PR is a rewrite of the static defaults into a request-scoped class. Changes made:
1) You hook up griddly services by calling
services.AddGriddly<TMyConfigClass>()inConfigureServices()2) Since theIGriddlyConfigis scoped, it can have a constructor acceptingIHttpContextAccessorwhich allows it to get theHttpContextwithout needing to be passed in to each event handler. 3)services.AddGriddly()adds theGriddlyHttpContextAccessorandActionContextAccessorso this no longer has to be done manually. 4) Added aGriddlyOptionsclass which is a stub allowing the (safe) static default properties to be set in a more conventional way. This is an optional parameter ofservices.AddGriddly()5) Made all templates be asynchronous (returnTask<IHtmlContent>) and accept anIHtmlHelperparameter so they can support a handler which returnsawait Html.PartialAsync(...), that being the preferred way to render views. 6) ImplementedFilterModalHeaderTemplateandFilterModalFooterTemplatein the .NET Core view as this had been apparently neglected when these properties were added. 7) Some methods (e.g.IsCookiesDisabled()) may no longer need to accept anHttpContextsince they are now on a class that's request-scoped. However, I didn't remove them (in the NetFX implementation) to avoid breaking changes.Soliciting feedback/suggestions on this approach/implementation.