Is it a good design to have multiple masterpages in an application.
I am building a website using Asp.net MVC with different type of users like, admin, employee, general user, etc
And every user once logged in have different type of controls on the website, so I was planning to use different master page for each user.
Yes it is a good design, and make sure to layer them appropriately. Master pages specific to controllers should be placed them in the appropriate view folder.
If it makes life easier for you and your users, than I see no reason why not.
I don't know how about Asp.net MVC, but in Asp.net master pages inheritance is possible. You may create site.master, and admin.master, employee.master, etc that all inherit from site.master.
But take care of master pages inheritance. In my project, it seems that sometimes paths may point to wrong locations. I don't know whether it is my mistake or is a bug.
Related
I'm just starting to convert an existing ASP.NET Web Forms website to ASP.NET MVC. However, MVC seems excessive for some pages. ASP.NET Web Pages seems like a better fit for simple pages where the benefit of MVC is unclear.
If I use ASP.NET Web Pages for some pages and MVC for the rest, what difficulties will I likely encounter that would not occur if MVC was used for every page?
Here is one difficulty I am already aware of: Web Pages and MVC cannot share _Layout.cshtml.
EDIT
The content above was heavily edited to clarify the intent of the question.
I did a little research into this and now fully understand the scope of your question. Sorry, it was my mistake for thinking you mean Web Forms and not the relatively new Web Pages.
Any answer anyone gives here will be pretty subjective, but my take on this is to go ahead and stick to the MVC method instead of mixed modes. It appears that Web Pages is a razor based HTML file without a controller/action associated with it. If that is truly the only major difference / reason for your question, then it seems the extra three lines of code it would take to make it MVC...
public ActionResult StaticFile(){
return View();
}
actually will make it a) easier to add dynamic data to in the future, b) more directly ties into routing (no special routes for static for example) and c) easier to interact with the server-side if you have to do any kind of authentication, session tracking, etc, etc. Anyways, my 2 cents. Go the way that works, but keep in mind the trouble/frustration of future modifications as you go forth with your site. I post this opinion with the admission of never having used Web Pages, just a few hours of reading about them.
The biggest pain is the maintenance of a Master Page and a __Layout view. That being said I am with Tommy - why not just make these static pages html files and not aspx pages.
I decided to abandon ASP.NET Web Pages and use MVC exclusively on my website. The primary reason was because of the duplication of effort for things that could not be shared between Web Pages and MVC. Here are some things I learned.
Web Pages and MVC could not share _Layout pages. I was able to work around this by moving shared content into sub-layout files that the Web Page _Layout and MVC _Layout files could share.
Forms authentication was no problem.
I was not able to figure out how to implement MvcSiteMapProvider in the Web Pages for breadcrumb functionality. (See this question.)
The MvcSiteMapProvider difficulty made me realize that it was just a matter of time until I found something else that could not be easily shared. Therefore it seems smarter to stay with MVC rather than taking a hybrid approach.
I have been reading on MVC and I created some db-driven pet projects with it and I am very pleased with the shift from WebForms.
However, I have a bit of a limitation that holds me back with WebForms and I was wondering if you could help me with it.
I work for a Web CMS company as a Consultant, therefore all websites (public sites, intranets, extranets, you name it) are based on the CMS software from my company (which should remain nameless).
One of the features that the sales guys like to pitch about our software is its "friendly" urls. Baiscally all data is stored and structured within the CMS like a file system. Then when you point your browser to http://mywebsite.com/about the CMS will return the contents from the item stored under the root with the name "about".
Each item also has a (interchangeable) template registration which is the physical location of the file that is going to display the contents of it (an .aspx page). Just like the "Views" on MVC.
To handle the friendly URLs I have to add a HTTP Handler as follows:
<add verb="*" path="*"
type="Cms.ASPDelivery.HttpRequestHandlerFactory, CmsDelivery" />
That will take care of the friendly URLs and will do the mapping between contents and views.
In an architectural way you could see that just like MVC. The data is stored in the CMS, the presentation is independent of the data, and the handler will be the Controller.
But when it comes down to coding in itself, it is the same old Webforms spagetti.
So, my question is: Do you see any way that I could use both MVC and my CMS' Http Handler?
It depends on the concrete Implementation of the HttpHandler but in most cases it is possible. You have to add the MVC UrlRoutingModule and setup the MVC. I use MVC in a CMS environment with friendly url-s. The CMS is called EPiServer and from what you described it has pretty much the same functionality. I use ASP.NET MVC for the template pages. The path to the physical pages is actually handled by controllers' actions. It works fine and with some tweaking I can say that it is a lot better than WebFroms especially if you develop custom web applications.
Currently, we have a site where almost all the pages fall into some page class that's a subclass System.Web.UI.Page. Generally the subclasses control styling -- headers, footers, etc. -- things displayed on that class of page that we want for all classes.
For one particular class, we check some session variables to see if the user has access to that particular page. If not, they get redirected off and told they don't have access.
I've since implemented a custom role provider and am in the process of updating all my web.config files from to .
The question has arisen: Why not implement the page-based restrictions in the page class instead of implementing a role-provider methodology.
Honestly, when I first considered this topic, it seemed to me there was a clash between and having page classes do the authorization. However, I'm having a difficult time coming up with reasons why page-class based authorization would be a bad idea right now.
If you're able to understand what I'm talking about where we set access (authorization) info during the login process and then use this (session based) information to "authorize" a user to access a page based on the page-class vs using the built-in ASP .NET role provider methodology, I'd appreciate your thoughts on this matter. Especially if you have experience in this area.
Thanks.
Well both ways are possible, IMHO, it comes down to whether you want to use the ASP.NET authorization scheme (allows, denies in the web.config) or code it into the page.
Personally I prefer the configuration approach, as it is more flexible and allows for the pages to inherit from another page class, or use master pages to provide for a common look and feel.
What I need to do is create a web application that can run inside SharePoint. It needs to be more involved then a web part and include many pages and a database. I know you can create a SharePoint application that goes under the Action bar, but I would like to create something that is run like how a site is. I would want a few tabs to show different sites, each running the same application, just showing their own data.
It looked like creating a site definition would be the best route to achieving this, but I have not been able to get it to become like an ASP.Net Web Application. Anyone know of any other project type or method that can be done to develop an ASP.Net Web Application that simply shows up in SharePoint? I know I can do it in a page viewer webpart, but that just seems like a cheap hack to create an IFrame and not the optimal solution. I don't need any true integration with sharepoint, other then using it for Authentication and a display mechanism. Our corporate intranet is setup using SharePoint, so anything that I build has to exist within it.
If anyone has any guidance, I would love to hear your suggestions.
Thanks!
It's actually pretty straightforward, at the basic level:
Create your ASPX pages with codebehinds in your own assembly - just like normal.
Use the Sharepoint master pages (look at the existing ones to mimic their styles and markup)
Create a Feature which adds a link to your "entry point" page(s) to the SP menu
Deploy your assembly to the GAC
We would like to have several internal web applications which use the same master page. Is there a way to store a master page in a common library referenced by all projects?
You can do this, but it is difficult and has quite a few drawbacks.
This process is similar to packaging up user controls as well. Basically you have a web application project that contains your master page. You can precompile this into a set of dlls using aspnet_compiler.
then you can use ilmerge.exe to put them all into a single dll that you then reference from your other projects.
You still need to have the markup in order for your pages to render properly in the designer, so you'll probably have to investigate VirtualPathProviders as well.
It's a kludgy solution and it has many drawbacks.
I've heard this works, I haven't tested it.
Create a separate project to house your master pages, since all master pages are like user controls and built into their own separate assembly. Run the build and try referencing the assembly of the master page.
Again, not tested, just something I've read before.
G'luck with it!
Given that these modules are part of the same web application, you should look at this approach:
Basically, you have one root web, which is set up as the(only) IIS web application.
You may plug in new web modules by creating ASP.NET Web Application projects and place under the root web, physically.
Set the build directory to root web's bin, eg. "..\bin". Don't create a IIS application/virtual directory.
Thereby, each web module compiles into its own DLL, which is itself a good thing.
When compiling, it is "merged" with the root web.
It is a great way for sharing master pages and user controls, and have different parts of the web site in different projects/assemblies.
Master pages and user controls will even work in design mode.
Hope this helps
Sharing master page across the application
Enjoy.. :)