Skip to content
This repository has been archived by the owner on Dec 8, 2018. It is now read-only.

Use a builder pattern for configuring options in UseDatabaseErrorPage #184

Closed
Eilon opened this issue Oct 2, 2015 · 8 comments
Closed

Comments

@Eilon
Copy link
Member

Eilon commented Oct 2, 2015

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 various app.UseXyz(...) extension methods.

The DatabaseErrorPageOptions is used only in middleware setup (and effectively internally elsewhere), so it should move to the Microsoft.AspNet.Builder namespace.

The end result is that fewer namespaces need to be imported in a typical Startup.cs file.

@Eilon
Copy link
Member Author

Eilon commented Oct 2, 2015

Just discussed another option with @Tratcher that both of us like:

Instead of passing in a particular type, the UseXyz() method to add the middleware could use a builder pattern and take in options that are configured inline, removing the need to reference any type by name at all, e.g.:

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

@Eilon
Copy link
Member Author

Eilon commented Oct 2, 2015

@rynowak FYI

@rowanmiller rowanmiller added this to the 1.0.0-rc1 milestone Oct 5, 2015
@rowanmiller rowanmiller self-assigned this Oct 5, 2015
@rowanmiller
Copy link
Contributor

Agreed on the builder pattern. I working on #190 at the moment so I will enable this pattern at the same time.

@Eilon
Copy link
Member Author

Eilon commented Oct 17, 2015

@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).
@rowanmiller
Copy link
Contributor

Fixed in 1c26436

@rowanmiller 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()).
@Eilon
Copy link
Member Author

Eilon commented Oct 21, 2015

@rowanmiller remember to mark completed bugs as 3 - Done.

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
Copy link
Contributor

@Eilon done... I mean 3 - Done

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()).
@Eilon
Copy link
Member Author

Eilon commented Oct 21, 2015

4 - Thanks!

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.
Projects
None yet
Development

No branches or pull requests

2 participants