aspnet / Mvc

[Archived] ASP.NET Core MVC is a model view controller framework for building dynamic web sites with clean separation of concerns, including the merged MVC, Web API, and Web Pages w/ Razor. Project moved to https://github.com/aspnet/AspNetCore
Apache License 2.0
5.62k stars 2.14k forks source link

Razor Pages #494

Closed NTaylorMullen closed 7 years ago

NTaylorMullen commented 10 years ago

We will support a simple model where a user can crate a CSHTML page that can handle requests but still use the primitives of MVC.

| 57 | 10153 | Reported By: Yishai Galatzer |

DamianEdwards commented 8 years ago

Goals

We are trying to:

Non-goals

We are not trying to:

Enabling

Packaging

The "MVC View Pages" feature will ship in a standalone package, e.g. Microsoft.AspNetCore.Mvc.Razor.ViewPages, that will be referenced by the MVC meta-package, Microsoft.AspNetCore.Mvc. Users of the lower-level Microsoft.AspNetCore.Mvc.Core package can bring in the MVC Pages package to enable it without using the meta-package.

Startup

The IServiceCollection.AddMvc() and IApplicationBuilder.UseMvc() extension methods will enable MVC Pages by default. There will be appropriate extension methods to enable MVC Pages explicitly in the cases where these extensions methods are not used, e.g. when using IServiceCollection.AddMvcCore().

@page directive

MVC pages are represented by CSHTML files that use the new @page directive. This directive instructs the MVC Razor host to treat the CSHTML file as a standalone page for the purposes of request handling.

e.g.

@page
Hello, World! It's @DateTime.Now on the server

@class block directive

MVC pages can add members to the generated class using the new @class block directive. This directive is effectively an alias of the existing @functions directive. All members added to the class are available to the page during request processing.

Page Actions

Public methods added to the page class in the @class block are candidates for handling request processing, much like action methods on MVC controllers. Methods that match the selection rules become Page Actions, and one (or none) will be selected as the handling Page Action for any given request to the page.

Action Selection

Action selection is based on simple HTTP verb name matching, with support for the prefix On, e.g.: GET requests will match methods called Get or OnGet, POST requests will match methods called Post or OnPost.

Situations that result in more than one action matching are an error should throw an exception (like an ambiguous action selection error in a controller).

If no actions are matched, the page will simply render.

Action Results

Page Actions must return an IActionResult. Typically this will be a ViewResult that renders the current page, e.g. return View();, but any IActionResult is supported. This allows pages to return non-HTML results, e.g. 404 not found, or even JSON or other formats if so desired.

e.g.:

@page
@class {
    public IActionResult OnGet()
    {
        return View();
    }
}
Hello, World!

Parameter Binding

Parameters of Page Actions will be populated using model-binding, just like action methods are in MVC controllers. As such, it will support binding of simple and complex types from the registered value providers, e.g. query string, form, cookie, route data, etc., and model-binders.

e.g.:

@page
@class {
    public IActionResult OnGet(int? id)
    {
        if (id.HasValue && id < 0)
        {
            return NotFound();
        }
        return View();
    }
}
Found!

Properties & Helper Methods

Members in the @class block are available to the page during execution of the page action and during rendering, making it easy to pass data between the two stages.

e.g.

@page
@class {
    public IActionResult OnGet(int? id)
    {
        if (id.HasValue && id < 0)
        {
            return NotFound();
        }
        Id = id;
        return View();
    }

    public int? Id { get; set; }
}
Id = @Id

@model directive

The @model directive can be used to declare the model type for the page. It will generate a Model property on the page class of the declared type, as well as using the model type as the generic type argument for the IHtmlHelper<T> instance available to the page.

@page
@model Customer
@class {
    public IActionResult OnGet(int? id)
    {
        if (id.HasValue && id < 0)
        {
            return NotFound();
        }
        var model = new Customer { Id = id, FirstName = "Jane", LastName = "Smith" };
        return View(model);
    }
}
Customer: @Model.FirstName @Model.LastName

Inline View Models using @model & @class

Unlike on views, the @model directive will not change the base type of the generated page class to a generic variant. This is to allow the page the ability to declare nested classes in its @class block and use those as the model type with @model.

e.g.

@page
@model ViewModel
@class {
    public IActionResult OnGet(int? id)
    {
        return id.HasValue && id < 0
            ? NotFound()
            : View(new ViewModel {
                Customer = new Customer {
                    Id = id,
                    FirstName = "Jane",
                    LastName = "Smith"
                }
        });
    }

    public class ViewModel
    {
        public Customer Customer { get; set; }
    }
}
Customer: @Model.Customer.FirstName @Model.Customer.LastName

Code-behind class

IDEA: Class of same-name as page file will be automatically used as base type, not sure if this is a good idea, could be hard to make work in expected way reliably.

@inherits directive

The @inherits directive can be used to change the type that the generated page class will derive from. The type specified can be a POCO, or derive from the page base type in MVC (TBD). This way, code can be separated from the CSHTML file and placed in a CS file that it is compiled with the application (rather than as part of the CSHTML compilation process, either at runtime or as part of view pre-compilation).

In the case the base type is a POCO, the existing contextualizing attributes can be placed on properties of the appropriate types to gain access to relevant context objects from MVC, i.e. they will be set to the current instances during page activation, e.g. [HttpContext]. (We might possibly end up with some new context types, e.g. PageContext, in order to make the members appropriate for pages)

e.g.

public class MyPage : Page
{
    public IActionResult OnGet(int? id)
    {
        Id = id;
        return View();
    }

    public int? Id { get; set; }
}
@page
@inherits MyPage
Id was @Id

@inject directive

Yeah, you can use the @inject directive to generate properties that have instances injected from the DI container, just like in views., e.g. @inject AppDbContext Db

@{ } code blocks

They work just like they do in views and run as part of page rendering.

Page URLs

The path to the page file from the configured pages root path (defaults to IHostingEnvironment.ContentRootPath), including the file name, but excluding the file extension, becomes the URL that the page will be served in response to. Pages with a file name of "Index.cshtml" will also act as the default page for the sub-path (folder) they are in, e.g.:

Page Path URL
/Foo.cshtml /foo
/Foo/Bar.cshtml /foo/bar
/Index.cshtml /index
/Index.cshtml /
/Foo/Index.cshtml /foo/

Explicit routing using conventional routes

TODO: routeBuilder.MapPageRoute("customers/{id}", "Customer.cshtml")

Explicit routing using attribute routes

TODO: Using attribute routes on the base class when using @inherits

Anti-forgery (CSRF protection)

TODO

Examples

Hello World

Project Structure

Index.cshtml
Program.cs
project.json

Program.cs

using System.IO;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;

namespace HelloWorld
{
    public static class Program
    {
        public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .SetContentRoot(Directory.GetCurrentDirectory())
                .UseKestrel()
                .UseStartup<Startup>()
                .Build();

            host.Run();
        }

        public class Startup
        {
            public void ConfigureServices(IServiceCollection services) => services.AddMvcPages();
            public void Configure(IApplicationBuilder app) => app.UseMvcPages();
        }
    }
}

Index.cshtml

@page
Hello, World! It's @DateTime.Now

Single-page CRUD

Project Structure

Data/
    AppDbContext.cs
    Customer.cs
wwwroot/
    [static files]
_Layout.cshtml
_ValidationScripts.cshtml
appsettings.json
Customers.cshtml
Program.cs
project.json
Startup.cs

Program.cs

using System.IO;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;

namespace HelloWorld
{
    public static class Program
    {
        public static void Main(string[] args)
        {
            var host = new WebHostBuilder()
                .SetContentRoot(Directory.GetCurrentDirectory())
                .UseKestrel()
                .UseStartup<Startup>()
                .Build();

            host.Run();
        }

        public class Startup
        {
            public Startup(IHostingEnvironment env)
            {
                var builder = new ConfigurationBuilder()
                    .SetBasePath(env.ContentRootPath)
                    .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);
                Configuration = builder.Build();
            }

            public IConfigurationRoot Configuration { get; }

            public void ConfigureServices(IServiceCollection services)
            {
                services.AddDbContext<AppDbContext>(options =>
                    options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

                services.AddMvcPages();
            }

            public void Configure(IApplicationBuilder app)
            {
                app.UseStaticFiles();
                app.UseMvcPages();
            }
        }
    }
}

Data/Customer.cs

namespace MyApp.Data
{
    public class Customer
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string DateTimeOffset BirthDate { get; set; }
        public string FavoriteDrink { get; set; }
    }
}

Data/AppDbContext.cs

namespace MyApp.Data
{
    public class AppDbContext : DbContext
    {
        public AppDbContext(DbContextOptions<AppDbContext> options)
            : base(options)
        {

        }

        public DbSet<Customer> Customers { get; set; }
    }
}

Customers.cshtml

@page
@using MyApp.Data
@model ViewModel
@inject AppDbContext Db
@class {
    public IActionResult OnGet(int? id)
    {
        var customer = id.HasValue ? await Db.Customers.SingleOrDefaultAsync(c => c.Id == id) : (Customer)null;
        return id.HasValue && customer == null ?
            NotFound() :
            View(new ViewModel {
                Customer = customer,
                Title = customer != null ? $"Edit Customer {customer?.Id}" : "New Customer"
            });
    }

    public IActionResult OnPost(ViewModel model)
    {
        if (!ModelState.IsValid())
        {
            // Model errors, just return the view to show them the errors
            model.Title = "Edit Customer";
            return View(model);
        }

        if (!model.Customer.Id.HasValue)
        {
            // Create
            Db.Customers.Add(model.Customer);
            ViewModel.AlertMessage = $"New customer {model.Customer.Id} created successfully!";
        }
        else
        {
            // Update
            Db.Attach(model.Customer, EntityState.Changed);
            ViewModel.AlertMessage = $"Customer {model.Customer.Id} updated successfully!";
        }

        await Db.SaveChangesAsync();

        return Reload(new { id = model.Customer.Id });
    }

    public class ViewModel
    {
        public string Title { get; set; }
        public string AlertMessage
        {
          get { return TempData[nameof(AlertMessage)]; }
          set { TempData[nameof(AlertMessage)] = value; }
        }
        public bool ShowAlertMessage => !string.IsNullOrEmpty(AlertMessage);
        public Customer Customer { get; set; }
        public bool ShowAdultOnlyThings => (DateTimeOffset.UtcNow - Customer.BirthDate).TotalYears >= 21;
    }
}
@{
    Layout = "_Layout.cshtml";
    ViewData["Title"] = Model.Title;
}

<form method="post" role="form">
    @if (Model.ShowAlertMessage)
    {
        <div class="alert alert-dismissible" role="alert">
            <button type="button" class="close" data-dismiss="alert" aria-label="Close"><span aria-hidden="true">&times;</span></button>
            @Model.AlertMessage
        </div>
    }
    <div asp-validation-summary="All" class="text-danger"></div>
    <div class="form-group">
        <label asp-for="Model.Customer.FirstName"></label>
        <input asp-for="Model.Customer.FirstName" class="form-control" />
        <span asp-validation-for="Model.Customer.FirstName" class="help-block text-danger"></span>
    </div>
    <div class="form-group">
        <label asp-for="Model.Customer.LastName"></label>
        <input asp-for="Model.Customer.LastName" class="form-control" />
        <span asp-validation-for="Model.Customer.LastName" class="help-block text-danger"></span>
    </div>
    <div class="form-group">
        <label asp-for="Model.Customer.BirthDate"></label>
        <input asp-for="Model.Customer.BirthDate" class="form-control" />
        <span asp-validation-for="Model.Customer.BirthDate" class="help-block text-danger"></span>
    </div>
    @if (Model.ShowAdultStuff)
    {
    <div class="form-group">
        <label asp-for="Model.Customer.FavoriteDrink"></label>
        <input asp-for="Model.Customer.FavoriteDrink" class="form-control" />
        <span asp-validation-for="Model.Customer.FavoriteDrink" class="help-block text-danger"></span>
    </div>
    }
    <button type="submit" class="btn btn-primary">Save</button>
</form>

@section "Scripts" {
    <partial name="_ValidationScripts" />
}
mikebrind commented 8 years ago

Action selection: Wouldn't it make more sense to use attributes here rather than verb name matching? It's an easy enough concept to grok and will facilitate migration to MVC.

ctyar commented 8 years ago

Sorry I know this is not productive but this sample

@page
@class {
    public IActionResult OnGet()
    {
        return View();
    }
}
Hello, World!

reminds me of php's dark ages

<?php
include("../../externs/includes/connexio.php");

$result = mysqli_query($con, "SELECT * FROM myTable");

while ($row = mysqli_fetch_array($result)) {
    $id = $row["id"];
    $title = $row["title"];
    $subtitle = $row["subtitle"];
?>  

<div class="title" id="<?php echo $id; ?>"><?php echo $title; ?> </div>
<div class="subtitle"><?php echo $subtitle;?> </div>
<br>

<?php 
}
?>
DamianEdwards commented 8 years ago

@mikebrind the verb attributes will be supported when using @inherits to place the page actions in a CS file. Supporting them in the CSHTML creates issues around lifecycle and route discovery that we'd rather not tackle in this release.

We could create new attributes for this purpose, but we're trying to limit the number of new constructs we create, especially when they are similar to those that already exist in MVC.

For now, we plan to keep the pattern-based selection for page actions in CSHTML, and attribute routing when they're in CS.

mikebrind commented 8 years ago

@DamianEdwards That makes sense. I agree that it's a good idea not to create twins of existing MVC artefacts that actually differ in implementation.

mikebrind commented 8 years ago

Appreciate it is just an idea at this stage, but what kind of problems would the "code-behind" (page controller) feature attempt to solve?

rynowak commented 8 years ago

@mikebrind - the code-behind is part of your app and instantiable/unit-testable

mikebrind commented 8 years ago

@rynowak If people want to unit test their app, shouldn't they be looking towards MVC instead?

rynowak commented 8 years ago

If people want to unit test their app, shouldn't they be looking towards MVC instead?

We want to provide a few more in steps in between what MVC can do today and a simplest possible solution. It wouldn't be good if the choice is binary - either you get Controllers all the goodness - or you get just Razor.

I also expect that the the code-behind might become the place to put a lot of the code that goes into a view model today, which usually gets unit tested.

Also, it's just some folks preference that c# goes in .cs files. That's totally cool, we want to provide a few more options.

sqmgh commented 8 years ago

It feels to me like this is going to end up causing confusion and ambiguity for people who are trying to get into the space.

If someone is searching for guides or answers using a search engine, or something like StackOverflow you already run into problems with conflicting versions. Unless you're careful you get old incompatible versions of MVC, and unless you are very careful you get examples from the betas which are also not compatible. That's not so bad though, because at least those won't compile, and can be explained away with "It's an old version". However, this is going to be adding another set of examples which will show up while searching for 'aspnet' that will work just fine. I can very easily see people who aren't sure what they are doing creating confusing Frankencode projects by stitching together things that 'work', and having it quickly become very hard to maintain. Which could quite possibly reflect poorly on the whole experience.

I'm not saying the idea is necessarily a bad one, but you need to be very careful with the branding. Noting that having 'Web Pages' work (though I acknowledge it could just be this one issue) being done in the MVC repository doesn't feel like it's off to a great start.

mikebrind commented 8 years ago

@rynowak I thought this framework was aimed at beginners to ASP.NET development. It seems from what you are saying that the intended audience is far wider than that. My feeling is that the typical Web Pages user will feel overwhelmed with concepts like view models, code-behind, unit testing etc, and just go to PHP instead. I also feel that people who are concerned about those things will see no benefit in using Razor Pages when they can get those them from MVC.

DamianEdwards commented 8 years ago

@mikebrind this isn't intended at being a feature set just for beginners. It's intended for use in page-focused MVC scenarios where the actions are performing very basic operations, sometimes doing nothing but returning a view result via View(), or doing basic CRUD focused form handling. In those cases, it can be nice to not require the normal structure usually imposed by MVC, including the controller and views folders.

As always, if one doesn't see value, one doesn't have to use it. The files must be opted in to this model on purpose (via @page) so that there isn't cross-over between views and pages without explicit intent.

DamianEdwards commented 8 years ago

@sqmgh the issue of naming is a valid one and indeed we'll consider different names with a view to mitigating as much confusion with existing features from our previous versions. That's easier said than done of course, but we'll try.

DamianEdwards commented 8 years ago

Updated the outline above with some examples and other bits.

JohnMuller44 commented 8 years ago

I completely agree with mikebrind.

What is very important to mention at this point is that ASP.NET Web Pages is one of the best products Microsoft ever has created. As we all know, it is a Framework to build powerful Websites in a very easy way.

I was personally involved into a Project where an Enterprise ERP has been designed with the modules Accounting, Shipping, Purchasing, Import/Export etc. by using Web Pages. With MVC, this would not have been possible because MVC is very difficult and cumbersome to develop and maintain. With MVC, it would have taken much longer to develop the system, ultimatively driving up the cost.

From what I read on this page, the current Version of Web Pages is not given enough credit, especially when we consider it's popularity. With that in mind, it's currently the time to seriously think about what the future of Web Pages is.

Best thing from my personal perspective would be to create a Web Pages Version 4.0, basically an enhanced Version of the existing Web Pages 3.2.3. A version which is NOT related to MVC in any way, as mikebrind already pointed out, the typical Web Pages user might not want to get in touch with the MVC concept.

mikebrind commented 8 years ago

@JohnMuller44 I don't think I share your view. It seems from what @DamianEdwards and @rynowak have said that the "advanced" features like code behind are not intended for everyone to use. They will be opt-in, and most likely the default experience for Razor Pages users will be something similar to the one that Web Pages users have at the moment. A lot of course will depend on tooling and packaging, but you could either choose to use code-blocks for a page at the top of your cshtml file, or put that logic in a separate file. This is how Web Forms started out. The tooling gave you the option to add a code-behind originally.

There won't be any MVC artefacts getting in the way, despite the fact that this framework sits on top of MVC. There are quite a lot of (very useful) ideas that borrow from the current MVC framework, but they will only be possible because the new Razor Pages will have access to them as result of the way that it will sit together.

sqmgh commented 8 years ago

@mikebrind From what's I've read in this issue, it doesn't seem like it will even slightly close to what Web Page users have at the moment.

When most people say "it's easier to develop and maintain" they are referring to ViewState. They just want their webpage to function like a Forms application. They DO NOT want to have to worry about Models, or Model binding. I would wager that many would be happier if they never had to deal with or see Javascript. They want the whole stateless internet part abstracted away for them. Until that happens you're going to have people complaining that there is no proper WebPages update. There are users you will simply not win over.

Of course the arguments for actually doing this have never seemed particularly strong for me. Yes, assuming you are trying to do something simple and you come from a Forms background the learning curve is smaller, and it's faster to develop. However, the moment you start to do something complicated you start fighting the framework, and it becomes waaaaay more complicated and time consuming. Performance suffers greatly, and maintenance also becomes much, much harder. Personally, I was happy when I was afforded the opportunity to move away from it in one of the major projects I maintain. Due to cruft people had added over the years, it was getting out of hand.

The whole situation reminds me of the VB6 "problem", I guess. Microsoft created a very easy to use product that got a bunch of people into a new space not available to them before. Then for legitimate reasons Microsoft moved on from that product. Many of the users who came for the ease of use became stranded for whatever reason. Whether it be their toolchain, or technical debt. "Why change what isn't broken." Of course, this ends up with a situation where you have a bunch of vocal users upset that they have been left behind, and are not getting the latest new features.

mikebrind commented 8 years ago

@sqmgh Granted, the contents of the customer,cshtml file above don't look much like the existing Web Pages incarnation, but it looks like most of the features that it illustrates are opt-in. I'm pretty sure, based on what's been posted so far, that if I were to rewrite my Web Pages book to cover .NET Core's version, the majority of it would not have to change - especially if WebMatrix.Data is ported over to Core.

The book would benefit from a few more chapters, in all fairness, but I would put those in section 2 of the book, labelled "Advanced".

JohnMuller44 commented 8 years ago

Let's take the casual, basic type web developer. What he typically can do is some HTML, CSS and Javascript. What she can also typically do is declare variables in Razor, make database queries with db.query, db.querysingle, db.queryvalue. She can also execute SQL Statements by using db.execute. After some time reading into it, she also might add Security and Membership to the site.

What this basic, casual Web Developer typically does not know is:

That's why I'm not sure this customer would actually use ASP.NET Core, probably not, except if as @mikebrind pointed out, the majority of the Web pages functionality is available AND the exposure to those advanced development topics is kept at an absolute minimum

DamianEdwards commented 8 years ago

As it was stated in the goals above, we're explicitly not trying to create a script-life page framework that hides or works around lots of the C# constructs. That's Web Pages attempted to do, and is not what this is. This is more about removing unnecessary ceremony from building page-focused apps using MVC. This is still very much ASP.NET Core and C# and there is no scope to build something new.

mikebrind commented 8 years ago

@DamianEdwards I'm sorry for being thick, but just for clarification, this feature is NOT the "Web Pages" in the roadmap, despite the original title of the issue, right? So the Web Pages in the roadmap is something else? Has been dropped? Been replaced with this feature?

andrewlock commented 8 years ago

@DamianEdwards this looks interesting. We used the previous version of WebPages for a simple content focused web site previously, and it worked pretty well for us.

One of the reasons we settled on WebPages was that we had some junior front end developer/designers working on it who we didn't want to have to get their head around MVC, or even too far into C#. From that point of view, the tag-helpers would have been great as the Razor syntax was always a burden.

Similar to this, I'm very glad the plan is to just be using the standard validation helpers etc instead of the WebPages specific ones in the previous version - trying to remember the completely different syntax and usage was always a bit of a nightmare. Only downside to that I guess is I expect upgrading will be relatively painful.

For our use case, what you have outlined seems like a great compromise. For the majority of cases, a page will needs pretty much no C#, which will be nice and editor friendly for those not using Visual Studio and for more complex pages you have the @class/@inherits fallback to work with. I do wonder if @class is necessary when you have @inherits - it feels like it goes back to the previous problem of large amounts of C# in what is otherwise a pretty much pure html page.

AbubakarIdris commented 8 years ago

If these are the new ideas you the ASP.NET Team is trying to introduce into the Webpages model, then I'm not upgrading to any version greater that 3.0. Why? It seems the team is trying to focus much on the "enterprise" developers who use MVC. It's not really a bad thing for Microsoft. But it's bad for the lot of us who just need something straight forward, but still powerful. The current version of the model is extremely effective, best part is the use of pure csharp code in the App Code folder to do a host of tasks. It's simply amazing. I think the reason why the team is introducing these ideas is probably because they've ran out of ideas. They want to keep Razor, but want to make it better, but don't know how to. My first advise is this: get the guy who came up with the concept of the webpages model and put him back on the team. Second, bring the discussion to the ASP.NET Webpages forum on forums.asp.net. That's the only place to get to know how the true users of the model are actually using it. But don't trust their advise, since most are beginners, they won't be able to state what they mean in clear terms. Third, like it or not, the model is closer to rivalling PHP (yes, like it or not that's how you should think). The reason is simple: this is where the original idea may have come from, and you must think about how much PHP has changed in other get new ideas that are obviously lacking the way I see it. Fourth, please realize one thing: if it's Microsoft, then nobody would want to use this.

villanus commented 8 years ago

@damien another glorious microsoft fail!!!!

not having a simple beginner (php like) version of web pages will lead to new developers starting with something like python, php, or others and just growing on that stack.

how many lavarel devs would be asp mvc devs if msft had not dropped the ball by killing asp 3 vbscript and instead selling everone that web forms were the new way???

the bottom line is MVC is too complex for new devs and small projects. based on your example you have created another complicated framework for .net core where asp.net web pages had the right solution.

why are we re inventing this wheel? does the community actually need to step in and create a solution that MSFT should be buiding to attract small businesses and devs?

i guess the whole point of dreamspark is to bait new devs into azure, not to get devs on the msft stack.

sirus-codes commented 8 years ago

please keep web pages simple as it is! dont make this mistake. adding these features to webpages make it complicated and all of webpages developers move to php, ... thanx

villanus commented 8 years ago

Agreed. for simplicity you can go with php (which sucks) or stick with old web pages and miss out on linux hosting and performance improvements.

I cant tell you how many static html like pages i have built that have one or two Razor scripts for small parts of the site. Doing it all in MVC or the new proposed web pages sounds like overkill.

Too bad

villanus commented 8 years ago

maybe msft will fix this in 3 years when they realize all the new devs are going with php, python, or js on both front and back.

sirus-codes commented 8 years ago

plz don't ask MVC team to improve webpages, they will create MVC again, instead ask old webpages team to work on it. it's your biggest mistake where you said "we are not trying to Create a scripted page framework to compete with PHP, etc." because this is exactly what you should do!

villanus commented 8 years ago

I keep thinking about this, because I love razor pages. Why not build the old stack (scripted style) on .net core and also support all the extra bells and wistles?

Damien had a good talk demo about this a year ago where he pretty much nailed it. seems like they have been over complicating it since

sirus-codes commented 8 years ago

@DamianEdwards please make it clear. Is Webpages replaced by Viewpages in asp.net core or Webpages is still on the roadmap? thanks

villanus commented 8 years ago

i have been following everything web pages and here is what i gather:

They are reworking and its no longer geared towards novice programmers. My theory is this is a mistake ( lieky based on feedback from mvc devs and not actual web pages users)

they would like to rename it, but that is a complicated move ad microsoft lives to name their products in confusing ways that cant be searched. while apple and ubuntu have it righht by versioning and play names like yosemite.

robertboeckel commented 8 years ago

I actually love this idea. While the separation of concerns in standard MVC certainly makes sense, the solution with all its different artifacts always becomes a hassle to maintain. MVC View Pages, in combination with C# nested code-behind files would definetly be a nice tradeoff, leveraging most of the existing MVC concepts while still having everything for one page in one place. Looking forward to it!

miloush commented 8 years ago

So in the stand-up, @DamianEdwards is showing what from MVC is available to the pages. Could someone tell me what you don't have? What does full MVC give you more over view pages?

villanus commented 8 years ago

What MVC gives you is extra layer of complexity for small projects. It also gives you job security as a developer and the reason you see web pages getting negative feedback.

Simple solution build asp web pages to run on core or build classic asp to run on core

msft apparently only wants the enterprise devs and not the php mysql folks. big mistake in the long run.

miloush commented 8 years ago

While I understand not everyone is happy with how this feature goes, my question was serious, I am trying to understand the limits of view pages as currently designed compared to a full MVC project.

dstelow commented 8 years ago

I will give a try, but initial reaction is very positive. This sounds great to me for a lot of use cases. Like you said a lot of the goodness of MVC with simpler approach. Our main sites are still WebForms and this could make transition smooth.

sirus-codes commented 8 years ago

Web Pages unfortunately has been removed from the .net core roadmap!! https://github.com/aspnet/Home/wiki/Roadmap

sirus-codes commented 8 years ago

@jnm2 As Damian stated in this link: https://github.com/aspnet/Mvc/issues/5208

“We already have a product called "ASP.NET Web Pages". This feature is not a new version of this product.“

jnm2 commented 8 years ago

@cyrusel Ah, you are correct. I misread.

Eilon commented 7 years ago

Moving to 1.2.0 milestone.

dustinmoris commented 7 years ago

Not sure if someone has already asked that question, but is it intended to work outside of MVC as well, so it can be used from an ASP.NET Core application without having to install the MVC NuGet package?

It would be awesome if (when completed) I could easily use it from inside ASP.NET Core Lambda. Currently all efforts to bring Razor to non MVC frameworks have been duplicated by multiple projects and none of them is really great or easily reusable.

For example Nancy has written their own implementation which is tied to Nancy, Suave is using RazorEngine which doesn't seem to be maintained anymore and doesn't support .NET Core either, and then there is a rather new RazorLight project which seems to be the best option for .NET Core at the moment, but it would be still nice to have an official Microsoft library which can consolidate all of these individual efforts and bring the same level of Razor support to multiple frameworks.

Reading the spec at the top and looking at RazorPages I think it's not far away to be completely decoupled from MVC (logically decoupled from MVC, but still part of the default MVC package and integrated into the MVC so that the current experience is not worse off).

What do you think?

DamianEdwards commented 7 years ago

@dustinmoris it's built in to MVC and is built on top of many of the primitives in MVC. In short, it can't be split out. I'm not saying there won't ever be a time we're able to split out all the bits of MVC into separate parts (e.g. model binding, validation, tag helpers, view engine, etc.) but it's very unlikely. This is part of MVC.

villanus commented 7 years ago

at the next comunity stand up can you spend some time showing this off?

sirus-codes commented 7 years ago

@DamianEdvards, when mvc viewpages is ready to use? please give some information about which step is it. thank you

DamianEdwards commented 7 years ago

@cyrusel it will be part of the 2.0 release. We're aiming to release a preview around May, and finish it a month or two later.

sirus-codes commented 7 years ago

@DamianEdwards good luck, please make it simple as web pages is to encourage php guys to leave it and join asp.net core. thank you so much man.

villanus commented 7 years ago

@damianedwards as cyrusel pointed out it might be good to have a full beginner training path. For js, php, classic asp devs, who want to jump into core without mvc.

It would be nice if the training vision was to star on razorpages, then add more advanced and eventually learn MVC.

I see how this would be useful for both evangelists, and the comunnity.

Versus just having a different framework

iamzm commented 7 years ago

Will this not be less secure and also my concern is it will make page rendering slow ?? Can anyone help me

villanus commented 7 years ago

Why would it be less secure?

Eilon commented 7 years ago

@iamzm the security is the same as the rest of ASP.NET Core. If you have any specific concerns, please let us know! If you think you've found a security bug, please contact secure@microsoft.com with a detailed bug report.

The performance in general should be roughly the same as ASP.NET Core MVC, because Razor Pages is built on ASP.NET Core MVC. If you have observed performance issues, please log a bug in this repo and we will investigate.

Thanks!