I was wondering if anyone had an easy way to wire up javascript event handlers to events happening on the server-side. I have a long running process that includes a lot of steps, and would like the client to be continually updated with new information as the steps transition. Will this involve some sort of polling mechanism?
Send an AJAX or JSON request from the client every so often asking for status.xml. Then, on the server, when something changes, just quickly write a new line to status.xml the same way you would to the console. You can use setInterval( function, timeBetweenRuns ) in Javascript to do this regularly.
would it be possible to use an update panel to do this with maybe a timer? it's sort of how I would do it.
Course, this depends on what you're doing already. I'm assuming you're using Forms...
Ajax calling a Web Service is how I would do it.
Related
I want to send a message to the client when the ASP.NET session ends. I did not want to use timers so I tried using "server sent events" to call the client from the session_end event in global.asax. Is there a way to call a specific client from global.asax? I tried using the 'SignalR' library for this propose, but had problems calling a specific client from Global.asax (I have managed to call a group of clients but not a specific client)
What are the best practices for this propose?
I'm not sure if this is what you need, but does this help?
(Of course you don't need to use DevExpress for this, you can implement your own popup window)
I'm new to this AJAX approach when you're not supposed to use UpdatePanel but rather go with WebMethods and WebServices. My main problem is authentication.
When page is entered or postback request is created, everything works fine. Authentication is passed correctly and I can access Thread.CurrentPrincipal.Identity and get my user identity object from there.
However this changes when I try to call WebMethod on my page. Call is passed correctly to server and everything seems to work just fine until i try to get user identity from thread. Then I get just Anonymous user instead of real one. Enabling session on webmethod didn't seem to help much.
Any ideas what might cause this problem and how to solve it? Someone mentioned that authentication cookie needs to be passed along with the request, but how am I supposed to do it?
Any help will be appreciated.
Edit:
Some clarification and code:
My application is written in standard asp.net. After some deeper research in legacy code I've found out, that all authentications are done in some base class from wchich all other pages inherit. Each time page is loaded, user principal are obtained from HttpContext.Current.Session("..."). I think this is far from good solution, but I'll need to stick with it right now. Problem was, WebMethod is not firing whole page lifecycle since it's static. I've fixed it right now by calling method that obtains user data from session.
I would like to get some ideas how this could be created correctly and what problems might be result of session based authentication.
PageMethods.SomeMethod(parameter, SuccessDelegate, FailureDelegate);
This is how I'm calling WebMethods right now. I assume it's passing all required cookies, am I right?
It depends on how you're calling the method and in what manner?
Jquery for instance with its Post method should push all cookies (including your FormsAuth / Session cookie) up with the request that should still authenticate as appropriate. Bare metal techniques might be making lightweight calls that simply do not push the cookie up...One way to monitor this is by using Fiddler to observe the request and a browser based development plugin like Firebug and see what is occuring and amend your JS code as appropriate.
Personally, if you are starting a brand new project and there is no pressing need to expose your services beyond your web application then I would suggest looking at ASP.NET MVC where you can make Jquery / client-side up to the controller and get your authentication wrapped up for free. I've recently created something simliar using WCF JSON endpoints and some inevitable pain, I then saw MVC and kinda kicked myself...
As noted in comment above, the issue lies in legacy code that handles users. It is needed to make call to special function that assigns appropriate user data to handling thread. Not a best solution, but that's how it sometimes is with legacy code. What you gonna do?
I am loading a gridview using a code based on this:
http://msdn.microsoft.com/en-us/library/ms366515%28v=VS.80%29.aspx
I am using callbacks to populate the grid, sometimes there is a lot of data or the user wants to cancel.
How can I cancel the callback from being processed on the server when user hit cancel??
thanks
Searched quite extensively and found that it is possible to Cancel Server Tasks with ASP.NET & AJAX
Although I'm not good with AJAX, Found some links that will help you,
Here's how to Canceling Server Tasks with ASP.NET & AJAX and here's a forum thread on something similar to your problem.
Hope it helped !
AFAIK, you cannot cancel the server side call back processing once initiated. At the most, you can have some client (browser) side logic that will ignore callback results.
Regardless, I will suggest you to use ASP.NET AJAX (UpdatePanel or Script Services) rather than using ICallbackEventHandler. It's quite simple to use and more flexible. Besides, you also have options such as cancelling callbacks : see this article for cancelling update panel callback (note that cancel really means stop waiting for (& ignoring) callback results, the server side processing would happen).
Once you've initiated a request to the server, the client cannot cancel it. Ignoring the mechanics around any possible "cancellable method", you've started a request with the server. Any further communication will result in a new request, so that original request will continue until it has finished. Remember HTTP is a stateless protocol, each request has no knowledge of any previous request, and because of that, how could it cancel a previous request?
You're best bet would be to just ignore the server response, or if you actually need to cancel a long running task that may still be processing on the server, you need to bake in that support yourself, as the web server will not natively support it. To do that, you'll likely need some way of persisting the task state across multiple http requests, and have the original request (the one running that task) be monitoring some sort of cancellation flag.
Just remember though, in the above scenario, you wouldn't be cancelling the request, but the task the request is running.
A long running background process creates a text file to indicate the completion of the process. From the frontend, I'd need to check every few seconds if the text file has been created or not.
I am doing this check from http://DomainA.com However the file is created in http://DomainB.com/Mytext.txt
Can someone help me write a jquery script that checks for a file across domain?
PS: Currently, I am doing a ajax postback that executes a WebMethod in ASP.NET that creates HttpWebRequest. This works functionally, but I have major performance problems. So, I need a light weight way of finding if a URL is valid or not.
Thanks
I would set up a server-side script on your own server which pings the URL (using cURL or whatever) and responds with a JSONified version of the response.
Do not fire HttpWebRequest at the moment the jQuery script requests it. Run HttpWebRequest independently at same intervals in some background thread which in turn sets some shared boolean toggle. Finally let the code which should respond to jQuery requests return the state of this toggle (thus without firing the HttpWebRequest itself).
I ended up using YQL with JQuery that lets me do cross domain requests.
call it using jQuery ajax, then look at the result if it is 404? This is asynchronous though, so you need to use javascript continuations if you are in a workflow
Is there an event like onLoad?
just at closing the Site (onClose)?
Not in the sense that I suspect you're thinking. All your code in ASP.net runs on the server which doesn't inherently "know" when the site is closed by the user. To achieve what you're after, you'd need to use Javascript to handle the window.onunload / window.onbeforeunload events and trigger some form of request to the server.
Take a look at http://developer.mozilla.org/en/DOM/window.onunload for more information on the window.onunload event.
Update: If you're using/able to use ASP.net AJAX, there's some quite tidy wrappers there that provide you with a similar set of events/beahviours to the server-side page lifecycle. There's a pretty decent tutorial from Stephen Walther on his blog.
I would suggest using asp.net ajax for this. See this link of page lfecycle for this, which shows the application.unload event (triggers when the page is being closed, navigated away from).
This fits well with asp.net for obvious reasons, better than using onunload event directly, unless of course you do everything without asp.net ajax. The only thing it cant do is notify you in the case the browser crashes.
You could use with limitations Session_End method in ASP.NET application file (Global.asax).
"Closing the side" means that the user closes the browser window on his client, right?
In JavaScript you have the OnUnload-event. If you need an event on the server, then you might be able (I never tried) to push the event to the server by hand using a custom client script. But you do not have it out-of-the box, because it's a client event.
Hope this helps.
The closest you can get it UnLoad.
http://msdn.microsoft.com/en-us/library/ms178472.aspx