I've created three related ASP.NET MVC web-applications that sit in IIS like so:
root
|-Emailing
|-InternalManagement
Where the root site is customer facing.
The three sites have different security requirements and I wanted to be able to modify one application with less worry about breaking the other two.
However both the root and the internal management site need to have links to the emailing site.
I'm using T4MVC.
Now I've separated the T4MVC helpers for each project by modifying the HelpersPrefix, and root and InternalManagement reference emailing so for example I can do something like:
Url.Action(MVCEmailing.CustomerDocuments.Index())
Which almost works - except the actual URL produced will be:
For the root application:
http://mydomain.com/CustomerDocuments/Index
for the internal management application:
http://mydomain.com/internalManagement/CustomerDocuments/Index
What I need in both cases is for the URL produced to look like so:
http://mydomain.com/emailing/CustomerDocuments/Index
What's the best way to go about doing this?
Copying from the T4MVC doc:
One key concept to understand about T4MVC is that it is just a thin
layer over MVC. e.g. while it provides strong typing, in the end it's
just putting values in a dictionary, and using standard MVC to
generate the routes.
One thing I often suggest when people have questions is to first
figure out how they would do things without T4MVC. If you have no idea
how it would work, or think it may not be possible at all, then you
are probably expecting too much of T4MVC! Generally, it will not do
anything that MVC does not support.
In your case here, I'm not convinced that you could do this with plain MVC, because each of the application does not have knowledge of the other applications' routes. And generally, I don't think that MVC routing can ever general links that go outside of the current app.
Related
My group is working on a new web application and is considering using MVC. However, there are members who would rather include pages than use master pages. Is this possible to do in ASP.NET MVC? In the small amount of time that I've poked around with MVC I have not yet been able to figure out how one might accomplish that.
Why the preference?
Having used both in the past, Master Pages are much easier to use. You just have to get over the (very small) learning curve.
ASP.NET MVC doesn't force you to do either one though...
If you like the Include method, then you would probably feel most comfortable using Partial Views to provide the same functionality. You would just add the Partial Views to each page instead of including another page.
No. It does not force you in any way.
You should really avoid server-side includes with anything newer than classic ASP. They're more difficult to debug, IIS has a hard time finding correct line numbers when there's a problem, etc. Also, I haven't looked at the order in which SSIs are processed in the request pipeline - they may not work at all with ASP.NET.
If you're moving into MVC, use RenderPartial() or RenderAction() instead. These perform essentially the same function as a server-side include, but are more inline with the spirit of the framework and provide some additional benefits, like passing models without having to declare a global variable (which should also be avoided, and I'm not sure if it is even possible under .NET scope rules).
And, no, master pages are not required, but you really should use them. Using includes to build your page layout works, but only if you don't and won't need to radically change the layout of your site at any point in the future. I'm in that boat now with a 350k line classic ASP app which used very nicely structured code and #includes to create the page layout. That was the best solution available at the time, but it's causing me a lot of headaches now (10+ years later).
With a master page you can move your ContentPlaceHolder blocks anywhere you want, whereas with #includes the final page really determines the format by the order in which the includes are placed. This also makes it pretty straightforward to create a mobile version of your site - you can create a mobile-specific master page and use the same content views.
Its a matter of choice,but for consistent look and feel across the web application, master pages give you just that. You have to take the team through the learning curve of good master page design, not only would it be useful for the current project at hand but also future projects. Good luck!
I would rather opt to go for Master pages due to the ease of use and built in support in MVC for this.
If you want to know more about it check out this tutorial: Creating Page Layouts with View Master Pages.
Grz, Kris.
This is a ASP.NET MVC beginner question (I'm in phase of developing NerdDinner)... I have assignment to create ASP.NET MVC cms (with its own design) and portal (also with its own design) that will display data that's being handled by CMS. I was wondering if I will have to make two individual projects in Visual Studio or I will have to use one project and place portal section in specific folder.
I know that my question is a bit premature (according to fact that I still haven't finished tutorial) but I'm bit impatient :)
On server (commercial hosting) I would use only one hosting account... this thing with URL routing is a bit confusing to me, CMS is practically also optimized for SEO.
I would like to the structure of URL to be:
---- PORTAL ----
www.domain.com
www.domain.com/Menu1/Submenu1
www.domain.com/Menu2/Submenu1/SubSubmenu1...
etc.
---- CMS ----
www.domain.com/CMS
www.domain.com/CMS/Whatever
Thanks,
Ile
It all depends on the functionality of the portal and the MVC cms.
For starters I would have a separate solution for the Model/Data Access that way you can have as many MVC projects without duplicating your data access.
From your desired url structure I would probably have the CMS as a separate controller and sub folder. Alternatively if your using MVC 2 you could look at the areas support which will probably give you a little more flexibility.
If you want the solution to be a bit more complex/flexible you have a number of options:
If both the portal and MVC cms are going to have he same functionality and page layout you have two master pages and determine which mater page to show when returning the view. You would specify this in the routing so multiple routes would point to different controllers.
If the layout/functionality differs slightly but one controller can still manage both you could have a separate controller project and two mvc projects which only contains the views, javascript and images so both mvc solutions look at your controller solution. With this option you would probable end up setting up two websites on your domain one under the root and the other under the CMS folder (in your MVC app you will prob need to block routes to /CMS so it will be processed by your CMS app).
Finally if both differ hugely have two separate projects but keep your common data access project, as above you may need to set up two sites on your hosting package.
I have an application that will support multiple sites. The site will be determined based on the url.
For example
http://myapp/site/abc123/...
and
http://myapp/site/xyz123/...
The site code will drive a lot of the functionality for example themes, available modules, etc...
Questions:
1-)I need to validate the site code is valid and if it isn't, it should direct the user to an info page. I was looking at using IRouteConstraint, is this appropriate? Are there other/better options?
2-)Any gotchas with this approach (using url to identify site)? Is there are better approach?
Solution
I ended up creating a Custom ActionFilter and check the sitecode in the OnActionExecuting event. That seems to work well and fit better than the IRouteConstraint.
The system I have implemented uses Urls to identify unique page content within a single site and the routing process is pretty straightforward. That being said, you may want to consider making use of Areas in your MVC application. With Areas you can have multiple sections to your website that all have their own MVC structure which can run semi-independently.
Essentially, you will have one base routing definition that lays out some defaults and then the rest of the "sites" will define their own routes pointing to controllers and views in a separate location. It's pretty easy to set up, you'll just need to make sure you're using version 2.0 of ASP.NET MVC. Here's a decent looking tutorial on ASP.NET MVC Areas and Routes. In the current model which MVC 2.0 supports you'll have a single Web project for each area, but that is not necessarily a requirement. Phil Haacked has some code for ASP.NET MVC Single Project Areas if you're looking for another example of the technique, although you, personally, will probably benefit more from the first article.
So long as you define good routes that have clear and measurable constraints, you shouldn't have too much trouble laying out the website you've described.
I ended up creating a Custom ActionFilter and check the sitecode in the OnActionExecuting event. That seems to work well and fit better than the IRouteConstraint.
I'm currently working on an asp.net-mvc content management system. It would be incredibly useful to be able to deploy nested applications e.g. /shop to have a separate app inside. Or even another instance of the cms.
I've found some information around talking about limiting the inheritance of the web.config but I've no idea how this maps to an MVC application. I'm hoping as its essentially the same stack it will just run. Nothing is ever that easy though.
If anyone has any experience doing this I would be really grateful. The idea of one big application to rule them all is not at all nice.
Si.
To be honest you biggest hurdle is going to be creating the routes and making sure they don't interfere with routes already in the system. After you get that working the rest is easy as pie.
The first thing you will need is an HttpModule that will be inserted in to the web.config under the . This module will be used to register and custom ViewEngines or Routes that you want to register. You do this in the same way that you do in the Global.asax but instead of putting them in the Application_Start you put them in the static constructor of the HttpModule. This is so they are only loaded once like Application_Start.
By do the above you will have created a module that is easily transportable and doesn't require the implimentor to modify their Global.asax code to get your stuff to work.
The second thing you probably want to do is create a custom configuration in the web.config to set stuff like the root path of your application. This will be prepended on to the route when you are setting it up in the HttpModule. Also you can use this to store customization information that is not appropriate for the database.
Last but not necessary is that you may want to create a custom ViewEngine that knowns and understands your folder structure. This is only necessary if you want to store the views in a different path than the default views, in order to minimize conflicts.
Check out the Grouping Controllers with ASP.NET MVC from Phil Haack.
Hope it helps,
Bruno Figueiredo
I've gone down this road before (with /blog), but found it to be doable but complicated and difficult to maintain. Instead I ended up using subdomains:
www.example.com
shop.example.com
blog.example.com
These are much easier to maintain because you can just have them work as separate websites in IIS. And, of course, you can always redirect www.example.com/shop to shop.example.com.
I need your advice regarding migration. I want to migrate existing project to ASP.NET MVC and I can figure out the proccess except of url rewriting issue:
for example how can I make following route:
http://www.eireads.com/ireland/mayo/cars-3/1263-used-cars-citroen-c5-for-sale.aspx
Or maybe I could somehow keep supporting legacy routes.
I think that migrating a web forms applicaiton to MVC is going to be very hard unless you have a clear seperation of concerns in your current applicaiton. If you have followed a design pattern like MVP then it might be easier, but if not then much of your business logic is likey going to have to be moved to controller classes and much of it re-written.
I would start by extracting your model, this should be fairly easy, then identifying your controllers and actions and seeing how much code you can re-use. At this point you should be able to discern whether or not you can migrate or if you'll be better off re-writing portions of your applicaiton.
Default URL patterns in ASP.NET MVC are http(s)://(appdomain)/(controller)/(action)/(par/ame/ters)
So your url above should fit into that pattern. You can change the pattern to account for other things (like namespace for example). Your URL pattern might be:
http://www.eireads.com/cars/used/ireland/mayo/citreon
where ireland, mayo and citreon are the in put parameters.
I think you should really re-write your question and try to detail exactly what you are attempting to accomplish here.
If you are asking how to migrate an existing WebForm project into ASP.NET MVC keeping the same URL rewrite, the answer is; not easily. The models are too different.
Yet, you mention "routes" in the end, which make me think you are speaking like those of the System.Web.Routing namespace. So are you dealing with an existing MVC app and want it too look like that URL path? I can't tell. I am confused.