Mvc: Razor Page base classes should have HttpContext property

[DamianEdwards]

The Razor Page base classes (for Page and PageModel) should have an HttpContext HttpContext { get; } property.

[pranavkm]

We have an HttpContext Context {get } property. Would this be an alias to it?

[DamianEdwards]

Not seeing it on PageModel. And we should call it HttpContext to match Controller I think.

[DamianEdwards]

Not seeing it on Page either...

[DamianEdwards]

Ah it's on RazorPageBase. So yeah, we should clean this up.

[rynowak]

Lots of the legacy MVC stuff wrt naming is not consistent and we intentionally continued that legacy instead of addressing it.. I believe I made RazorPages more consistent with views than with controllers.

[DamianEdwards]

Seems slightly strange to have the Context property be HttpContext rather than the more specific PageContext, maybe?

[rynowak]

Perhaps it's not useful, but I'm just mentioning the reason for the choice, not trying say it's the best 👍

[Eilon]

We need to make sure we have these properties available on Page and PageModel:

c# public class Page / PageModel { public HttpRequest Request { get; set; } public HttpResponse Response { get; set; } public HttpContext HttpContext { get; set; } public PageContext PageContext { get; set; } public ViewContext ViewContext { get; set; } }

[hishamco]

@Eilon why we need to add ViewContext while PageContext already inherit from it?

Can we add HttpContext in PageContext instead? so adding one property may enough in this case

[Eilon]

@hishamco ah that's a good point about ViewContext. @rynowak thoughts on these two questions?

[hishamco]

Also the Request' & 'Response will be accessible via the newly suggested property 'HttpContext`

[Eilon]

@hishamco we still provide convenience properties. It's nice to have a lot less .'s in the code, plus it makes code easier to copy & paste between various pages/controllers/views/etc.

[pranavkm]

Poaching this

[pranavkm]

@Eilon do we actually want these properties to be settable? I'm not super sure there's a lot of utility in that.

[hishamco]

IMHO it should be read only, because almost of them will get their values from the PageContext

[hishamco]

Waiting for @Eilon thoughts ..

[DamianEdwards]

I'd think we take our lead from ControllerBase

[pranavkm]

The closest context properties are settable so in this case it'll be PageContext. ViewContext is currently settable in Page due to it being part of an interface contract, I'm leaving that as is.
The remainder are gettable only. IUrlHelper is settable in ControllerBase, I'll make that change in my PR: https://github.com/aspnet/Mvc/pull/6034.

[Eilon]

I think they're usually settable for testing purposes, no?

[Eilon]

Or, at least, the main properties (e.g. "root" properties) are usually settable. The ones that just "dot" into them for convenience probably don't need to be settable.

[pranavkm]

Yup. Here's what we have:

```C#
public class Page
{
public PageContext PageContext { get; set; }
public ViewContext ViewContext { get; set; }
public ViewDataDictionary ViewData {get; }
public ModelStateDictionary ModelState {get; }
public HttpRequest Request { get; }
public HttpResponse Response { get; }
public HttpContext HttpContext { get; }
public ITempDataDictionary TempData { get; }

// Injected properties (codegened on generated types)
public IUrlHelper Url { get; set; }
public IHtmlHelper<T> Html { get; set; }

}

```C#
public class PageModel
{
    public PageContext PageContext { get; set; }
    public ViewContext ViewContext { get;  }
    public HttpRequest Request { get; }
    public HttpResponse Response { get; }
    public HttpContext HttpContext { get; }

    public ViewDataDictionary ViewData {get; }    
    public ModelStateDictionary ModelState {get; }
    public IUrlHelper Url { get; set; }
    public ITempDataDictionary TempData { get; }
}