I've often developed websites in asp.net webforms with an administration area which is always a folder in the root of the application, where the site also lives. Which will always be compiled into one dll, meaning every small change requires full re-build of a solution - it just doesn't work well.
This is quite a lengthy question so my summary is at the bottom, but I've tried to give as much information as possible to help.
So at the moment things are set up something like this (you should get the idea):
¬ Application Root
- /MyAdminPanel
- dashboard.aspx
- /website-css
- site.css
- index.aspx
However I've recentley starting developing our sites with ASP.NET MVC and using multiple projects in a solution, like:
¬ Solution
- ClientName.Core
- ClientName.Models
- ClientName.CMS.Services
- ClientName.CMS.Web
- ClientName.Services
- ClientName.Web
the .Web projects being the CMS and front facing websites.
Is there a better way for me to structure my IIS applications bearing in mind that 99% of the time there will be an administration area for the website?
There are concerns regarding resources that are uploaded through the administration panel that need to be accessed via the front facing website, so essentially out of the child application and into the root.
This is possibly by doing Server.MapPath(string path) as that will go to the root application, however depending on how things were set up, it could potentially not be guaranteed that the root application is where the file needs to go (for instance if both the front and admin facing sites were both in separate virtual applications).
I'm thinking about the situation here if using HostingEnvironment.MapPath() where the path would actually resolved to the /MyAdminPanel child application, which would obviously not be correct.
Summary
In essence, to cut a very long story short, an ideal situation would be to have a VS solution as mentioned above, with a similarly structured website (though I am more that happy for this to change to something better), where I can MapPath resources to the front facing website and not worry how the website is hosted.
One thing that is important though is that I can build and maintain the projects separately, as some administration will have different functionality from one client to another
If you can come up with a much better structure for all of this, I am more than happy to listen! :)
Thanks for taking the time to check this out.
The solution is elegantly simple -- you really only need to worry about mapping 4 paths here -- just write some utility methods that can:
map a path from the public site http root
map a path from the public site filesystem root
map a path from the admin site http root
map a path from the admin site filesystem root
You'll probably want to make these configuration driven, or at least overridable as this will change in production quickly in scenarios that don't really allow for "rebuild and redeliver software to client" in the timeline.
Related
I've created an Orchard Website that consists of many mini-websites made operable via theme selection relating and triggered by the current [unique] URL all from the same DB.
It works as I'd hoped, but I wish to improve the Autoroute paths of my pages.
Currently I'm using:
{Content.Fields.PageOrderPart.SitesTaxonomy.Terms:0}/{Content.Slug}
Which results in:
www.site1.com/sitealpha/gallery
www.site2.com/sitebeta/gallery
What I would like is:
www.site1.com/gallery
www.site2.com/gallery
However, I still need to be able to differentiate pages with the same name [...hence why the Autoroute path above was created in the first place] - or I will obviously get permalink duplication errors.
Can anyone think of an ingenious way to sort this or is there some Orchard feature I may've missed, perhaps url rewrites or possibly an existing MVC method?
Many thanks for your input, PP
Further thoughts (hopefully this doesn’t influence any other member's sugestions):
Rewrite rules: Probably aren't dynamic enough for the amount of content I have [still increasing] - and I could see any alterations to existing permalinks being a real nightmare.
Besides, for an unkown reason - I and some other Orchard users - can't seem to get a rewrite action to work?
Routes: Honestly, I haven't played with these properly - I can see that capturing and dissecting a URL to stipulate the area / controller / action should be easy enough - but I'm not sure how to go about redirecting to a particular Orchard page?
FilterProvider, IActionFilter: I tested this scenario [which could become quite complicated code wise] and I'm not sure the performance is acceptable -- my dev system seems to really suffer with any code in the 'OnActionExecuting' method.
Update: I've investigated the IActionFilter scenario and it appears my initial performance worries were unfounded [i.e. a fresh install didn't behave any slower with some URL restructuring code on the 'OnActionExecuting' method].
My last hurdle is to discover why IIS Rewrite rules aren't working with Orchard:
https://stackoverflow.com/questions/35226580/orchard-cms-iis-rewrite-rules-do-not-work-for-rewrite-action-types
It could be that multi tenancy would be the feature you are after. You can have one code, one db but they are all completely separate sites. So separate admin areas etc.
http://docs.orchardproject.net/Documentation/Setting-up-a-multi-tenant-orchard-site
I would like your guidance on this.
I'm trying to build a website that has two "players" (which, I assume can be translated to "roles"?). One player is "consumer" and the second player is "supplier".
Both are interacting through mutual (sql server) database.
Now I would like to have totally separate systems each player, with totally different authentication mechanisms.
However, I would like to have the consumers system as sub-domain of the main domain, i.e., I would like to have the consumer system under 'mydomain.com', and the suppliers system under 'supplier.mydomain.com'.
However, I can't figure out how to technically do this? Can I create another web project in my solution, call it 'suppliers' and let it include all the features of the suppliers system?
Or should I create separate controllers for the suppliers features inside the main project?
The first option sounds most "clean" to me, however, how can I route the user from the main (the consumers) website to the suppliers website based on the subdomain?
If I choose the second option, how can I make sure that user which authenticated as customer will not be able to perform as supplier?
This is probably very common task to do, any good tutorial or example for this?
You will create two separate IIS applications - one for your consumers and another for your suppliers.
You will then set the host headers on each to your required domain and subdomain. IIS will then take care of routing URLs to your separate applications. Instructions for setting IIS host headers here https://technet.microsoft.com/en-us/library/cc753195.aspx
As for managing application code, given you want complete separation I would suggest creating three Visual Studio projects:
Web application for consumers
Web application for suppliers
Class library of shared code - database logic etc
You are then able to develop and deploy each web application independently.
In terms of tutorials, there is quite a lot available, here are a few which will help you:
https://web.archive.org/web/20211020150710/https://www.4guysfromrolla.com/articles/122403-1.aspx
https://www.simple-talk.com/dotnet/.net-framework/partitioning-your-code-base-through-.net-assemblies-and-visual-studio-projects/
https://softwareengineering.stackexchange.com/questions/207101/managing-multiple-projects-that-share-code-customization
for this problem, so use "Area" =
https://msdn.microsoft.com/pt-br/library/ee671793(v=vs.100).aspx
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.
I am working on a Turbo Gears 2 application. The application directs a user through a set of questions. I like the templating system of TG2 (which of course is the idea) so I want to integrate the static web pages with TG2 also. This will allow me to abstract away the headers, sidebars, navbars and footers.
Please note that I am not talking about placing my 'static' files in the public directory of the application. I created a Controller called WebController and I am serving files through that. Of course the instance name of the controller is web so all my pages are accessible at the URL http://mysite/web/page1.html (for example)
Now the question - is it possible to have all pages at the root level be redirected to /web. That way I can eliminate the /web in URLs for HTML pages.
Thanks for reading.
Ok I realize that my question was somewhat vague. After doing some research on my own, I found out that TurboGears does not use routes by default but uses CherryPy dispatching scheme. http://nxsy.org/unscientific-and-biased-comparison-of-django-pylons-and-turbogears was very helpful in understanding some of the high level architecture of TG.
I rely a lot on stackoverflow to solve my problems as I make progress in my application - so, here is hoping someone else can benefit by reading that discussion.
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.