Can anyone help me in working with (multiple)WebUserControls.
I have tried, but I am not clear with the events which we have to use.
The most important thing to understand is the ASP.NET Page life cycle. Once you learn the order of operations for how an httpRequest is received into ASP.NET and how the httpResponse is built and returned you have the essential information.
This might answer your Q sharing controls across multiple websites
check this too
Related
I have two projects. One is an ASP.NET Mvc, and the other is a Web API.
The main project is the Mvc one. But I need to redirect the request to the Web API. All posts about it make clear that in order to redirect to another project, it should be a Redirect to an URL:
return Redirect("http://localhost:54270/"); //This calls the Get action in the Web API
But the problem is that I'm using an Authentication in Mvc that I would like to be validated in the called Web Api Action. Is it possible?
The session is not the same, so I cannot retrieve this information. Is there any way to share the same Context between both running sites? Or is it the wrong approach?
Yes, it can be done. In webforms, you can set the keys to hash values to the same key in multiple applications. As long as they are in the same domain, that is all you have to do. I have not tried it in MVC, but the internals are very similar. This is a bit of a kludge, but it works nicely.
In this simple way of doing it, you cannot share information, just the high level session information. As I have not played with this in MVC, you may have to set MAC settings or similar to get it to work. I don't have time to look this up. When I found this worked, the developers were still thinking in the ASP world, so they had a boatload of crap in the Session object which we had to sync up. You should not have this issue.
This method will not share the contents of session, but that should not be an issue if you are using MVC correctly.
If you want to go beyond this, there are ways to set up a single sign on mechanism. Anything that works for ASP.NET webforms should work in MVC, although you may have to add some code for items that would not normally be set in MVC that are required for webforms.
If you want a deeper understanding of the way it works, I would look up how people shared state in ASP and ASP.NET, as these pages generally have more information.
Dumb question (maybe) I have searched online but I'm looking for somewhat a yes no type of answer. If you ever see a website with just xxx.com/xxx.aspx ... was that application created using Web Forms? Is ASPX only associated with Web Forms?
Thanks
To answer your question in yes or no (as asked), NO.
You can do that in ASP.NET MVC as well, by setting up the routing in that fashion. But I don't think anybody would do that.
On another note, if you have come across a website which is xxx.com/xxx.aspx, you can make a decently good bet that it was developed in ASP.NET WebForms.
Hope that helps!!!
Technically no. The web server software determines how to handle every request. It could be configured pretty easily to say that any requests for a file with a .aspx extension should be handled by the PHP parser, or Ruby, or whatever. Or, if using ASP.NET MVC, you could set up routes that resources that end in .aspx are still handled as MVC pages.
Of course, there aren't many reasons that someone would WANT to do that. The only reason I can think to do so would be if you're explicitly trying to make people think that a page is using a different technology than it is. And I don't see that being a common goal.
I have seen that ASP .Net Code Behind files are really slow. I have used local web services which I call from jquery ajax function and they are fast. But I am still confused? Should i display dynamic data from code behind or web services?
I let my web service return a JSON Object and I assign relevant elements from that JSON object to different html elements like (image, div etc.)
You need to weigh several things..
If you are dealing with a low-traffic, internal web application, perhaps server-side postbacks are the way to go. Often you'll find that there's less code you'll have to write in this case.
If you are working on an external, public, high-traffic web application, perhaps AJAX is the way to go. That way you avoid posting back entire ViewState and running through the full page lifecycle. This may result in more front-end code, but is less load on the web server.
Keep in mind that client-side data binding is a very viable solution these days, with the help of such things as jQuery Templates. So that helps bind data returned from AJAX calls to tables and other elements.
As far as web services go, they are great for when you're sharing data/functionality between different systems. If you don't foresee doing that for this particular application, then perhaps there's no need to over-engineer it - keep it simple with either MVC and Action methods that support AJAX calls out of the box, or get familiar with PageMethods.
I'm sure there are other pros/cons I haven't mentioned, but this is the first thing that came to mind.
ASP.NET classic life cycle and postback is the base of Microsoft Click&Go philosophy. It is not designed to be fast even if it suits in most cases.
AJAX plus Web Services architecture is good way to improve server performances and dynamicity. It may not improve client performances, may increase the network load if bad designed and complicate a website architecture.
Another possible orientation is ASP.NET MVC, where old life cycle and postback is ancient history.
Like Kon said, mixity is probably the best way at the moment : MVC+AJAX or ASP.NET+AJAX where classic client<->server requests are used for common functionnalities and AJAX requests brings dynamicity with small requests for friendly functionnalities.
Note that most users on the planet are using Internet Explorer who have the worst javascript engine on the planet ;)
Can anyone suggest me good reading materials on the internals of how ASP.NET handles page postback and events?
-Justin Samuel.
I would absolutely read Microsoft's primer on the ASP.NET page lifecycle. Knowing the page lifecycle well will save you many headaches!
Please see How postback works in ASP.NET:
In this article, we will take a closer
look at how ASP.NET pages post back to
themselves, and how to customize this
feature in our web applications.
If you are just learning ASP.NET, check out ASP.NET MVC as an alternative which will make a lot more sense coming from other web platforms and doesn't have the added abstraction of events, state, and postbacks which http wasn't exactly designed to have.
Try to read these articles:
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1045191.html
http://www.w3schools.com/aspnet/aspnet_events.asp
http://www.dotnetspider.com/resources/15190-ASP-NET-Page-Life-Cycle.aspx
A little setup:
Our shop has a mixture of different platforms. Almost all of our web development is done in classic ASP. We have a WinForms application in development that is being written using the .NET 3.5 framework.
The problem:
I am writing a webservice for updating information to this enterprise application. Most of the classes and business logic also pertain to the WinForm application. On top of this, there needs to be a way to maintain some data on a website. Because we use classic ASP, I have decided upon using a generic HTTPHandler to make posts to. I use an ASMX webservice to query since I get XMLSerialization for free. However, I know this is not the normal use of a Handler and can't help but think there is a much better, short of converting a bunch of stuff over. Doing just this much is quite a bit more work than the project timelines allow. Can anyone offer some insight on this topic? More generally, how have people converted from classic ASP to ASP.NET? We are not a very large shop, so I think we're going to have to take it incrementally.
As a follow up to this question, I am finished with the roll out of this project and it is working pretty well. The AJAX portion was pretty easy doing it this way. However I never got ternary operators to work in my handler page and I'm not sure why. This resulted in first checking the HTTPContext to see if the control I was trying to read was actually there, and if it was, taking in the value from it. I suspect I did something wrong but for now I'll have to move on and refactor later.