I am using basic asp.net web application project template, because I want to move away from MVC into SPA.
Most of my pages will just be basic html files that will interact with the server through ajax calls. That said I want to hide the .html extension, but I don't want to create controllers just to hide this, which is too much of an overkill.
Of another note, I am using Azure as well, so setting this up on IIS directly is not going to work, as I would not be able to scale the administration nicely.
So how can I hide the html extensions without such a heavy layer as an MVC controller?
This sounds like a job for Url Routing
Url Routing allows you to intercept a request and then determine how to service it. It is how MVC does it and has many other useful benefits. If the router isn't able to service it, it falls back to the default ASP.NET pipeline processing, and then IIS.
Related
I'm new in ASP.net MVC Single Page Application (SPA). I want to design a system that using SPA concepts.
However, I have a bit confusing on how a system consider design in SPA concept? Is it the system URL must always same although we perform many activities or don't have back function (browser) as it always in one page because only render the necessary HTML part? I did googling on this, still have no idea. Does anyone can explain in more simple way?
Thank you.
One of the main advantages of having an SPA is that because you only have one page and you load all the data at once (or make multiple AJAX calls in the background to get data on demand) your application gives an illusion that there is no post back to the server, making your web application seem like an app.
Using SPAs can potentially improve the user experience of your application.Site speed can be improved but you might have to make a user wait a few seconds to load all the initial data.SPA's are great for touch screen appications, such as kiosks and touch based Point Of Sale systems where the navigation is 100% controlled by the SPA.
SPAs also have a lot of disadvantages like implementing the back navigation in your site.In traditional websites this is not a problem but in an SPA you would need to make very clever use of javascript libraries such as Backbone.js or Angular.js to mimic this functionality.Also search engine functionality of public sites and analytics may be a problem.If your are writing a huge enterprise type of application, you may encounter performance problems.
I would stronly recommend reading Disadvantages of Single Page Applications before you make a decision on whether to use them or not.
A SPA can still have multiple different URLs.
In this case, the server that is hosting the application needs to be configured to direct all paths for a URL to the main index.html page.
The index.html page will load the initial part of the SPA, and if it sees there is a path on the URL beyond /, then it will load the "component" for that path.
A "component" as described here might consist of HTML, JavaScript, and request any data that is requested from external APIs.
Angular is a SPA framework that has built-in support for loading components based on registered URL paths. There are other SPA frameworks, as well.
Can I have a ribbon button launch an aspx ( asp.net ) page? The aspx page needs to inherit authentication and authorization as the logged in Dynamics user.
You can execute custom JavaScript from a ribbon button allowing you to spin up a new browser window pointing at whatever you like.
To inherit security credentials you need to look at setting up federated authentication across both the CRM server and the custom website hosting the ASPX. As you can probably imagine this isn't a trivial task.
You could also look at dropping your website into the custom ISV folder as was the case with CRM 4. However, this approach has been deprecated in CRM 2011 and AFAIK is therefore no longer supported.
As #Konrad pointed out you won't be able to use the Data Service REST API (OData) from your custom web pages as the service is only accessible from web resources hosted within the CRM environment. Server-side you'll be fine against the Org Service.
If you can get away with doing what you need in a web resource I'd highly recommend it as it's a whole lot less work.
I'm not sure you can do that. A while ago, I put in an iframe that I linked to an outside web page and it worked as supposed to except for connecting to the organization data. I just couldn't make that work (I got impatient, to be honest and didn't try all too hard).
The resolution I deployed in the end was to run a web resource, which was run internally on the server, that communicated the data to an outside service.
I'm assuming that the same behavior will follow if you try to open windows/convey data in to/out from the CRM.
I need to implement route mapping in asp.net web application. there are many tutorials telling how to do it in mvc. but i need to do it in web pages.
I have done it successfully for parent domain. my website also handles fake domain(wild card dns) as well, I need to map routes for subdomains as well.
http://mysite.com/login is mapped to http://mysite.com/default.aspx
but , now i want to map http://login.mysite.com to http://login.mysite.com/login.aspx
and http://signup.mysite.com/ to http://signup.mysite.com/signup.aspx
any idea how to do it?
Are you sure you need routing for this? It seems your just want redirection which can be handled by IIS or web.config.
If you really need routing, there are plenty of articles on both MVC as well as web forms, just search. In MVC you do it using the RouteConfig.cs file and in web forms you do it via Global.asax.cs file (or some helper referenced from global.asax.cs). Basically in web forms you add your routes to the RouteTable.Routes collection.
The code will look something like this (untested):
routes.MapPageRoute("",
"login",
"~/default.aspx");
Here are a couple of links which can get you started on routing:
Walkthrough: Using ASP.NET Routing in a Web Forms Application
RouteTable.Routes Property
Many hosting companies let you define which page will be shown to the user if the user goes to a page that does not exist. If you define some .aspx page then it will execute and be shown.
My question is, why not use this for routing. since I can parse the users URL and then do a server.transfer to the page I want. I checked and there is no redirect sent to the client and the http headers are HTTP/1.1 200 OK.
So, is this a good idea for servers that don't have ASP.NET 3.5 SP1 or if you are not using MVC?
Thanks
You "can" do that, but why not just create an HttpModule and handle the routing there? That's how most of the URL rewriting systems work (in actuality, it's also how the MVC routing works since global.asax is just a pre-build HttpModule with a few extras).
The big thing with relying on that kind of server handling you describe is that you really aren't in control of it, and it is a hackish mechanism... by that I mean you are taking a function of the web server that has a specific purpose and design and laying a different meaning and function on top of it... which means you now have no built in handling for an actual 404 error. Plus, the mechanism you are contemplating is harder to adapt to your purpose than just using the other options available to you.
Unless you need something special from routing, you should consider using an existing routing component such as Mod-Rewrite or one of the dozen or so other popular URL rewriters that were built before the MVC routing engine was implemented and work fine in older versions of asp.net. There are also numerous tutorials on using HttpModules, HttpHandlers, and various other techniques to do routing in asp.net webform environments.
I was planning to use url routing for a Web Forms application. But, after reading some posts, I am not sure if it is an easy approach.
Is it better to use the URL Rewrite module for web forms? But, it is only for IIS7. Initially, there was some buzz that URL routing is totally decoupled from Asp.Net MVC and it could be used for web forms.
Would love to hear any suggestions..
This is the best article I found about this topic: IIS URL Rewriting and ASP.NET routing by Ruslan Yakushev.
IIS URL Rewriting
When a client makes a request to the Web server for a particular URL, the URL-rewriting component analyzes the requested URL and changes it to a different other URL on the same server. The URL-rewriting component runs very early in the request processing pipeline, so is able to modify the requested URL before the Web server makes a decision about which handler to use for processing the request.
ASP.NET Routing
ASP.NET routing is implemented as a managed-code module that plugs into the IIS request processing pipeline at the Resolve Cache stage (PostResolveRequestCache event) and at the Map Handler stage (PostMapRequestHandler). ASP.NET routing is configured to run for all requests made to the Web application.
Differences between URL rewriting and ASP.NET routing:
URL rewriting is used to manipulate URL paths before the request is handled by the Web server. The URL-rewriting module does not know anything about what handler will eventually process the rewritten URL. In addition, the actual request handler might not know that the URL has been rewritten.
ASP.NET routing is used to dispatch a request to a handler based on the requested URL path. As opposed to URL rewriting, the routing component knows about handlers and selects the handler that should generate a response for the requested URL. You can think of ASP.NET routing as an advanced handler-mapping mechanism.
In addition to these conceptual differences, there are some functional differences between IIS URL rewriting and ASP.NET routing:
The IIS URL-rewrite module can be used with any type of Web application, which includes ASP.NET, PHP, ASP, and static files. ASP.NET routing can be used only with .NET Framework-based Web applications.
The IIS URL-rewrite module works the same way regardless of whether integrated or classic IIS pipeline mode is used for the application pool. For ASP.NET routing, it is preferable to use integrated pipeline mode. ASP.NET routing can work in classic mode, but in that case the application URLs must include file extensions or the application must be configured to use "*" handler mapping in IIS.
The URL-rewrite module can make rewriting decisions based on domain names, HTTP headers, and server variables. By default, ASP.NET routing works only with URL paths and with the HTTP-Method header.
In addition to rewriting, the URL-rewrite module can perform HTTP redirection, issue custom status codes, and abort requests. ASP.NET routing does not perform those tasks.
The URL-rewrite module is not extensible in its current version. ASP.NET routing is fully extensible and customizable.
There's a great post here about the differences between the two from a member of the IIS team.
One caveat I would advise is that for WebForms, you need to be careful when using Routing. I've written a sample implementation of how you'd use routing with WebForms that addresses these concerns and hopefully helps answer your question.
Do you want formatted urls to be a factory for spawning pages?
or do you want to make the .aspx go away?
rewriting, is for making the .aspx go away, or just to tidy up the url.
Routing, is for looking at a request and determining which object should handle it. They sound similar, phil haack has a few good articles on the subject.
in iis6, isapiRewrite, is very good
I recently just wrote my own rewriting system to make the URLs on my sites look better. Basically, you're going to need to write your own IHttpModule and add it to your web.config to intercept incoming requests. You can then use the HttpContext.Current.RewritePath to change what you're pointing at.
You'll also want to configure your site to use the aspnet_isapi for everything.
You'll discover a lot of little problems along the way like trying to work with pages that use "tails" on them (like for PageMethods), or pathing of page elements and form postbacks, but you'll get through them.
If interested, I can post a link to the code and you can check it out. I've worked a lot of the problems out already so you can read through it as you go. I'm sure there are a lot of other people that have done this as well that might be good resources as well.
You may want to check out my answer to this question: ASP.NET - Building your own routing system. I include some good references to help build your own routing system with either using the url rewriting method or the new routing engine that you can use that came out of the ASP.NET MVC project.
The Dynamic Data project that is available with .Net 3.5 SP1 shows a good example of a url routing implementation.
For URL Rewriting on IIS, IIRF works in IIS5, 6, 7. Free. Easy. Fast. Open Source. Regular expression support.