I use update panels all the time when i wanna to update specific part of my page but recently i face performance problems ( i mean it 's slow in rendering the intended control and sometimes it doesn't work and need multiple click to work !!
so my question is :
Is the page method could be considered as an efficient alternative to
the update panel and do the ajax magic ?
What are the other alternatives?
please if possible a simple example to clarify how to replace the update panel using with page methods ?
I used to be like you some years ago, I used to use UpdatePanel to gain performance, to have the wrong idea I was increasing the performance of my applications...
Well I was totally wrong, UpdatePanel is the root of all UI-evil, first of all it hides the complexity of using AJAX which makes it easy for most of us, giving us the wrong idea that we are creating responsive applications, which is worst than if we weren't using it at all (that's the main reason I used to use it in all my pages, and I am sure that's the reason why many developers use it... 'cos it's easy).
Consider the following articles:
Why you should not place your whole site in an UpdatePanel
UpdatePanel is evil
When you understand what the UpdatePanel really does against a simple call to a PageMethod or a REST WCF Service, you will see the huge difference between them.
UpdatePanel. When you perform a post from an UpdatePanel, the whole page life-cycle has to be executed, this means, it requires to send all the page ViewState on each post, when your page grows in complexity with several controls, the ViewState will certainly be huge and this will certainly be a performance issue. Using them you only gain partial rendering, the controls inside your UpdatePanel will be rendered without a full post back although you need to send the whole ViewState on each request.
PageMethod. Page methods are static, they are called like if they were a service method, they do not need to create the whole page life-cycle in order to be executed, therefore, they execute faster.
So it would seem that using PageMethods would be the solution, the problem is that PageMethods are usually used to return JSON objects which means, that you will have to render these objects manually. This means that if you want to get rid-off all your UpdatePanel you will have to change the controls used in your views, you won't be able to use the GridView out-of-the-box for example, instead you would have to change it for the JQGrid (or similars).
This is natural if you are creating a MVC application, but with traditional ASP.Net this is not straightforward.
You also need to consider something very important, the ViewState is validated by default on each post, you can turn it off, but it is not recommended if you want to be sure your ViewState has not been corrupted (take a look at this question).
Consider this example, you have two DropDownList controls, (named: ddl1, ddl2) ddl2 depends on ddl1 so using the SelectedIndexChanged event you fill the second drop down list. But if you attempt to do the same using AJAX calls (without an UpdatePanel), you will face two problems
Rendering, you need to manually add objects to the HTML select control representing the DropDownList. You could use a third party framework to bind these controls using javascript, I can recommend you knockoutjs (it's awesome)
This is the problem. After you have changed the content of the second DropDownList using javascript, you cannot do a simple post to your page because the ViewState will not be valid, and you will see the following exception:
Invalid postback or callback argument.
The workaround is to specify which values will be valid in the server side, in order to do that you need to override the page Render method and specify each one of the values of the second drop down list, but this will increase the page size and obviously, this is not a good option
Take a look:
ASP.NET Event Validation and “Invalid Callback Or Postback Argument” : Part I
ASP.NET Event Validation and “Invalid Callback Or Postback Argument” : Part II
So as a summary, if you want to get rid-off all your UpdatePanel controls, you will need to replace the existing server controls for javascript-friendly controls. Also remmeber that if you do that, instead of relying on the page post mechanism, you would have to use AJAX to perform operations on the server, otherwise, you will get the Invalid postback or callback argument. exception. In other words it would be better to consider moving to a MVC application if possible.
There is an alternative to UpdatePanels, but still using PageMethods. It is a combination between jQuery and jQuery templates. It is proven to be faster than the UpdatePanels. Further reading on the resource below, where you can find more articles dedicated to this topic.
http://encosia.com/use-jquery-and-aspnet-ajax-to-build-a-client-side-repeater/
You might read about the coming WebAPI in .NET 4.5. It's for WebForms as well as MVC and may be a viable solution to your problem if you can wait on 4.5.
Just use it in combination with any jQuery template engine.
http://weblogs.asp.net/scottgu/archive/2012/02/23/asp-net-web-api-part-1.aspx
Have a look at http://uframe.codeplex.com/
Related
I am going to be purchasing an MVC theme from WrapBootstrap https://wrapbootstrap.com/theme/inspinia-responsive-admin-theme-WB0R5L90S for a personal project.
There are alot of things that I like about it design wise, but it has brought up a question about the best way to load notifications in the header (really any sort of dynamic data that needs to load into the common Layout view).
I know there are a great number of ways to do this, but I am at the point in my development experience where I am trying to break my bad design habits (hacking things together so they "just work"), and look for elegant solutions where I can.
The things that make the most sense so far is to either:
1) Create a global ActionFilter that will filter all requests and throw a "LayoutViewModel" into the ViewBag, and just use the ViewBag in the _Layout view.
I'd rather do something strongly typed, but I don't see a way.
This is nice because it is available, does not require my controllers to inherit any functionality from a base class that might be cludgy, or even know that it is happening.
2) Load the page and onLoad, just do an Ajax Calls to the server to load any dynamic data I need.
This may have some disadvantages if your layout needs to change based on the data. I dislike with things snap all over the page after loading.
Is there a design pattern or MVC feature that I may be missing top accomplish this?
I may in the future I may implement something liks SignalR(or a simple timed ajax call to look for updates) to get updated data/notifications, but for now I am just looking at the initial page load.
Thank you for any ideas that you may have.
Most likely, what you're looking for is a child action. These are pretty much just like normal actions, except they'll return partial views and generally are decorated with [ChildActionOnly] to prevent routing to them via the URL bar.
[ChildActionOnly]
public ActionResult Notifications()
{
var notifications = // get the notifications;
return PartialView("_Notifications", notifications);
}
Then, in your layout, you just add the following where you want it to appear:
#Html.Action("Notifications", "Foo")
Where "Foo" is the name of the controller you put this child action in. I have a post on my blog that gives a primer on the Razor templating system that may be of use to you as well.
I'm fairly new to ASP.NET and programming in general, and one of the problems I'm currently struggling to grasp is reducing repetitive code.
My goal is to have a master page that contains a grid view, then numerous pages can contain the grid. However, I want to be able to share code between my grids but at the same time be able to adapt unique code to each and everyone of them as some will have different attributes and data.
I've looked into separation of concerns, and other various posts/blogs but haven't found a definitive answer to how I can actually achieve what I want.
I've already tried using master pages and it worked quite well until my application continued to expand, plus I'd prefer to only use my master pages for presentation.
Could anyone provide a simple example of how I can achieve this?
Happy to provide additional information!
After spending the day doing research and testing numerous possibilities I've pretty much answered my own question.
I've setup a master page that contains the grid, the content page then retrieves the grid using accessors. This grid is then set to a property in the base class which makes it accessible where I need it to be.
edit
Event handlers were created to handle the grid events in the content pages, then those methods were overridden to allow the calls to bubble up to the base class thus allowing me to assign unique, page specific and common code where I needed it to be.
I would like to move some SQL code from the aspx page to the code behind page. The SQL code is bound to a DataSource object.
I am unsure whether to add this code to OnInit, or to PageLoad. Does it matter which one, or is there a better place to put it than another? I would think OnInit would make more sense since I am binding the Select/Update commands and parameters prior to actually using them with an active connection.
Init is better. This is where control properties are set anyway so you will get the closest thing to setting them in markup. On a side note my advice is that you move to ObjectDataSource and extract the Data Access code from your code behind as well. Your markup + code behind are equivalent to the View in MVC terms and data access code does not belong there. If you are doing serious refactoring it may be worth looking into the MVP pattern. With this pattern you get MVC equivalent separation of concerns and testability with Web Forms. In fact MVP is a kind of MVC pattern.
I'm not sure if I'm asking the right question.
We have a web app that we're trying to have a 3rd party POST to. We're creating a special landing page for them to which they can submit the data we need via POST.
I'm not sure how to respond to their request, which I assume I handle as an incoming HttpRequest. Do I process their data in PageLoad or some other event? Where/How is this data contained?
Do I have to use HttpListener or the ProcessRequest handler, or what?
Doing a search here or on Google turns up a lot of results on how to POST to another site, but can't seem to find a relevant site on how to be that "other" site and handle the incoming POST data.
Again, I'm not sure I'm asking this right.
EDIT: I found the Page.ProcessRequest Method in the MSDN library, but the Remarks say "You should not call this method"
Thanks!
You really need to look at the basics of ASP.NET. Even if this were a case where an IHttpHandler would be best-suited, I'd suggest using an .aspx page in this case as it's the best place to begin learning, and you can move to an IHttpHandler later on.
If the data is posted in application/x-www-form-urlencoded or multipart/form-data (the two formats used by forms on web pages - if they haven't told you what format they are using then it's probably one of those two), the Request.Form property (actually, a property of a property) will act as a dictionary into the data sent (e.g. if they have a field called "foo" then Request.Form["foo"] wll return the value of it as a string). Otherwise you'll want to use the Request.InputStream and read from that. This latter is a tiny bit more involved though.
Best would be to use an IHttpHandler, but it is possible to do what you want using a standard ASP.NET Page. Using PageLoad is fine, you have access to the Request and Response properties, which give you everything you need to process an HTTP request. For example, to obtain form parameters, you can use Request["input1"] to get the form input value (either query string, form post, or cookie) with the name "input1".
What is it you need to do in response to this post request? What sort of data do you need to return? Until that is answered, hard to help further.
I am working on a website (developed in ASP.NET with C#) that was passed on to me. As I'm working through the site, I notice much of the site has this type of code in it:
EmailLabel.Visible = false;
WhateverButton.Visible = false;
AnotherControl.Visible = false;
...
This is all typically done in the code-behind of the site (in the Page_Load method). Essentially, this was put in place to prevent a non-logged in user from accessing components (the rule for the site is that a non-logged in user shouldn't be able to see any part of the site until they log in). The way above works...but it seems rather expensive to have to always check if the user is logged in and then flip to the correct status for all those components.
Is there a different way that this problem could be approached. Just from thinking about it/research, I thought perhaps there would be a way that I could do a redirect back to the home page if a user is not logged in. Even further, I could extend a base page which would do this for any page that extends the base page. However, my knowledge in this area is limited, so my suggestion may not work.
What can SO suggest? Anything better? Is what is there good enough?
We do this a lot at my work.
The way we accomplish this is by creating a BasePage class that inherits from System.Web.UI.Page. Then you override OnInit, call the base.OnInit, and add code to check for a logged in user. If the user is not logged in, Redirect them to a login page (which would not inherit from BasePage.)
Then, on every page that needs to be protected, just change the page to inherit from BasePage.
And contrary to what womp says above, if you write Response.End(); after the redirect, it is much faster that even continue processing the rest of the page!
Hope that helps.
There is a loginview component that is a panel which has an anonymous view, authenticated view, and views for specific roles. This makes it easy to do this.
http://www.creativeui.com/2007/10/05/net-membership-part-ii-loginview/
It would be many, many orders of magnitude more expensive to issue a redirect than to set the Visible flags on a number of controls.
If your page allows both anonymous access and logged in access, then redirecting would also require you to allow anonymous access some other way, probably by building a second version of the page.
The expense question is really just an aside though, it likely doesn't matter at all. To answer your main question, without knowing more about the architecture of your app, I would consider both these things as undesirable. The advantages of just setting the controls to Visible = false is that nothing gets rendered to the output stream for the invisible controls, but they can still interact with server requests.
Without knowing more about the requirements of your page, it's hard to suggest alternatives. As someone else mentioned, a LoginView might meet your needs if the invisible controls don't participate at all with anonymous users.