i heard we should use "return" after "Response".why?
like this :
Response.Redirect("../Login.aspx");
return;
That's probably just an artifact of C# development. Every C# method requires a return statement, regardless of what happens in the Response.Redirect call.
You're probably assuming that the return won't execute, but that's not the case. Response.Redirect, once called, does in fact pass control back to the next statement in the C# method, just like any other method call would.
A 'Response.Redirect' does not finish the code processing. It just instructs the server to send an HTTP 302 Found to the client. The client then commits (technically it doesn't have to but "common" clients like web browsers do) a request to the new URL given after the HTTP 302 header.
You can, for example, do other server-side tasks after the Response.Redirect and they will run.
Related
We are building a custom way to process timesheets using eConnect. A method is exposed that allows out timesheets documents to be submitted to GP. This method is run synchronously, but can take a long time to complete. How can I handle this so that the user's client can make additional requests in the meantime?
I have attempted to use async/await on this method, but because the method isn't awaitable this will not work. The method depends on a windows service. I have researched potentially wrapping it in Task.Run but have hesitations since this sounds like a bad practice.
public bool SaveTimesheets(string ConnectionString, List<PATimeSheetsType> Timesheets)
{
string timesheetDocument = string.Empty;
//Creating timesheet document
bool result = false;
eConnectMethods eConnectMethods = new eConnectMethods();
//CreateEntity takes minutes to complete and return
result = eConnectMethods.CreateEntity(ConnectionString, timesheetDocument);
return result;
}
The behavior I currently get is that, if for instance I am doing an ajax calls on the client-side, the call doesn't seem to get there while the method above is executing. I would like it so that the method call executes in the background so that the client can still communicate with the server to execute other requests.
How can I handle this so that the user's client can make additional requests in the meantime?
The easiest solution is to change your session state to be None or Read-Only (for both this and the other requests). Then ASP.NET will allow multiple client requests for the same session.
If you're on pre-Core, the session state docs are here.
I'm currently working on the stable version of Rascal and I want to spawn the Rascal webserver to serve my html templates with javascript functions.
Looking at the Webserver module I can't see how to use the serve function to use the webserver. It asks for a location (I'm assuming that the location would be something like |http://localhost:8080|) and a callback that has the type of Response (Request) but what is that type? I don't know how to create this kind of type and what it exactly is.
The type Response (Request) callback is a function, E.g.:
Response (Request r) {
return response(...);
}
This function is an anonymous function (it has no name) that you can pass into the serve function as an argument, you can also define it as a normal function with a name, and just put the name of that function as the argument.
So this would probably work:
serve(|http://localhost:8080|,
Response (Request r){
return response("Hello world");
}):
Since there is a factory method Response response(str content) in Webserver.rsc, that will create a response for you from a string argument.
In the absence of documentation about this module, all you can do is read the source. In the Eclipse browser, the libraries are accessible (indicated by little jar icons) and you'll find util::Webserver there with the definition of the Response and Request types.
Basically Request is a callback function with all the HTTP headers and stuff as parameters and Response is a wrapper with alternative response types (files, strings, etc.).
Note that the current version is quite a bit different from the stable version you use, so reading code on github will not help much.
The usecase is simple. Info for logged in user is displayed in _Layout.cshtml. That info needs to be refreshed every time.
I found two ways to do that
Have BaseController and in its OnActionExecuting method set ViewBag.UserInfo = ...; which is later used in _Layout.cshtml
In _Layout.cshtml do #{Html.RenderAction("GlobalUserInfo", "UserInfo");}
The problem is that these two ways fail miserably with deadlocks or exceptions if UserInfo is returned from an async public async Task<UserInfo>GetUserInfo(){...} method.
So the question is this: How to set ViewBag properties on every action when data is retrieved using async/await.
MVC is not quite fully async-friendly, particularly with filters.
You could write your own RenderAsyncAction extension method or duplicate the code in all your async actions.
Alternatively, you could attempt a bit of a hack. I describe on my blog why using Result in ASP.NET can deadlock, but there's a workaround: use ConfigureAwait(false) on every await in GetUserInfo.
Then you can define a synchronous wrapper:
public UserInfo GetUserInfoBlocking()
{
return GetUserInfo().Result;
}
You should be able to use GetUserInfoBlocking in OnActionExecuting or RenderAction.
Please note the side effects:
This approach uses multiple threads per request, so this will decrease scalability. The pure async approach uses multiple requests per thread, so it increases scalability.
Any exceptions from GetUserInfo will be wrapped in an AggregateException, so be sure your logging will capture the InnerException details or you'll get meaningless errors in your logs.
It's definitely best to use async all the way down instead of blocking like this. But sometimes MVC doesn't leave you a choice (hopefully this will change in the future).
In Struts2 if we have define an interceptor stack and it is called in First in First Out manner.
So in post processing phase what happened if one of the earlier interceptor return a control string which in result render the response to the client.
I want to know that would the left interceptor will be processed or not.
Well it will work like this.
Your action method will only called once the interceptor stack has been called fully.This means that once the first interceptor has been called successfully in the stack it will call the next interceptor defined in the stack and there reference being stored in the stack this chain will keep on calling till the last interceptor in the stack is called
invocation.invoke()
this call is the key to call next interceptor defined in the stack or of this is the last it will call the desired function in your action class.
now in other case suppose some of the interceptor failed say workflow it will return the result as INPUT and will halt the further execution of the interceptor and framework will output the desired JSP/Tempelate to the user.
Than comes the post -processing/cleaning in this case interceptors will be called in reverse order i.e top most or latest executed interceptor will be called first and den so on so.
The idea for this post-processing is to do any clean-up work or any other things which needs to be done (like cleaning up resources etc)
Hope this will give you some idea.
First check the slide that is referenced here: http://weblogs.asp.net/leftslipper/archive/2007/12/10/asp-net-mvc-design-philosophy.aspx
Since I have been using ASP.NET MVC I have in my mind conceptually been aware of the 'URL Routing', 'Controller', and 'View' stages that are shown here...
But what is meant by all the other stages? Can anyone give a synopsis of them? Especially the ViewFactory, what the heck is that and am I suppose to be using it? Right now my Controller just returns Views...
The View Factory (AKA View Engine) is what actually creates the view classes that process the markup you write. If you want to replace the default MVC Views with something like Spark or NHaml then this is the stage you need to change/intercept.
An HTTP handler lets you intercept messages at the protocol level before the request really hits your "application". For example you might plug in a custom error handler for certain response codes. Or you might plug in a special HTTP handler for media you host like images and movies, to prevent other sites from hot-linking.
The MVC Route Handler itself is an HTTP handler; it "handles" HTTP requests by creating the Controller class.
The last piece is the Route which I think is pretty self-explanatory.