In my Web application I need a Popup window to be displayed daily when a particular time is reached and based upon the interaction (i.e.) the buttons , my application has to be opened. Is it possible in ASP.Net.....If it is, help me in this thing. Thankx in advance.
You can use javascript to create a popup. Since what you describe is a client side feature the GUI aspect will likely have to be in js (unless you want to do a postback and check each time for a time-expired variable, but that is a very 2000's implementation). Here's the tag:
<script type="text/javascript">
alert('expired');
</script>
Alternatively, doing it in ASP.NET webforms or MVC would require you to store a session variable for each user and check on each page load if the time has expired. This has the advantage of being persistent across page loads, and is less easily spoofed by someone with chrome js console. If the resource you are limiting time on is vital, you should store the time on the server side and check via ajax to get it, but that may or may not be feasible depending on how much you know and the resources available to you.
Related
I want to make a form where people can sign up for a course. Number of people for a course is limited. I want to make a page where user can see how many places are still available and that number is dynamically updated, so if another user signs for a course the other one sees change. When number of available places reaches 0 the signup button should be disabled. Such task should be easy to implement but I am afraid it is not. I suppose some Ajax will be involved but how to handle server side counting? WebServices? I have a problem to design a logic behind all of this.
The technology/technique you're looking for is called Server Push.
Basic idea: Client should respond to some events happening on Server.
Possible solutions:
Polling some server action via AJAX in a timely fashion;
Keeping long-running AJAX request open on server-side until timeout occurs or event happens, then process acquired result on client (determine if it was server action or just timeout), reestablish connection from client if necessary.
and a couple of other solutions which are basically variations of the above two. Also solution will much depend on server-side technology you're using.
Google has a short yet very informative article on what this technique is and how it can be implemented here. It's (almost) technology agnostic so it should help you to understand concepts and possible solutions.
I'd use a database on the server. For the "courses" table, have an associated table containing the "bookings". Add them up in a SQL query.
I've been working on a C# ASP.Net application that requires images to be customized by users. The images aren't very large, and so they are being stored in a database.
To facilitate loading them onto the pages, a single ASPX page has been created that depending on how it's posted to it loads a different image from the database.
The problem I've been seeing is that if a single page makes multiple requests (usually over 4), then each request starts getting a half second delay in the response.
I've added extra logging and run it through a performance analyzer and have not been able to find the source of the half second delays.
Question is:
What is this delay and how can I get rid of it?
-OR-
What is a better way of doing what I am trying to do that would avoid this entirely?
You're probably hitting a session lock. Disable the session if possible for these concurrent requests. For more information see:
ASP.NET MVC and Ajax, concurrent requests?
Underpinnings of the Session State implementation in ASP.NET
What "performance analyzer" are you referring to? Are you profiling your app? A profiler should tell you exactly where the time is going.
We are considering a web application to provide users with frequent updates to system data. Initially, the data would be limited to system pressure, flow, etc. but the concept could apply to many areas of our business. The data is stored in SQL Server.
The question is, how do we force a table on a webpage to update when new data is inserted into the database. For example, a pump reports a new flow value. The updates to the database can be throttled but realistically we're looking at a new update every minute or two for our purposes.
This seems like a case where push notification would be used but what can we use with ASP.NET? HTML5 is out of the question although we've watched some push demos with web sockets.
Is there a push technology we can use for ASP.NET?
If not, or if it's a better solution, should we poll the database with jQuery / AJAX? Any suggestions for samples we should look at?
Using HTTP you can only send responses to client queries, so pushing content without web sockets is not possible.
The most common solutions are
polling the server for changes and updating the table if there are any
updating the page on the client often and having the server generate the page if there are new data.
The latter method is the closest to pushing content, as the client do not retrieve data, but if you want to manipulate the data client-side it will be better to retrieve only the data.
A bonus in the latter is that the server handles data and turns it into a plain file, that the server can easily serve to many clients instead of creating the page every time it's opened.
Polling via ajax is the best solution here.
Since you are using ASP.NET, some of the built in ajax controls can make this pretty simple:
http://ajax.net-tutorials.com/controls/timer-control/
If you want to make a better job of this, you might consider creating a web service and using raw JavaScript or the JQuery framework to handle the ajax request / update. I say this because ASP.NET ajax sends the full page view state back to the server, which is inefficient and usually unnecessary.
"Comet" is the technology you're looking for. It's basically a handful of techniques people have come up with to do the sort of thing you're asking for. The simplest of these techniques involve causing the browser to make constant requests to the server for any updates it should know about. The most versatile (but complex) technique involves clever use of an embedded <script> tag which references a dynamic script resource.
You can use an ASP.NET Timer control coupled with an UpdatePanel to periodically check for new data and then refresh the UpdatePanel.
I was wondering if there is any way to always run some server side code when a user leaves a page in ASP.NET. The page Unload event is no good because that doesn't get called if someone clicks on a link. Ideally I'd also like the code to run even if the user closes the browser.
I suspect what I'm asking isn't possible, but it doesn't hurt to ask
Problem is, HTTP is a stateless protocol, so when the page has finished being served, you wont know if the user is still on the page or not.
The only way to acheive this would be a hidden piece of Javascript that constantly pings the server with it's session ID, or another similar mechanism. When the ping becomes unresponsive you can reasonably assume the page is not being viewed by the user anymore.
Here is a diagram that explains traditional HTTP message flow.
im not really sure if you can do that but i have a workaround in mind.
There is an event in the DOM called onbeforeunload. it get calls everytime a user leaves a page. you can try sending an ajax request to the server from this function.
The closest thing you can come without creating too messy a solution is to enable ASP sessions. This will create a session on the server for each visitor, who will be identified by a cookie.
After a certain amount of inactivity from the visitor, the session will be closed, and a SessionEnd event will be raised. This you can hook up to in the Global.asax file.
I will not recommend this however, because HTTP is pr. definition a session-less protocol, and using server based sessions violates this fact, and are often problematic. Many solutions that use server based sessions run into problems when the user uses the browser-back button, and resubmits a form. Because the content of the submitted form no longer corresponds the data that exists in the server session.
Also, enabling server based sessions seriously hurts the scalability of the application.
Not that I know of. You'll need to use javascript for that, and call a web service on the server side.
We just recently wrote an online job application that is made up of multiple, dynamic modules and each one has individual Create/Edit/Update modes that they invoke asynchronously to avoid full page postbacks. Basically you save the data in the different modules as you fill out the application and then you submit it at the end.
Being new to AJAX, we initially implemented the modules using UpdatePanels. Now that we have been using it for awhile we are better understanding some of the limitiations to the UpdatePanel approach. At any one time the application page has between 30-40 update panels.
So we are getting ready to update the code to be more client focused and use web service calls to get data, with the intent to decrease postbacks as much as possible. One of the issues that we are running into now is the fact that only one asynchronous request can be running at one time, so if a user answers one question and then answers another while the first one is still saving, the request for the first one is dropped and doesn't complete.
My question is whether this is just a behavior of UpdatePanels and that it will not be an issue when I move to making web service calls from javascript code. I'm assuming the page can make as many different asynchronous javascript calls at one time as it wants, but I wanted to make sure this was the case as that is a big point we are trying to resolve with a re-write.
Thanks
Yes, that is only a limitation of the UpdatePanel. Its single-request limitation is necessary because the UpdatePanel's asynchronous postbacks are still just postbacks, with all the ViewState roundtripping that is normally associated with full postbacks. If more than one were allowed to execute simultaneously, the ViewState would quickly get out of sync between them and things would go downhill from there.
Using web services, you can perform as many simultaneous requests as the user's browser supports per-domain.