Feature folders support

[artiomchi]

As far as I can see, there's no official out of the box support for feature folders in asp.net core mvc, but the framework is extensible enough that many people came up with a simple pattern on how to make it work (see this, this or this)

I'm assuming there might be enough interest in adding support for them in r4mvc, alongside support for Pages, a different new feature also added to asp.net core.

Based on the above it's probably safe to assume that most people will put all their feature folders in a single parent folder (usually /Features/ + /Areas/{area}/Features/), which we can also make configurable. Within that folder you'd have a set of static files, controllers view model classes and razor templates, either in the root or grouped by feature folder.

This will make it easy picking up the features content, and filtering it from other content present in the app. Any content present in the Features folder will be available for content generation and static content access.

Considering the fact that making feature folders work requires extra configuration, it will be a disabled feature by default, but can be easily enabled using r4mvc.json. There are a couple settings that we can add, and we can group them in a separate object:

{
  "featureFolders": { // if this object is present, feature folder generation is enabled
    "featuresPath": "Features", // default value, but technically there in case anyone wants to override it
    "staticFileAccess": true
  }
}

We have to make sure that feature folders can coexist with existing controllers structure. That's one of the reasons why the Features folder is a good idea.

One side-effect of feature folders is the fact that the same controller name can exist in multiple features, which will cause a clash. That's something that will inevitably happen, and is not something we can easily guard against. Neither will the framework (as far as I understand, the first matching controller only will end up processing requests). A special case would be if all the controllers are manually forced to be in the same namespace, we should also make sure that this works :)

Original post, pre update

To support this, we need to consider several things.

• How will the feature controllers be accessed from the r4mvc generated classes?
• What kind of pattern will we support?

It's probably safe to assume that most people will put all their feature folders in a single parent folder (usually /Features/ + /Areas/{area}/Features/), which we can also make configurable. Within that folder you'd have a set of static files, controllers view model classes and razor templates, either in the root or grouped by feature folder.

Luckily for us, thanks to the way t4mvc/r4mvc works, we don't have to worry about how they are wired up (whether the user has wired up using something like this, this or this

I suggest the following:

• Add generated entries for all feature controllers, and add an extra route parameter to them named by the feature name (route parameter defaults to feature) The extra route parameter can be disabled, or renamed using settings. This would allow us to support all of the above ways of using it, while also supporting the use case when the feature folders are ONLY used for organisational/structural purposes
• All feature folder content (controllers, views) can be accessed using the MVC.Features.[...] prefix. So a controller in /Features/Toolbar/HeaderController.cs will be accessed using MVC.Features.Toolbar.Header.Index()
• Feature folder static content can be accessed using MVC.FeatureLinks.[...] prefix and will act in the same way as MVC.Links.[...] for static content in wwwroot

This is related to #91 and #92, which don't seem to work yet, and I'd rather have a more structured approach to this.

[artiomchi]

The implementation might have to wait for a little bit, as I'm finishing the structural changes needed for alpha1 .1 milestone, so it's a great time to gather feedback and make a plan.

@valeriob could you take a look and tell me what you think on this?

[valeriob]

I'm doing features folders since mvc is out, and i never felt the need of anything more than T4MVC offers.
I usually do features folders inside areas, and often on the root, but i just have one or two of them.

I'm using this approach on 5/6 aspnet core projects right now, and i only miss what #91 and #92 provide, i like the file system to be the structure, so i do not really like to add another prefix like "feature" , it's redundant, off course they are features 😄, what else ?
I mean, i would have to always type MVC.Feature.Home.Index() instead of MVC.Home.Index(), and for an area MVC.Area1.Features.Home.Index() ? i do not see any value...

Try to use my pull requests to get a feeling.

[artiomchi]

Nevermind, I wrote that post on the way back after work!

Just read a bit more about feature folders, and checked out some examples, and I see that my suggestion about the Feature prefix is just plain wrong :)

The reason your PR confused me even more is because of how you used them there. You seemed to apply area names in both added controllers, to make your "feature" folders work. But that's not really how I've seen everyone use feature folders at all, so it's very much non standard.

I've just updated my original post with an updated approach which should work much better, and actually makes more sense. I kept the old edit in a collapsed section for posterity :)

[artiomchi]

P.S. I forgot to add @davidebbo and @kevinkuszyk to the discussion to get their opinion on how we should handle feature folders. I can see that they're supported in T4MVC and is used in a similar way. I'm sure they might have some gotchas and tips based on their experience with implementing it

[valeriob]

I would not call things standard or not, the only thing i made different in the example is that i did not group all areas together in the same folder. The purpose of feature folder is to align the code base with business needs, my business do not have the "Areas" concept, it's useless, but never mind, let's keep this container for the folder structure.

I'm sorry but i did not understand this sentence

You seemed to apply area names in both added controllers, to make your "feature" folders work.

Maybe something is not clear: feature folders are about keeping things together, so basically a folder should contains all it needs to run, Controller, models, client assets. You can apply them to the main project and/or to each area as you wish.

R4MVC should just provide constants for path in the file system for Views and Links, and this is what the pr is about, nothing more, and i think it's what T4MVC used to do.

In the current implementation you are forced to put areas under Areas Folder and you infer the area name from the folder name

var viewsPath = Path.Combine(root, "Views");
var areaName = Path.GetFileName(areaPath);

so i reversed the approach in an addictive and backward compatible way (yep they can both run side by side, so you can have some feature folders and some not in the same area).
Since feature folders means all stuff used by a controller go together, i infer the feature folder path from the controller, the area from the correct metadata and generate the "right" static structure, and by right i mean the same that T4MVC does and the one i have became accustomed to in the years 😄

Let's start to agree with a folder and codeHelpers structure.

Do you agree that this project structure should generate the following helpers ? (like t4mvc does? i just double checked 😄 ) :
MVC.Home.Index()
MVC.Home.Views.Index

MVC.Area1.Home.Index();
MVC.Area1.Home.Views.Index()

MVC.Area2.Home.Index();
MVC.Area2.Home.Views.Index()

If so i think we should implement the minimum thing that makes this work in the shortest time possible, aspnet core 2.0 is out since much time, i think ppl needed now, at least we do, then we can refactor when we get more insight.

Thanks for caring about this, but let's try to make something simple and useful quick, we are not sending a car on mars 😄

[artiomchi]

Hmm, I understand how the feature folders work in asp.net, and I agree that we should add it. I'm not a fan of rushing features though and fixing it later, but that's a separate discussion :)

Regarding the folder structure, I don't think that's how feature folders are supposed to work. I also don't think you should mix up the areas and feature folder concepts. They're separate things, and can be used together or separately. Any controllers in a feature folder will behave the same way as if they were in the Controllers folder, the only difference is the code structure, where we move the models and the views into the same parent folder for our convenience, right?

With all this in mind, consider the following project structure:

This project can handle the following requests:

• /Home (Controllers/HomeController)
• /Calculator (Features/Calculator/CalculatorController)
• /Admin/Dashboard (Areas/Admin/Controllers/DashboardController)
• /Admin/Users (Areas/Admin/Features/Users/UsersController)

For this, R4MVC should generate the following:

• MVC.Home.Index()
• MVC.Calculator.Index()
• MVC.Admin.Dashboard.Index()
• MVC.Admin.Users.Index()

This is the way most people use feature folders (based on my research), and more importantly this is the same way that T4MVC works (I just tested this myself). In fact, by default feature folders are completely ignored, since it's an optional feature. Once I set the feature folder name to Features in settings, it started working, as described above. I just pushed it to a new repo just for testing and discussion - artiomchi/AspNetWithFeatureFolders, you can check out the commits and how the generated files changed based on the settings.

It seems to be a relatively simple thing to implement too, actually. The static file generation might require a bit more work, but controllers and views should only require a handful lines of code changes :)

I couldn't make your folder structure work. It doesn't seem to follow any of the accepted conventions either, to be honest. I'd be interested to see a sample project that follows that folder structure and has t4mvc generating the links you described for it, even if just for academic purposes

[artiomchi]

By the way, I just made several changes to add some rudimentary feature folder support to r4mvc in a feature branch. It works quite well, but only supports the folder structure above. There are a couple other patterns that people use (like putting all the view files into a Views folder within the controller feature folder, or grouping multiple features in a "feature group" folder, which is not supported, but that can be done later. In terms of basic support though - it works.

I've updated the test project I mentioned above (artiomchi/AspNetWithFeatureFolders) with a asp.net core project. It uses the new feature build from the ci server (version 1.0.0-ci--feature-folders-00231), and enables the feature in r4mvc.json.

In the same way as before, I added the project, r4mvc, feature controllers, feature folder setting - all in a commit each, so you can see the progression, and the changes that each step makes.

What do you think?

[valeriob]

Hi @artiomchi thanks for thinking about this, those are my considerations, sorry for the long post, but i really care about this 😄

Exactly my point, and that's why i think r4mvc should make nothing different than usual, but should look for views and static files whererever they are and provide static links, so everyone can make the folder structure thye want.

I've never seen the "Features" folder used and to be honest i do not like it, it's useless, it does not provide any benefit at all, instead it's another useless folder (like Areas) that you have to deal with because of framework complexity, my businnes does not have the "Areas" container concept neather the "Features" container concept.
The whole point of feature folders is to have project structure aligned with the business, pls do not force ppl to add yet another folder for the framework sake.

I think you are wrong about T4MVC :
The T4MVC parameter FeatureFolderRootArea works only for the ROOT of the project, and not for the areas ! Instead to enable all areas to feature folder you have to enable the following parameter
*, and you do not need that added folder, this demonstrates that your project structure does not exists in T4mvc and it's not "standard" (i don't like the word), pls its fine if you do not have feature folder experience, you have to trust me a little bit on this pls :smile, see my pull request on your project (see that it does not work like you said https://github.com/artiomchi/AspNetWithFeatureFolders/pull/1).
The FeatureFolderRootArea parameter has been added just lately and it's not how most people use it, and it's optional, the main behavior is the one i'm telling you.

To be honest i do not understand why are you making a big deal of this and why you want all ppl to adhere to your project structure, i'm for max flexibility and i think it's easy to achieve, with less work, and more correctness.
Static files should work regardless of feature folder, they should just reflect static files in file system, they should not care how ppl structure their project ( and my pull request supports all of this).
Views instead should just be "coupled" with controllers so i think you should discover them wherever they are, and ppl are free to implement their project strucutre, and if they place all assests in the same controller folder my approach will make em work wherevere they are in the file system, with zero configuration.

I do not know if you checked my pull request, but it's very symple thing :

• from the controller metadata get the controller.cs path

• look for views in the same folder

• infer the area from the controller metadata

• Your approach only works with "Areas" folder

• forces ppl to add yet another "Feature" folder they have to keep opening for no reason

• you infer the area from the folder name (it's needed to generate code)

I'm sorry but i see only downsides and not even one upside of this approach.

You have to think about why ppl add some things, and the only reason to add those keywords (Areas, Features) is to recognize the part of the project they have to act upon, but with roslyn this is not needed ! We can ask a controller what area he's on (and not infer it from the path!) we can know if a folder has controllers inside, and we do not need to ask the user "pls point us to the folder where your controllers are because are different from the keyword "Controllers".

[artiomchi]

Hey,

Oh wow.. So this is going to be long. Let's start with the fact that your post has a LOT of misinformation and misleading statements, both about T4MVC, the way R4Mvc works and feature folders themselves.

I would REALLY appreciate some input from the project owners @davidebbo and @kevinkuszyk, both in terms of their experience with this and as mediators 😄

To be honest i do not understand why are you making a big deal of this

I'm.. not? I've just opened a discussion for this new feature, to make sure we implement it in the best way we can? Unfortunately, you're taking a somewhat aggressive stance on this, which is not very productive.

TL;DR; So far I don't have any reason to believe that what I explained about about feature folders is wrong. But please note that this is literally the first commit I did in regards to it, and it is NOT finished yet - it only added basic functionality. I AM planning to add support for something similar to FeatureFolderAreas from T4MVC, and if you check the code I added yesterday, there's an option in the settings called FeatureFolders.FeatureOnlyAreas - it's just not been implemented yet. Once properly implemented, you will be able to do this:

Note that feature folders in the root of the project will still have to be contained in the Features folder, for reasons I explain later in this post.

I have checked your PRs, but I don't agree with what they do. They make assumptions about how the project is structured based on how you build your projects, and potentially promote bad practices. I'm trying to make sure this library will work well and fit most well adopted use cases. As contributors to an open source project, our responsibility is to make sure that the library works for everyone and follows best practices, and doesn't just follow what we like to do.

---

So let's break your post down into points:

I've never seen the "Features" folder used and to be honest i do not like it, it's useless, it does not provide any benefit at all, instead it's another useless folder (like Areas) that you have to deal with because of framework complexity

Sure, but the fact that you haven't seen it doesn't mean it's not a thing. I haven't seen anyone use feature folders without grouping them all in a "Features" parent folder. I don't think it's useless, far from it. It provides structure to your project and that's good. You can have a number of other classes/folders in your project that aren't controllers, you can have static resources and so on - things that shouldn't be treated as feature folder content. So grouping all the controllers/views/models in a "Features" folder makes perfect sense to me. That's just my opinion, but it seems to be backed by other developers too, based on my research.

my businnes does not have the "Areas" container concept neather the "Features" container concept.

I completely understand that, and there's nothing wrong with that. It also doesn't mean that it's a useless concept and that nobody is using it.

The whole point of feature folders is to have project structure aligned with the business, pls do not force ppl to add yet another folder for the framework sake.

I'm not forcing anything, that's why I opened this issue to discuss this. That's also why I didn't change anything in the main branches yet, since it's an open discussion. The feature branch was just one possible way of doing it.

The FeatureFolderRootArea parameter has been added just lately and it's not how most people use it

Ahh.. nah man, it's been added in March 2014! T4MVC/T4MVC@da22a2fe Heck, it's been added 4 days after the FeatureFolderAreas attribute so what are you even talking about? T4MVC/T4MVC@e52fe2b6 e52fe2b6

and it's optional

sure, so is FeatureFolderAreas. They're also both disabled by default

the main behavior is the one i'm telling you.

Umm.. Don't agree with you here. Both FeatureFolderRootArea and FeatureFolderAreas have been added to the project pretty much at the same time, in the grand scheme of things. BOTH of them are optional, and the default setting has them both disabled.

Furthermore, feature folders in MVC have always been bundled in a Features parent folder. Both way back in 2013 (see here) and now in 2016-2017 (here, here and many other places). There's a Feature folders support plugin for asp.net core by Scott Allen (!) that follows this convention! (check it out here: OdeToCode/AddFeatureFolders)

Even in the comments to the setting in T4MVC, it explains the feature. You can set FeatureFolderAreas to *, but that's only if ALL your areas are following the feature folder convention, but that's not the main part of this option, and it's not the default either.

this demonstrates that your project structure does not exists in T4mvc and it's not "standard"

Umm.. I literally showed you how this works in T4MVC yesterday with my test project.. What do you mean "it does not exist in T4mvc???" 😄

Static files should work regardless of feature folder, they should just reflect static files in file system, they should not care how ppl structure their project

Again, I strongly disagree. Static file behaviour was changed drastically in asp.net core, as we've discussed in #87. By default static files will ONLY be served from the wwwroot folder, and if the developer wants to change it, they have to reconfigure their app. The default behaviour of R4Mvc should mirror the default behaviour of asp.net.

And on this note, while you CAN configure the static files to serve files from your app root, it's a potential security risk, and we should NOT be promoting this. In the same way, serving files from ANY subfolder in your app can also expose sensitive information, and as such should not be encouraged.

Using a Features folder to group all features becomes a safety net - a safe default way to enable feature folders support. This ensures that the developer knows exactly which content will be exposed to the end user, so they will not accidentally create security holes in their apps.

You have to think about why ppl add some things, and the only reason to add those keywords (Areas, Features) is to recognize the part of the project they have to act upon, but with roslyn this is not needed

In asp.net mvc, you had to do this because that's how the framework was built. You had a bit more leeway with where you had the controllers, but the Areas and Views folders were just the way the framework worked (out of the box).

In asp.net core they changed things. Mostly just the way the controllers were assigned to the area (now using the AreaAttribute). Most other concepts are quite similar in their default settings.

We can ask a controller what area he's on (and not infer it from the path!) we can know if a folder has controllers inside, and we do not need to ask the user "pls point us to the folder where your controllers are because are different from the keyword "Controllers".

Umm.. You do realise that r4mvc uses the area attribute for this, and NOT the path, right? It also already picks up controllers from ANY folder in the app, as long as they derive from the Controller class.

P.S.

"standard" (i don't like the word)

Why not? Having standards is very good. Otherwise we'd have to carry a bag of 15 different cables and adapters with us, instead of most things working over USB. And we'd have 15 different protocols to access a website instead of using HTTP.

Having standard ways to do things doesn't mean you don't get a choice to do things your way, but it will mean that projects can be consistent and easy to work with for multiple people. It also promotes best practices.

[davidebbo]

@artiomchi I was involved in T4MVC (not so active anymore), but not in R4MVC. As much as I would have liked to, I just have too many other priorities to make useful contributions on this one.

[valeriob]

I'm sorry if i looked like uproductive, it's not my goal :D

TL;DR; I'm fine with any implementation you prefer, that let the user some leash and do not hurt productivity, i' can live with the "Feature" root folder, but i do not agree with that choice.

I do not think that something is right just because ppl do it in a particular way 😄, i prefer to use my own brain and experience, and there is no technical reason why this folder should be mandatory, i still think that that folder should be optional, it does not provide any value, it's the framework forcing me a project structure. Anyway pls do not force us to use the "Feature" folder inside an area.

I did not understand your position on static files, will you allow to generate helpers for static files in features folders or are you forcing ppl to copy them in wwwroot ?
I agree of the security implication of "exposing" the project root, but it's easily mitigated by a simple line of code, and it has been like that for like 15 years. Anyway forcing to serve content from wwwroot makes the whole development process frustrating, because you introduce an useless step of copying files on wwwroot during build (and you need them to be there to generate r4mvc helpers, catch 21).
So when you are working on a feature, you save a Ts/js file and press Save, refresh the browser the file have to be copied, you need a watcher, and i do not see a "default project support for something like this https://www.npmjs.com/package/cpx.
I'm using the approach you suggested but it has limitations about routing (introduced by framework) that i have to live with, and force on me a particular project structure, but i'm being pragmatic and bit that bullet.

this demonstrates that your project structure does not exists in T4mvc and it's not "standard"
Umm.. I literally showed you how this works in T4MVC yesterday with my test project.. What do you mean "it does not exist in T4mvc???" 😄

I'm sorry i was referring at the picture where you have "Features" folder inside areas, this does not exist in T4MVC. The "Features" folder exists only in the root of the project, this brought me to believe that you have not used them very much, and so i'm trying to bring here some feedback from the field, that's a completely different sensibility than reading a blog post about it.

Just for the sake of being precise, my pull request does not make any assumption about project structure, it just adds on top of what exists today in backward compatible way, because it detect the path of the feature by the controller, instead today r4mvc (i have not looked at your recent prototype yet since we where discussing about the end result yet) has a "Areas" magic string on it and detect area name from the path.

Umm.. You do realise that r4mvc uses the area attribute for this, and NOT the path, right? It also already picks up controllers from ANY folder in the app, as long as they derive from the Controller class.

Not the code that looks for views, that's the main point of my PR 😄
Actual code :

My additive suggestion (it's another locator running in parallel, and the result is merged)

In conclusion root "Features" folder apart i think we agree on the end result of the project structure, i think that the main issue now is about static files.
Note that none of the resources you mentioned solved that issue, did not even mention it. I can't understand how someone who used it in production had not written a single js file, this makes me doubt about the "production ready "solution 😄
My pull request #92 is very very simple, it's additive and backward compatible, and coupled with this approach works without changing wwwroot, so i see no issue about it It has support from aspnet core framework

Serve files outside of web root

[kevinkuszyk]

@artiomchi @valeriob wow, there's a lot here.

To be honest, I haven't used feature folders in my MVC projects, so I don't think I'm best placed to comment on usability etc. However, I'm aware of the concept and have seen that we have support for it in T4MVC.

My guiding principles for adding features would be:

• is there a demand from users for a feature?
• can users can opt in without degrading the experience of other users?
• can we can support it without making the code hard to maintain?

If it's yes to all of the above, we add it.

Let me know if you want me to get off the fence, read through the whole thread, and make an informed decision!