Open joeaudette opened 9 years ago
Planning...yes.
However, I don't have a lot of time to dedicate to MvcSiteMapProvider at present. I also have a policy not to install any pre-release software on my dev boxes, so the only option at present is to set up a virtual machine (which obviously is more work to setup than waiting for the official release of VS2015).
I took a really quick look and it seems that the IControllerFactory interface has changed pretty significantly, which will mean significant changes to the AuthorizeAttributeAclModule (or perhaps even a completely different authorization module) to accommodate MVC6. The IDependencyResolver interface is gone, so there will also need to be some rework to work out how to plug in DI (for those that use it, anyway).
I am guessing there are other changes to make it function as well, but fortunately there aren't very many places where MvcSiteMapProvider and MVC/ASP.NET touch and we already have a conditional compilation symbol scheme to support conditional pieces of code, hopefully it won't be too involved.
Anyway, I just pushed an mvc6 branch and I am willing to accept pull requests for work on MVC 6 on that branch in case anyone wants to jump ahead and start working on it. Of course, it will be best starting from the internal DI container (with IControllerFactory), then fix the MvcSiteMapProvider project to be compatible with MVC 6, fix the build, then tackle the external DI containers last.
Next to that, all of System.Web has disappeared so we will effectively have to create a separate version of MvcSiteMapProvider. PR's welcome :)
Yeah this is a very big transition for ASP.NET, probably the biggest transition in the whole history of asp.net. Actually System.Web is still existing but only in the desktop framework not in the new light weight cross platform .net core framework, which of course is what the cool kids will want to use. System.Configuration is also gone but there is a new lightweight flexible config system that can be used instead.
There is also a new DI Container built in and used by default when you create an asp.net 5/mvc 6 project, though of course it can be replaced with other DI easily. But I would suggest use that as the default instead of an internal DI. As an aside, on another issue thread you mentioned about the Dependency Injection book by Mark Seemann. I took your advice and read that book and really got a lot out of it so thanks for that.
So basically asp.net 5/mvc 6 will run on the core framework but anyone who wants to continue using WebForms or anything form System.Web or System.Configuration will be stuck with the desktop version.
The core framework is also bin deployable so it will be possible to upgrade to new versions without concern for what version is installed at the web host.
The MVC and Web API frameworks have been consolidated so they both use the same controllers. Most previous functionality should still exist but namespaces may have changed. Actually while there is still a base class for controllers, you are not even forced to use it, it is possible to make controllers without it but you still need the convention to name the class with the word Controller like MyController.
instead of .csproj files we now have project.json files and compilation happens at once in memory when files are edited rather than requiring a rebuild. It is very fast. There is also a new class library project that uses the project.json and the roslyn compiler, building actually produces nuget packages rather than dll files in the bin. There is no bin folder beneath the web app anymore. Even the core framework itself is composed of nuget packages.
Things that used to implemented as httpmodules would now be implemented as OWIN Middleware components.
Like you I've always been reluctant to install any preview version of VS on my main machine, but I did install the new RC recently because from watching the asp.net community standup videos on Scott Hanselman's youtube channel I learned that it is ok to install it, it will run side by side with VS 2013 and when a new or final version comes out you can just install on top of the old one without uninstalling. Even the download page for VS 2015 RC has no warning about installing it on your machine as they did have in the very early previews where they suggested using a vm.
I'm not sure I know enough about the internals of MVCSiteMapProvider to help and at the moment I have a lot to do converting the code for my own app. But when I get that done and I need to get menus working I will probably at least have to take a look and see if I can be of help in order to move my own app forward.
I agree that it will be best to use the cross-platform .NET core, and not have any dependencies on System.Web
. And since MvcSiteMapProvider
is a web-only framework, I don't think that will be a problem.
Ideally, if possible, we would like to continue using a single code base for all MVC versions, including MVC 6. It sounds as if we must switch to using config.json
in order to support .net framework core. If I am not mistaken, we will also need the .csproj
file for supporting older versions of Visual Studio (or will there be some updates so Visual Studio 2012 and 2013 can support project.json
?). It would be nice if we could sync the code files between the two project files so adding a file using one environment adds the file in the other environment automatically. Or perhaps it would be best to start with a .csproj
to maintain compatibility with the rest of the MVC versions and have the build script generate the project.json
file, the .net framework core DLL, and NuGet package.
Or perhaps we could do it the other way around. It sounds like Roslyn will be able to build projects for older .NET framework versions, so we might be able to swap out msbuild for Roslyn across the board for the build.
The whole point of moving to DI in the first place was to conform to a set of interfaces that know nothing of the underlying implementation. Technically, MvcSiteMapProvider
doesn't depend on System.Web, it primarily only depends on some of the abstractions provided by System.Web
, System.Web.Routing
and System.Web.Mvc
. So, the simplest course of action to port MvcSiteMapProvider
to MVC6 may be to create adapters around the new interfaces that are based on the old interfaces (and re-implement the old interfaces locally inside of #if MVC6
symbols, copying them from the old libraries).
For example, whenever HttpContextBase
is passed through an interface in MvcSiteMapProvider
, a custom implementation could be passed that wraps the relevant context object from ASP.NET 5 and implements the current HttpContextBase
abstract class (copied into the MvcSiteMapProvider code base). The advantage of this approach is that the core interfaces of MvcSiteMapProvider
will remain unchanged, which in turn means less maintenance, and less likelihood to introduce bugs as part of the port. Ideally, we can add the MVC 6 support to the project without affecting any of the other MVC versions or making any changes to any existing interfaces (in other words, just make it a patch to the existing version).
One trick will be to find out how to add conditions to project.json
the same way they can be added to .csproj
, as we won't be able to support conditional dependencies (i.e. versions past MVC 6) without them.
There will also likely need to be some new components (or just conditional sections of the existing components) to operate with the new Authorization functionality, resolving controller types, resolving URLs, etc. Unfortunately, the interaction with Routing has not been put into services, it is part of the SiteMap itself, so there will likely need to be some changes to interact with Routing in ASP.NET 5. But those could simply be put into conditional compilation blocks.
As for using the built-in DI in ASP.NET 5, I respectfully disagree. Mark Seemann did not agree that the approach Microsoft took was the correct one (at least not very early on). There are others (who I respect) who agree that Microsoft took the wrong approach. As a maintainer of this project I don't think it would be wise to depend on ASP.NET any more than is necessary, including adding a dependency to an external DI framework that many experts agree is overly complex.
Unfortunately, there was a chapter missing from Mark Seemann's book. The book was all about configuring applications, but the advice does not blanketly apply to libraries or frameworks, which were posts that he released after MvcSiteMapProvider v4 was complete. The direction we are heading is to eventually phase out the internal/external DI container (which is essentially a conforming container) using the approaches described in those articles. This means that whatever DI container comes in the box with ASP.NET is irrelevant and unnecessary as far as we are concerned.
The plan is to allow you to optionally reconfigure the MvcSiteMapProvider
DI pipeline at application startup, allowing swapping-out of individual dependencies. This will mean you will simply be able to use the new
keyword to inject your own dependencies (similar to how you inject IDependencyResolver
in MVC 5), as there are still a large number of developers who would like an alternative to using full-on DI for more complicated configurations. There will be a unified fluent configuration API (consisting of several fluent builders and abstract factories) where the entirety of MvcSiteMapProvider
can be configured (configuration options, nodes (hierarchical nodes in code!), code-based node providers, multiple SiteMaps, mapping of requests to SiteMaps, etc.). For backward compatibility, all existing configuration options will still be supported, but we will likely discourage using external DI after the fluent API is in place, and phase it out in a future major version. The emphasis will still be for MvcSiteMapProvider
to "just work" when installed, but also allow for replacement of individual pieces with or without a DI container.
What is gained? Developers won't have to worry about changes to MvcSiteMapProvider's internal configuration breaking their external DI configuration when they upgrade MvcSiteMapProvider. Developers who don't want to use DI for advanced options don't have to. All configuration of MvcSiteMapProvider can be done in one place using fluent code constructs that are easy to read and understand. Creating multiple SiteMaps will be a quick and easy procedure. Going forward, MvcSiteMapProvider won't depend on web.config. We won't need to maintain any external DI packages or configurations for specific DI containers, or provide documentation for same. It will be much easier for us to add features because we won't have to consider the external DI configurations. So this is a win-win.
There is currently no documentation for this, so this is intended to be a primer to understand how MvcSiteMapProvider
works, along with what parts of core ASP.NET/MVC it uses.
Like nearly any web technology, MvcSiteMapProvider
is driven entirely by the incoming requests. The requests begin at the point where the HTML helpers or the /sitemap.xml
endpoint are called. If more than one HTML helper is on the page, there will be as many requests to MvcSiteMapProvider
. However, the SiteMap
object is stored in a shared cache (which can plug into either System.Web.Caching
or System.Runtime.Caching
), and it also extensively uses request caching through System.Web.HttpContext.Items
to keep data alive between HTML helpers.
ISiteMapBuilder
, ISiteMapNodeProvider
, and IDynamicNodeProvider
services. During this stage, there is a different request-cache pool than that used in production to prevent the build stage from polluting the current request. In general, these services do not depend on ASP.NET (except for some enumerations). This is done only when the SiteMap
cache expires.HttpContext
object based on the home page (to prevent the injection of "ambient values" into the URL - see #213). Most of the time the URLs are not cached, but they are cached along with the SiteMap
when there are no custom route values and no preserved route parameters. This phase uses the UrlHelperAdapter
(based on an internal IUrlHelper
interface since MVC didn't provide one), and HttpContext
(both internally and through the UrlPath
service, which is a duplicate of some of the ASP.NET functionality and may need rework).SiteMap
, the SiteMapNode
, and the RouteValueDictionary
. This stage depends on the URL information in the HttpContext
object as well as System.Web.Routing
.PreservedRouteParameters
are copied from the URL or Route (route takes precedence) into the request-cached RouteValueDictionary
. These values are discarded after the current request ends. This stage depends on the URL information in HttpContext
object, System.Web.Routing
, and System.Web.HttpContext.Items
dictionary.ISiteMapNodeVisibilityProvider
interface and a IAclModule
interface. This phase is not cached. The visibility provider does not depend on ASP.NET, but the AuthorizeAttributeAclModule
depends on several interfaces including the AuthorizeAttribute
and Controller
, ControllerContext, and
HttpContext`.There is also another slightly different workflow when calling the /sitemap.xml
endpoint which is pretty much the same except for it outputs XML through an internal Controller
. The Controller
would probably be better suited for OWIN middleware in ASP.NET 5.
In general, the classes in the Web
namespace are most dependent on ASP.NET and MVC directly, and many of those will need rework, including the ControllerTypeResolver
, which will likely need a new implementation for MVC 6.
Do note that there is a new XML Sitemap implementation in the works that I have recently put into a production project for testing. I am considering making this into a separate NuGet package (so we can support ASP.NET 2.x to 5.x), but there are many common dependencies and there will need to be some configuration to make it interact with MvcSiteMapProvider
. See #345.
Ideally, that piece should be ported to MVC 6 as well (although the fluent API is not yet complete).
It would be interesting to also support Tag Helpers as an alternative to using HTML helpers. This may end up being a big win since the templated HTML helpers are not so obvious to use (the templates are tucked away in the /Views/Shared/DisplayTemplates
folder).
It would be better if the developer could simply use a tag for the Menu and then provide their own CSS class using an attribute and other menu customizations using nested tags that represent repeating sections similar to how ASP.NET templated controls work (if that is possible).
At this point, these are not strictly necessary because HTML helpers are still supported but they are an interesting alternative nonetheless.
I still think that MVC 6 support can be added without a major release, but in case that isn't true, here are some of the major issues that are awaiting the next release.
In addition to the remaining open issues (which mostly can be closed with the above work), there is another list of issues that need to be addressed (some of which have been addressed in the above list).
Needless to say, if we don't break the interface of the current version, the above work can be avoided for the port of MVC 6.
Thanks for all the great information.
I want to mention about DI, Mark Seeman's book came out in 2012 and was very influential. However, before you dismiss the DI from Microsoft please note that it is not one of the older ones criticized by Mark Seeman, it is brand new in the Microsoft.Framework.DependencyInjection namespace and I suspect the fact that they decided to start over and not use one of the older ones is probably because of the influence of this book. Keep in mind that anyone who starts a new MVC 6 project is going to get this one by default unless they change it themselves and probably most people won't change it unless they just really love some other DI for some reason. This one looks very good to me.
Another concept that is new and may be very useful in terms of replicating needed interfaces without taking a binary dependency on assemblies you want to avoid, is the concept of "assembly neutral interfaces". You can find some information about this by google if you have not seen ti already.
oh, sorry, I spoke out of turn, I had not read the forum post you linked, I see that it is the new DI that Mark Seemann did not agree with not just the old ones.
I have been doing research on this subject and have made some headway. However, after spending 2 days attempting to reuse the current code base and make a direct port to MVC 6, I can see there are quite a few incompatibilities.
Also, I have been searching for a way to actually make reuse of the conditional dependencies of MVC going forward without any luck (I even offered a 50 point bounty, but still nobody is answering). I did come up with a (not so good) solution, though - using globs to select source code to compile outside of the build directory.
"compile": "../MvcSiteMapProvider/**/*.cs",
"compilationOptions": {
"define": ["MVC6", "NET46"]
},
Then you can structure the directories like
MvcSiteMapProvider/
MvcSiteMapProvider.MVC6/
MvcSiteMapProvider.MVC7/
and each MVCx
directory can have its own project.json
file with references to the same source. It works, but Visual Studio doesn't display any of the code files in the MVCx
directory. I (sort of) solved that by adding a .projx
and project.json
file to the MvcSiteMapProvider
folder.
Anyway, it occurred to me that there are 4 different options for moving forward:
MvcSiteMapProvider
die with MVC5.MvcSiteMapProvider
have a way to upgrade, but create a new package for the best integration with MVC 6.In all cases, it would probably be best to exclude the XML sitemap functionality (for search engines) from MvcSiteMapProvider
for the ASP.NET 5 stack and make it a separate package using the [prototype]() I made previously.
I am also inclined to push the Fluent API forward for the integration, since it makes total sense to add to the existing configuration scheme that Microsoft started (for both OWIN and for MVC6).
// Add MVC services to the services container.
services.AddMvc();
// Add MvcSiteMapProvider services to the services container.
services.AddMvcSiteMap();
Pros:
Cons:
#if MVC6
sections in the code.This could be the opportunity to fix the project name, which is just wrong.
I think we should contact Microsoft to see if they are open to creating a Microsoft.AspNet.Navigation
package first (or perhaps just adding the Navigation
namespace into the Mvc
project), and if they are not, we can still name the package AspNet.Navigation
. It would be nice if there were official support from them, though.
Pros:
Cons:
Pros:
Cons:
Pros:
Cons:
I can tell you that since asking about this I have gone ahead and implemented something new for navigation that is almost feature complete for my needs but does not have every feature that your project provides. I do have menus and breadcrumbs working and my current implementation supports use of either xml or json for building the navigation tree from a file. I still plan on adding a way that a navigationnode in the xml or json can point to another INavigationTreeBuilder so that for example a cms could implement one that builds its sub tree from a database building on top of the one that is built from xml or json. I plan to move this code to its own public repository and make it open source under apache 2 soon after MS ships asp.net 5 beta8. In beta8 we will be able to package views and viewcomponent templates and other static files in the nuget created by building a class library project. So at the point my main project can just take a nuget dependency on my navigation library. That is why I'm waiting till beta8 to move the navigation project out of my main repo. So at the moment my work is in a private repo.
So as far as the start over option my project may interest you and I would welcome collaboration on it if it does interest you. I implemented the menu and breadcrumbs as a viewcomponent and I also have a taghelper for pagination that will be in the same project. I still have some work to do as far as caching the navigation tree once it is built, but that should not be difficult work.
Sure, I'd like to see what you came up with.
Although based on what I am seeing in the AspNet project, it might make the most sense to make navigation into middleware (since that is where session and routing are).
Also, since a contributor offered up a glimpse of a fluent API, that seems like the most logical way to configure navigation (since writing the configuration will happen few times, and reading it again will happen many). The new startup section of MVC makes this even more compelling. This enables us to completely get rid of the internal vs external DI mess and provides a unified way to configure the entire library. Seems way better than trying to manage configuration files, but that could always be a another option (along with .NET attributes and custom node providers).
As for caching, one of the things I have learned on this journey is that making the best use of memory really pays off. MvcSiteMapProvider
has a limit of about 10-15 K nodes before it really starts to bog down the system with disk swapping. So my thought was to try to split up the "indexing" data (that is, the route values/url) from the rest of the data on the node, and then lazy load the rest of the data as the UI requests it into separate caches, so nodes' data that is rarely accessed can be removed from memory. It wouldn't be as good as reverse-engineering Lucene.Net, but it would probably increase the amount of nodes you could deal with considerably.
Also, taking a page out of the MVC project, it occurred to me that the node matching should be made asynchronous and perhaps optimized in other ways too (like searching by action name first, then searching the subset for the matching node). The Decision Tree namespace also has some interesting ideas in it.
I'll post a link when I make it public. You may not like my version or my vision for it. To me it is a UI component and nothing related to middleware and I have tried to keep it as simple as possible, you may find it too limited. I will welcome feedback both positive and negative once you do see it.
Simpler is usually better. That is what I am liking about the new MVC - gone are the days of the 1000 line+ class definition. Maybe you are right and I have been looking at it all wrong the whole time - it should just be a simple UI component. I am curious to know if you found a simpler approach to node configuration, as well.
It seems like there must be a way to piggy-back on the ActionSelector to pick the right node. Food for thought...
If you'd like to have an early look I'm happy to add you temporarily to my project. I know you are a reputable guy and I trust you not to do anything wrong. The other stuff in my solution will also be open source later on anyway. Just don't be too harsh on me with criticism since it is an early view. for example I know I currently have some logic in my my NavigationViewModel that needs to be factored out of there. Let me know and I'll add you, I can also give you easy directions to get the solution working so you could actually see the navigation. Really just a matter of giving it a connection string.
Sure, I would appreciate it. You don't have to give me write access or anything, but yea, I would like to see how it works.
Since the repo is currently private the only way I can let you in is by allowing you write access. I've let you in and I just updated the file DeveloperQuickStart.txt in the notes folder. It has instructions for getting it working.
My 2cents: I use this as a display component only. When the user is on a page, I want to know what node they are on so I can display the correct menu. Currently what I use is very simple - I have all top level nodes on tabs at the top and when you click one of those tabs, the nodes under that selected one appear on a side menu on the left. I use visibility selector - so I can have nodes that are not on a menu, yet keep the tab at the top highlighted. I use the security trimming feature so only things they have rights to are shown.
I use autofac for DI. Autofac integration will be released with vNext directly. It is 'included in the box'. I would support that everything in your library REQUIRES DI and there is no built in mechanism. It uses this Autofac out of the box in MVC6 and if users want, they can replace it.
I have been using this library for many years and that is all I use. Hardly seems like a middleware type of thing. @joeaudette I probably could fit in what you built?
btw, I think a clean break 'Start Over' is what looks the best route to me.
@joeaudette Any chance I could see your work and see if that is the direction I would like to go toward?
Sure it is public now, https://github.com/joeaudette/cloudscribe.Web.Navigation
Any news here?
Hi, is there any progress on MVC6 sitemapprovider? Asp.net core 1.0 is out...the MVC6 branch is running for a while...is there any planned release date with the same features as MVC5?
Btw. focusing purely on the sitemap funcions, is it possible to have a single code-base and a interface with 2 implementatin - with MVC5 related System.Web helpers and with the same helpers and MVC6 implementation?
I've been trying to work on "Port and then Redesign", to try and help since I really don't want to look at another library for menu systems, but I can't even get it to build. :(
Port will be hard, as all underlying bits have changed... Time, need time :-)
(the compilation error may be because MVC2, which we still support, is missing on your system)
@maartenba I too am porting my MVC sites to ASP.NET Core MVC. My solution to porting SiteMaps was to use Options (configuring POCO settings ) and to setup the site navigation in the appsetting.json file. Essentially you have navigation collections with nested nodes ( which are similar to a SiteMapNode ).
Here is what the Navigation section looks like:
"Navigation": {
"Collections": [
{
"Name": "Site",
"Description": "Site Menu Collection",
"Nodes": [
{
"Title": "Home",
"Url": "~/",
},
{
"Collection": "Admin"
},
{
"Title": "TopMenu1",
"Nodes": [
{
"Title": "SubHomeA",
"Url": "~/subhomeA"
},
{
"Title": "SubHomeB",
"Url": "~/subhomeB",
"Roles": [ "Administrator", "SuperUser" ]
}
]
},
{
"Title": "DynamicTopMenu",
"Key": "/Site/TopMenu"
}
]
},
{
"Name": "Admin",
"Description": "Administration Menu Collection",
"Nodes": [
{
"Title": "Admin",
"Roles": [ "Administrator" ],
"Description": "Site Administration Menu",
"Nodes": [
{
"Key": "/admin/content",
"Title": "Content Management",
"Description": "Content Type Management",
"Nodes": [
{
"Title": "Articles",
"Url": "~/articles/admin/list"
}
]
}
]
}
]
}
]
}
Just wanted to post my thoughts here. Lots of thoughts...no time to implement them :). In case someone else gets the jump on this work, here is the direction I would probably go (as it makes the whole thing better and easier to implement at the same time). But feel free to chime in if you disagree or can improve on these ideas.
When I took a stab at attempting to make a port, it didn't seem very likely that we can make it work without a major version change. So, it might be better to Divide and Conquer in conjunction with a redesign. Basically, split everything up first in an effort to release a completely new version, and factor all commonality out so we can reuse it in both stacks. However, I am still thinking that a name change to AspNet.Navigation
is in order (at least for the MVC Core stack).
Yea, I know, it means everyone has to throw out their existing code, and reimplement their business logic in order to upgrade. But my thought is to eliminate the need for most of that code, so you will be deleting a lot more code than you need to add.
So, perhaps the DLL project structure could be:
MvcSiteMapProvider.dll AspNet.Navigation.dll
\ /
AspNet.Navigation.Core.dll
(Namespace conditionally compiled as MvcSiteMapProvider or AspNet.Navigation)
Of course, we could either ILMerge them together into a single DLL for each stack, or simply put both the main DLL and Core inside the same NuGet package.
After coming across Mark Seemann's Provider is not a pattern post some time ago, I realized that the "providers" in MvcSiteMapProvider
are not actually "providers". So moving away from this naming convention is a good thing.
I don't think anyone will disagree with my view that MvcSiteMapProvider
requires way too much configuration code. There have been a HUGE number of questions about configuring route values and preserved route parameters, generating URLs, confusion about how to dynamically change the SiteMapPath
, how to load nodes from dynamic sources, and how to control node visibility. So my thought is to embrace the MVC pattern, and move away from the ASP.NET 2.0 provider model that much of this is based upon. Here are some of the design changes that I think will make for a much more intuitive experience.
RouteData.DataTokens
as one option for providing key/parent key relationships directly in the routing configuration. Some convention-based settings such as the pattern used for routing ({controller=Home}/{action=Index}
- but we need to invent ours...my thought is to make them similar to namespaces sort of like what MvcCodeRouting
does to maintain their hierarchy of controllers) should also be used to set the name of the key of the current route combination and the name of the key of the parent. Due to the fact that routes don't map 1-1 with actions, this might be a bit of a challenge, so ideas are welcome.
MvcSiteMapNode
will no longer exist - we will just provide various attributes (which filters run) that control the loading process.IsVisible
property that can be set as needed (possibly made invisible in other filters by passing an interface that doesn't include it, so only visibility filters can interact with it - SRP).SiteMapTitleAttribute
works now. The simplest scenario is just to add another level on the fly (for CRUD methods for example), but there should also be a convention-based way to make 2 or 3 levels, including grouping nodes, as well. For more advanced scenarios, a custom filter will be required. ISiteMapNodeProvider
, make convention-based Navigation Controllers that will execute automatically when put into a known location (possibly look into extending the view engine locations) to load static navigation nodes. The navigation controllers can return a result (similar to or inherited from ActionResult) that executes a specific type of action. Examples could be XmlFileResult("thefile.name")
, JsonFileResult("thefile.name")
, ControllerActionScanResult()
, AttributeScanResult<attributeType>()
, etc. plus custom result types. The controllers can be decorated with filter attributes to control which SiteMap instance(s) will be populated with the nodes. Basically, the built-in functionality will use Navigation Controllers and you can add custom Navigation Controllers/turn off the built-in Navigation Controllers to customize.MvcSiteMapNodeAttribute
into individual attributes for various properties (especially for custom attributes, since dictionaries are not directly supported by .NET attributes).AspNet.Navigation
to tell it to release at the end of the request.In essence, this means that the current SiteMap
structure can be made into a very simple Navigation
Model that the user doesn't have direct access to, except perhaps in the Navigation Controllers. We could go on using something similar to our current cache without running into scalability problems because it will not usually contain more nodes than there are action methods in the project. The request caching part (and the confusion that comes with it) can be eliminated. All of the internal IsAccessibleToUser
code and references to HttpContext
, ControllerContext
, and RequestContext
can be eliminated. Most of the FindNode
methods can be made into extension methods that are specific to an MVC stack, just leaving a simple one that passes in a facade interface that can be used to wrap the RouteData in each stack's extension methods. Nearly all of the internal things that SiteMap
and SiteMapNode
now do can be put into external filters, making them nothing more than "dumb" models with some extension methods to do some of the more complex stuff.
All of this means we will be able to eliminate some of the thoughts from my original comment and prior the list of issues about vNext. So as you can see below, this actually eliminates some work (especially on those overly complicated file streaming (no. 2), business rules (no. 7), and cache chunking (no. 24 from the list of issues) ideas that I had dreamt up previously).
In addition to the remaining open issues (which mostly can be closed with the above work), there is another list of issues that need to be addressed (some of which have been addressed in the above lists).
I think nobody would mind that he had to use old partial views inside MVC6, if it'd mean that a new release would roll out for it - just to make MvcSiteMapProvider usable on MVC6 in the first place (so basically "just" switching to new interfaces while getting controllers/actions). Other enchancement could wait...
@all @hidegh just fyi, if you need something that works today for asp.net core, I have a navigation/sitemap solution that is working well in my projects and lots of other people using it too https://github.com/joeaudette/cloudscribe.Web.Navigation
Any head way? I don't even want to contemplate Asp.Net Core until there's a solution for this library. I just love this library too damn much and I've put a ton of work into the integration with my system.
Unfortunately none at this time :-/
How about a more generic .NET standard support?
Also wondering what effect might bring splitting rendering code (partial views / components) from the "Core" functions...
Anything? Does anyone know of a good alternative to this library? I don't require anything super complicated.
@toddca did you look at this? https://github.com/cloudscribe/cloudscribe.Web.Navigation
Hi, Now that Visual Studio 2015 RC is available, I've begun working on porting an application to MVC 6 and .net core framework.
As my app currently depends on MvcSiteMapProvider, I'm wondering if you guys are planning to support MVC 6/.net core framework, and if so any idea when a NuGet will be available for that?
Thanks, Joe Audette