This repository has been archived by the owner on Dec 8, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 111
Use a builder pattern for configuring options in UseDatabaseErrorPage #184
Comments
Just discussed another option with @Tratcher that both of us like: Instead of passing in a particular type, the app.UseDatabaseErrorPage(options => {
options.ShowExceptionDetails = true;
options.ListMigrations = true;
}); Or if that's too verbose, could add a helper: app.UseDatabaseErrorPage(options => {
options.EnableAll(); // just sets all the properties to true
}); This would be even more inline with how other middleware works, as seen here: https://github.com/aspnet/MusicStore/blob/dev/src/MusicStore/Startup.cs#L161-L218 |
@rynowak FYI |
Agreed on the builder pattern. I working on #190 at the moment so I will enable this pattern at the same time. |
@rowanmiller cool. |
rowanmiller
added a commit
that referenced
this issue
Oct 19, 2015
Mostly just a revert of the commit that removed this functionality, with a few changes: * Perform proper JavaScript encoding in the script part of the database error page Views/BaseView.cs * Use the builder pattern in the UseXyz extension methods on IApplicationBuilder (per #184). Also applying this to DatabaseErrorPageOptions to keep things consistent. * Fixing a few tests that were getting the context from DI but putting it in a using block so that it got disposed (rather than letting DI handle disposing).
rowanmiller
added a commit
that referenced
this issue
Oct 19, 2015
Mostly just a revert of the commit that removed this functionality, with a few changes: * Perform proper JavaScript encoding in the script part of the database error page Views/BaseView.cs * Use the builder pattern in the UseXyz extension methods on IApplicationBuilder (per #184). Also applying this to DatabaseErrorPageOptions to keep things consistent. * Fixing a few tests that were getting the context from DI but putting it in a using block so that it got disposed (rather than letting DI handle disposing).
rowanmiller
added a commit
that referenced
this issue
Oct 19, 2015
Mostly just a revert of the commit that removed this functionality, with a few changes: * Perform proper JavaScript encoding in the script part of the database error page Views/BaseView.cs * Use the builder pattern in the UseXyz extension methods on IApplicationBuilder (per #184). Also applying this to DatabaseErrorPageOptions to keep things consistent. * Fixing a few tests that were getting the context from DI but putting it in a using block so that it got disposed (rather than letting DI handle disposing).
rowanmiller
added a commit
that referenced
this issue
Oct 20, 2015
Mostly just a revert of the commit that removed this functionality, with a few changes: * Perform proper JavaScript encoding in the script part of the database error page Views/BaseView.cs * Use the builder pattern in the UseXyz extension methods on IApplicationBuilder (per #184). Also applying this to DatabaseErrorPageOptions to keep things consistent. * Fixing a few tests that were getting the context from DI but putting it in a using block so that it got disposed (rather than letting DI handle disposing).
Fixed in 1c26436 |
rowanmiller
changed the title
Consider moving DatabaseErrorPageOptions to Microsoft.AspNet.Builder namespace
Use a builder pattern for configuring options in UseDatabaseErrorPage
Oct 21, 2015
rowanmiller
added a commit
to aspnet/Templates
that referenced
this issue
Oct 21, 2015
The overload being used in the templates has swapped to a builder pattern (see aspnet/Diagnostics#184). But rather than updating to the new signature, just swapping to the parameterless overload since it enables everything by default (same as UseDeveloperExceptionPage()).
rowanmiller
added a commit
to aspnet/MusicStore
that referenced
this issue
Oct 21, 2015
The overload being used in the Startup.cs has swapped to a builder pattern (see aspnet/Diagnostics#184). But rather than updating to the new signature, just swapping to the parameterless overload since it enables everything by default (same as UseDeveloperExceptionPage()).
@rowanmiller remember to mark completed bugs as |
rowanmiller
added a commit
to aspnet/MusicStore
that referenced
this issue
Oct 21, 2015
The overload being used in the Startup.cs has swapped to a builder pattern (see aspnet/Diagnostics#184). But rather than updating to the new signature, just swapping to the parameterless overload since it enables everything by default (same as UseDeveloperExceptionPage()).
@Eilon done... I mean |
rowanmiller
added a commit
to aspnet/Templates
that referenced
this issue
Oct 21, 2015
The overload being used in the templates has swapped to a builder pattern (see aspnet/Diagnostics#184). But rather than updating to the new signature, just swapping to the parameterless overload since it enables everything by default (same as UseDeveloperExceptionPage()).
rowanmiller
added a commit
to aspnet/MusicStore
that referenced
this issue
Oct 21, 2015
Some more calls that I missed in my previous commit. The overload being used in the templates has swapped to a builder pattern (see aspnet/Diagnostics#184). But rather than updating to the new signature, just swapping to the parameterless overload since it enables everything by default (same as UseDeveloperExceptionPage()).
|
rowanmiller
added a commit
to aspnet/Templates
that referenced
this issue
Oct 21, 2015
The overload being used in the templates has swapped to a builder pattern (see aspnet/Diagnostics#184). But rather than updating to the new signature, just swapping to the parameterless overload since it enables everything by default (same as UseDeveloperExceptionPage()).
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
There's a general pattern where types that are used only for configuring middleware also end up in the
Microsoft.AspNet.Builder
namespace, alongside the variousapp.UseXyz(...)
extension methods.The
DatabaseErrorPageOptions
is used only in middleware setup (and effectively internally elsewhere), so it should move to theMicrosoft.AspNet.Builder
namespace.The end result is that fewer namespaces need to be imported in a typical
Startup.cs
file.The text was updated successfully, but these errors were encountered: