I'm learning the difference between these to concepts.
I want to build a public Sharepoint site, and is one better than the other for this use, or is it too general of a question?
At a very general level; application pages are stored on the web server's file system (also known as the "12 hive") and run in a more priviledged security context. You tend to use these to create administrative interfaces.
Site pages (such as default.aspx) are user-targeted, and available for customization via SharePoint designer.
Site Pages can contain one or more webpart zones each zone may contain one or more webpart zones.
Site pages can customized
Site Pages not supprot code behind file.
Application pages such as Create.aspx,Themeweb.aspx.
Application pages Can't customized
Application pages support code behind file.
Site Pages:-
Site Pages are Site or Web Scoped,
User can customize Site Pages,
Site Pages are stored in Content Database,
You cannot have custom code in Site Pages,
Site Pages are Un-ghosted Pages.
Application Page:-
Application Pages are farm scoped,
No customization can be done by the user,
Application Pages are stored in WFE(Web Front End) in _layouts folder,
You can have custom code in your Application Pages,
Application Pages are Ghosted Pages.
Related
I have inherited an existing ASP.Net MVC C# web application solution.
Currently, there are two separate Web Application projects.
An Admin site - used to managed the content of the public facing site.
The public facing site
Currently, the public facing site is not in production; only the Admin site is deployed on Windows Server 2012 running IIS 8.0 using the client's domain e.g. www.mysite.com
The client would like the public facing site and the admin site to be accessibile via the same domain:
Public: www.mysite.com
Admin: www.mysite.com/admin or admin.mysite.com
Is there any way to achieve this given the two sets of functionality are currently encapsulated in different Web Applications?
I'm wondering if:
Is there a way to achieve the above with sub-domains or some other feature of IIS
Or if its best to move all the Admin functionality into an MVC Area within a single Web Application
Discussions on the pros/cons of each approach (or links to resources) would be most appreciated.
I would rather move admin site and public facing site in single web app in separate area as OP said.
You can use host-header facility in IIS to adjust root domain url to admin.mysite.com (or such).
advantage of such approach is maintenance will be easier as code base is part of single vsnet solution, Assuming public facing site will have lot more content/controller/views and admin site will have less of those, there is no point in maintaining separate .SLN for admin.
I have a webapp running as an Azure website on http://www.example.com
I have controllers for www.example.com/signup and www.example.com/signin - all other stuff is put on subdomains, like username.example.com.
My question: is it possible to have another (azure) website running on http://www.example.com? E.g. with all the marketing pages etc.
Ideally I would like to give access to that second website to an external webdeveloper so that I don't have to worry that the webdeveloper have access to my main app.
Additional question: would that second website have to be asp.net? Could it be PHP? (e.g. a Wordpress site)
You can develop child projects within Azure Websites check here : A single web project hosting both the web pages and API
One web project for the web pages, and another for the API, deployed to different websites on different servers
One web project for the web pages, and another for the API that is deployed to the same servers as an IIS application (/Services). http://blogs.msdn.com/b/tomholl/archive/2014/09/22/deploying-multiple-virtual-directories-to-a-single-azure-website.aspx, not sure if it can use another platform.
I am developing a web site using ASP.net MVC. There are pages that are locked down and are only accessible by logged in users. If the user isn't logged in when trying to access these locked pages, then they are redirected to the login screen.
My question is, can search engines crawl these pages even though they are locked down to authorized users? If they can, should I be adding the meta tag rel="nofollow" or is there a better solution in MVC to block whole folders and its contents from search engines?
No the secured pages will also deny access to any search engine crawler.
the google bot will not be able to load the HTML in side the secured pages, however if there are links from the site to the secured page and if its loading the HTML, that could be index by google.
I have seen my websites only shows path as below when you navigate to different webpage or items in that website while when i created the website i have to create a webpage for everything & it do show the path with file name like .php while other websites only show a path even though it navigate to new page.
This is known as URL routing. The developer has configured the webserver (or web application) to map specific URL paths to individual webserver pages (.php, .aspx, .mvc, or whatever). There are different ways of achieving this, depending on the webserver platform technology, but it is generally achieved by configuring a url route map of some kind. There are several advantages to organising a website url's in this way but mainly it makes URL's more consistent and easier to understand for users, and hides the details of the website's underlying implementation.
I have a CRUD application written in Classic ASP (not .net) which transfers (routes) page requests to relevant servers using a loadbalancer DLL.
It works like this:
Someone requests for www.mywebsite.com/products
There is an index.asp under folder products that redirects the request to either:
http://www1.mywebsite.com/products
or
http://www2.mywebsite.com/products
based on a loadbalancer logic.
Another scenario:
Someone requests for www.mywebsite.com/products/details
There is a index.asp under the sub folder details within the products folder that redirects the request to either:
http://www1.mywebsite.com/products/details
or
http://www2.mywebsite.com/products/details
based on loadbalancer logic
The main issue with application is whenever I include a new page, I need to create a folder and index.asp page to redirect the page.
We have a CMS database which contains the details of all pages. So I want to create an MVC application to replace the existing Classic ASP application.
But I didn't find any database driven MVC applications and I'm bit confused by routing. Do I need to create a separate route for each main folder I have or should I create a generic route for all pages.
Any help would be appreciated.
You don't have to migrate to ASP.NET MVC just for the URL rewriting.
IIS 7 does have an integrated URL rewrite module and ASP.NET 4 includes routing as well.
IIS URL Rewriting and ASP.NET Routing
URL Rewriting in ASP.NET
Anyhow, if you search e.g. on Codeplex for ASP.NET MVC projects, you'll find a lot of them which are database driven.
You don't need to create individual routes for each seperate item. Think about the concept of querystrings (?id=15&day=monday). URL rewriting is pretty much the same.
Update
I've overseen that your talking about classic ASP.
The build in URL rewrite module in IIS 7 works also fine with classic ASP. If you are having an older IIS version you need a 3rd party ISAPI rewrite module.
Anyhow, switch it to ASP.NET MVC ;)
MVC would lend itself very well to sorting your routing problem. So would ASP.NET 4.
However, the problem you have is that you don't know enough to ask a precise question. Hence your confusion with routing in MVC.
I would therefore suggest reading the nerddinners tutorial. You can get a PDF download for free. To go a step further, read Stephen Sandersons book on MVC 2 (or MVC3 in a couple of months).
If you follow the nerddinners tutorial and Stephen Sanderson's tutorial, that will give you a better idea of how it works.
In short, this is how MVC works:
In MVC, you forget about files and folders.
Instead, you have Controllers and actions. The routes map the requests to the right controller and action.
The code in the actions then decide which View to stuff full of data (from a database or wherever, it doesn't matter). The Views are just templates that are told what to do and what data to display.
The Controllers ask the Model for the data that they want.
Ie, the data access is all done in the Model, neatly separated from the User Interface.
M: Model
V: Views
C: Controller
The above is probably meaningless to you. It is a VERY different mindset to ASP classic.
If you are coming from old ASP, you will have a long hike, but it can be done. I came from Access. Anyway, read the books, follow the tutorial and see if it is for you.
When you are ready, we will still be here to help with more precise questions.
Asp.net MVC routing in your migrated application
Based on requests you've shown here you can sort everything up with just default route:
{controller}/{action}/{id}
In your case you'd have a ProductsController with all the actions you need.
Load balancing application
But having an Asp.net MVC application is just one part. This application will run on both load balanced servers. All redirecting should be done before they hit the MVC application.
If you intend to continue using the same loadbalancer DLL you could create a different Asp.net MVC application with only one route definition:
{*path}
and a single controller and action that does it all:
public Load: Controller
{
public ActionResult Balance(path)
{
// decide for web server and attach path to subdomain
}
}
This should do the trick just fine as long as the overhead of this action is very small. Otherwise your load balancing logic will become the bottleneck of your application since all requests go through this load balancer (it does that now as well so bare in mind this is no different now; never mind the authentication process on different subdomains you may be using).
Load balancing alternative
You should consider using the web farm balancing capabilities on the IIS 7 that will run your application on several web servers (because that's what your load balancing does in the first place). Search the web for web farm information. You can start with this:
http://www.iis.net/download/webfarmframework