A page executes a number of tasks and takes a long time to process. We want to give the user feedback as each task is completed.
In ASP.NET webforms we used Response.Flush()
What way would you a approach this in ASP.NET MVC?
You can still use Response.Write() and Response.Flush() for whatever status you want to send down the wire. Or if you have your progress thingy in a user-control, you could do something like:
this.PartialView("Progress").ExecuteResult(this.ControllerContext);
this.Response.Flush();
from your controller while doing your lengthy operation in the controller's action method.
It's up to you to choose this or the client-side approach as mentioned in the comments here, just wanted to point out that server-side is still possible.
I would suggest to use AJAX for displaying progress. See links for ideas:
Real-Time Progress Bar With ASP.NET AJAX
Using jQuery Plugins with ASP.NET
Ajax Progress Bar Control
There are two basic ways:
Poll a server page that returns the status, then once the operation is done, redirects to a results page. MVC is nothing to do with this way, you'd need to use a server variable to store objects/status - this is a way that's more relevant to a standard Asp.NET application as you're (presumably) using session variables etc. anyway.
AJAX call from the client to a webservice on the server. Asp.NET MVC is going to be rolling the jQuery framework in, so use that for the client call and event handling for the response. This would be more in the spirit of MVC which doesn't/shouldn't use session state etc.
Me personally I would consider two optoins:
redirect to wait page(s), then fire actions
Do it ajax style
You can make it in client side. In each step, you set some session variable with the current step. Then, You make another action in your controller say called: "GetProgress" and assign a view and URI for it.
In the action, you will check this session and return the current progress of your task. In the client side, make a timer (i.e setTimeOut) and you invoke the URI of the later controller action every specific amount of time - 1 second or so. That is it.
Related
All:
I have been searching high and low for an answer to this, so forgive me if this is a dupe, I just can't seem to find the right answer.
Let's say you have an ASP.NET MVC Controller marked with the [SessionState(SessionStateBehavior.Disabled)]
attribute. Does calling actions on this controller "refresh" the session state, keeping it "alive"? Specifically, I have a AJAX request calling a controller to keep the session "alive" since the application is a single page application driven by javascript, and I don't want the users session to die, so every 30 seconds I make a call up to this controller. Similarly, would it stay alive if the controller was marked SessionStateBehavior.ReadOnly? Finally, is using an ASP.NET MVC Controller for this purpose not the best way (is there a better way)?
Thanks!
Session state will be kept alive automatically with no attributes on the action, depending on how the web.config is configured. To configure it, see here: http://msdn.microsoft.com/en-us/library/h6bb9cz9(v=vs.100).aspx
A controller should be okay, but you may want to look into Web API as it'll offer a few more features in this scenario: http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api
I have an mvc4 application that I am looking at hosting on azure websites. The only task is to take a code from a parameter and redirect to a page within our main application. We have a .co domain so we are issuing shortcodes like mydomain.co/abc I check the code in this example abc and redirect it to somewhere in our main application.
My question is do I just create a controller and do the redirect from the controller or can I do this before the controller? I want it to be as lightweight as possible.
Thank you
A controller action taking the parameter, querying some data store by passing it this parameter in order to retrieve additional data and finally redirecting to the corresponding application seems fine. Another possibility is to write a custom route that will perform those tasks but IMHO having a controller action to do it seems easier.
I Have Make a Create Form.
& I want the Values in Controller how can I get them Without Postback the Whole Page?
Any article please help
You could use AJAX to send the form values to a controller action. The jQuery Form plugin is very good for this purpose. The plugin reads all the form values and sends them in an AJAX request to a controller action for processing.
Use javascript to call a web service (i.e ajax). Check out this article for some basics.
Since you're using the "postback" term I think you might be coming from a WebForms background which hides all the HTTP request-response cycle. POSTs are done on <form>s, so technically the entire page is not "posted back", but the data from the form in which the pressed resides.
I'm after some design advice.
I'm working on an application with a fellow developer. I'm from the Webforms world and he's done a lot with jQuery and AJAX stuff. We're collaborating on a new ASP.MVC 1.0 app.
He's done some pretty amazing stuff that I'm just getting my head around, and used some 3rd party tools etc. for datagrids etc.
but...
He rarely uses Submit buttons whereas I use them most of the time. He uses a button but then attaches Javascript to it that calls an MVC action which returns a JSON object. He then parses the object to update the datagrid. I'm not sure how he deals with server-side validation - I think he adds a message property to the JSON object. A sample scenario would be to "Save" a new record that then gets added to the gridview.
The user doesn't see a postback as such, so he uses jQuery to disable the UI whilst the controller action is running.
TBH, it looks pretty cool.
However, the way I'd do it would be to use a Submit button to postback, let the ModelBinder populate a typed model class, parse that in my controller Action method, update the model (and apply any validation against the model), update it with the new record, then send it back to be rendered by the View. Unlike him, I don't return a JSON object, I let the View (and datagrid) bind to the new model data.
Both solutions "work" but we're obviously taking the application down different paths so one of us has to re-work our code... and we don't mind whose has to be done.
What I'd prefer though is that we adopt the "industry-standard" way of doing this. I'm unsure as to whether my WebForms background is influencing the fact that his way just "doesn't feel right", in that a "submit" is meant to submit data to the server.
Any advice at all please - many thanks.
The thing you need to take into consideration is how the application will work if javascript is not available. You should strive to ensure that the basic functionality works without it. This is called progressive enhancement or unobtrusive javascript and is considered a best practice.
http://en.wikipedia.org/wiki/Progressive_enhancement
The way you should do it is to use a form with a real submit button and then hijack that form to use ajax if the User Agent supports it. This is usually pretty trivial to do using the jquery forms plugin. In your action method, you can check to see if the incoming request is an ajax request by checking the Request.IsAjaxRequest property. This is set by MVC automatically on requests that have the X-Requested-With header set to XMLHttpRequest. Then you would return a full view or just some json based on that.
Here's a short screencast demonstrating this: http://www.youtube.com/watch?v=YQsFR1rkgMU&feature=player_embedded
Both solutions are viable, though using submit buttons will make your application more accessible (i.e. JavaScript will not be required in order to use it).
You could also do the both - start with a page that has all the necessary logic using postbacks, and "upgrade" it with nice AJAX-y requests and animations. This way, users with JavaScript will get the eye candy, and the page will gracefully degrade when when a user without JavaScript visits the page, falling back to the postback mechanism.
I am trying to create an upload control for ASP.NET MVC with jQuery progress bar. In ASP.NET the implementation works no problems, but in MVC the problem is that the server doesn't respond to my callbacks until the file is uploaded.
The upload control is based on html file upload element, and I cannot for the life of me, understand how MVC handles postback + callback synchronously ?
I have searched for a whole bunch of answers, but all I can find is a "callback+callback" solution and NOT a postback+callback.
Does anyone have any idea how to solve this problem for MVC ?
Thanks
Hrmmm,
Thomas, MVC does not handle post-backs at all. Because a URL is directly routed to an Action method on a controller, a form is not meant to actually post-back to itself. Further more, all of the post back processing that Asp.Net had to handle post-backs on the server was pulled out of the .Net MVC framework.
A better approach to accomplish what you're trying to do with a progress bar would be to use JQuery with AJAX to make the call to your server and then use Javascript/CSS (possibly a lightbox approach) or a pop-up window to inform the user that they are waiting. When the Ajax call completes it's work, you can have Javascript fire the redirect to the page in your MVC that you want the user to be redirected to after the action has been performed. Making AJAX calls with JQuery is a total breeze and is pretty fun to play around with as well!
Check it...
Suggestion:
You can use the JQuery Uploadify control to show the status of
the upload. This control has a flash and html 5 type controls. Use whichever is applicable to you.