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

* Allow null ViewData and TempData #3310

Merged
merged 1 commit into from
Oct 23, 2015
Merged

Conversation

ryanbrandenburg
Copy link
Contributor

If you're manually constructing a ViewResult you shouldn't have to pass in a ViewData and TempData just for us. This change allows them to be left null, the behavior on a resulting page being that references to ViewData just don't put anything out and references to TempData cause a 500.

@dnfclas
Copy link

dnfclas commented Oct 12, 2015

Hi @ryanbrandenburg, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.

TTYL, DNFBOT;

@@ -1,6 +1,7 @@
// Copyright (c) .NET Foundation. All rights reserved.
// Licensed under the Apache License, Version 2.0. See License.txt in the project root for license information.

using System;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This snuck in from another PR, I'll remove it when I rebase.

@ryanbrandenburg ryanbrandenburg force-pushed the rybrande/ViewResultNulls branch from 9067ce7 to b6ae7f3 Compare October 12, 2015 20:51
[Fact]
public async Task ExecuteResultAsync_ViewResultAllowNullViewDataAndTempData()
{
var context = GetActionContext();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we usually decorate tests with // Arrange, // Act and // Assert. Have a look at other tests in this class.

@Eilon
Copy link
Member

Eilon commented Oct 13, 2015

Aside from the small comments, :shipit:

Assert.Null(controller.ViewContext.TempData);
}

private class TestController
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move this test to ViewExecutorTest.cs. You shouldn't need a Controller to verify this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah that's actually a good point. Can just new up the type and call Execute from within the test.

@dougbu
Copy link
Member

dougbu commented Oct 14, 2015

@rynowak
Copy link
Member

rynowak commented Oct 14, 2015

I suppose it may very well be better to have dummy ViewData/TempData for those cases.

^^^ - was thinking the same thought earlier about this bug. There's too much stuff that will maybe read ViewData to give a consistent experience around reporting when it's null and not without just requiring ViewExector to create one if needed.

@ryanbrandenburg
Copy link
Contributor Author

Am I signed off then?

{
throw new ArgumentNullException(nameof(htmlHelperOptions));
tempData = new TempDataDictionary(new HttpContextAccessor(), new SessionStateTempDataProvider());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The HttpContextAccessor might need to point to the current ActionContext.HttpContext

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should be service-locating ITempDataDictionary and IModelMetadataProvider here - this isn't a unit-test-only scenario.

@ryanbrandenburg ryanbrandenburg force-pushed the rybrande/ViewResultNulls branch 3 times, most recently from a4f1507 to ca69d76 Compare October 16, 2015 17:26
@ryanbrandenburg
Copy link
Contributor Author

@rynowak Do those changes satisfy the dependency injection problems?

}
var service = actionContext.HttpContext.RequestServices;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

services

@ryanbrandenburg ryanbrandenburg force-pushed the rybrande/ViewResultNulls branch 2 times, most recently from bea9fea to 3e2ec3d Compare October 16, 2015 20:38
@ryanbrandenburg
Copy link
Contributor Author

@rynowak is that better?

{
throw new ArgumentNullException(nameof(htmlHelperOptions));
throw new ArgumentNullException(nameof(tempData));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Restore these null checks in their original order. That nicely matched the parameter order.

@dougbu
Copy link
Member

dougbu commented Oct 19, 2015

Wondering whether we should leave all but the main ViewContext constructor unchanged. That is, place the TempData and ViewData fallbacks in that constructor. May need minor ViewComponentResult and ViewExecutor updates to remove null checks. Then the fallback logic would then be in just one place.

@dougbu
Copy link
Member

dougbu commented Oct 19, 2015

public async Task ExecuteAsync_ViewResultAllowNull()
{
bool tempDataNull = false;
bool viewDataNull = false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

var

@rynowak
Copy link
Member

rynowak commented Oct 19, 2015

@ryanbrandenburg
Copy link
Contributor Author

Doug, about consolidating into the ViewContext, @rynowak is of the opinion, and he convinced me, that contexts should be dumb bags of objects that don't have any logic in them. Your suggestion would certainly simplify things a bit, but at the expense of having the Context violate its dumbness.

@ryanbrandenburg
Copy link
Contributor Author

I believe I've addressed everything now, is there a ship it?

@rynowak
Copy link
Member

rynowak commented Oct 20, 2015

:shipit:

@@ -6,6 +6,7 @@
using Microsoft.AspNet.Mvc.ModelBinding;
using Microsoft.AspNet.Mvc.ViewEngines;
using Microsoft.AspNet.Mvc.ViewFeatures;
using Microsoft.Extensions.DependencyInjection;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor but you don't need this anymore. That is, revert everything in this file.

@dougbu
Copy link
Member

dougbu commented Oct 20, 2015

:shipit: once the CI builds start working. Problem looks like something propagating through our builds and not at Coherence yet. But it could hide something real.

C:\projects\mvc\test\WebSites\FiltersWebSite\Controllers\AuthorizeUserController.cs(31,10): DNX,Version=v4.5.1 error CS0104: 'AllowAnonymous' is an ambiguous reference between 'Microsoft.AspNet.Mvc.AllowAnonymousAttribute' and 'Microsoft.AspNet.Authorization.AllowAnonymousAttribute'

@ryanbrandenburg ryanbrandenburg force-pushed the rybrande/ViewResultNulls branch 6 times, most recently from f94ae7f to 8565b2f Compare October 23, 2015 00:11
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants