I have a new message page that can only be accessed if you are replying to a message or you click to message a user (unless of course you guess the URL). The cancel button currently will send you back to the previous page you were on using javascript:history.back().
I'm wondering if this is the best practice or if I should be using something on the server side to set where the cancel button takes you.
I took a look at this similar question: Does using javascript:history.back(); have any unknown issues?
I don't understand the cache problem mentioned in that post or the javascript being disabled because the site has a lot of javascript that this feature would be the least of the concern if the user does not have javascript. I'm also not too worried about the user not having a page to go back to because as I said, this new message page can only be accessed by clicking on a button on a site unless you guess the URL or copy the URL into a new window.
I'm wondering if there's any other issues on doing it one way or another.
Thanks!
Well, one issue you did mention was when the user types in the URL? Maybe we're crazy, and/or hate buttons! Joking aside, using history.back is mainly frowned upon due to its static nature (who knows if there is a page to go back to).
What the guy is trying to say in the link you provided about caching is that, for example, say you had a sign in page. If you hit your button using history.back, the browser would use a cached version of the webpage, and in turn, clear out anything you filled in. It would also show that you weren't logged in on the users end.
If you do have server side logic. I think your best bet in this case would be to just put in an windows.location.href to your previous page. That way, this issue is resolved, and you know exactly where the user is going.
Related
I am trying to code an app for work where our clients can edit certain fields. When they click edit, the code will lock the data to be editted. And when they click save the data will unlock. But I am having trouble deciding if I can unlock the data when they click elsewhere, go to another page or site, or even close the browser.
What's a good way to decide if the user has left the edit page?
(We are using C# .NET 3.5 and JQuery and a SQL Server 2005 DB).
If you really must use pessimistic locking you could add check in Session_End and unlock all locks that this user set in current session. Use onUserExit jQuery plugin to end session if user closes the browser window or goes on another site, here is the example :
https://stackoverflow.com/a/10481972/351383
You can make use of "onunload" event of html tag. This event is raised
- when Page is closed using X button
- when Page is redirected(In your case user clicks on edits and move on to different link without saving.)
Hope this helps!!
Your question is being understood as "what's a good way to decide if the user has abandoned the edit page without having clicked 'Save' to unlock the field?"
But I am having trouble deciding if I can unlock the data when they click elsewhere, go to another page or site, or even close the browser.
All the scenarios in which someone looks at another page from the same application might mean another window in the same session - perhaps to check something. You don't want that to trigger an unlock because your user could still have a window open in which they can submit the edit.
The other scenarios where the user leaves the page can use onUserExit.
However, you omit from this list the scenario "user goes to lunch leaving webpage open". This is why pessimistic locking is problematic.
Therefore, rephrase the problem as "the user has clicked Edit, but then failed to make the amendment and save within a reasonable time limit".
Basically, your lock should at some point expire.
Upon clicking 'Edit', the save lock kicks in and a timer (5 minutes?) starts, which is also visible on-screen. (If getting these in sync is an issue, make the client-side timer shorter than the server-side one). Your users must make the change and click Save within this time. You could perhaps add an Extend button to extend the time.
The principle is that you need to determine that someone has left it too long, not that someone has left it. You also show to users that having clicked Edit you are expecting them to make an edit some time soon.
You will need to code your system to unlock fields where the lock has expired.
This has the benefit that your countdown will look 'cool' to the sorts of people that request such edit locks.
There's a certain website I need to access multiple times each day that requires me to enter my login name/password first, every time. To save some time, I copied-and-pasted the HTML source code and pre-populated the text fields with my info, then saved that to my desktop. Now I can just open that doc in my browser and click "submit" without having to type anything.
I'm wondering if I can go a step further. Whatever data is sent when I click "submit" — I'd like to start with that step.
From what I understand, the form info is converted into a POST request and sent to the web server. Is there some way I can concoct that request manually (without using their login screen) and then execute that request each time I need to access the site?
Thanks!
wow, what a safe site! Anyhow yes you could do this lots of ways. Not a good idea to transmit tho locally. Have you ever just tried using one of the form auto forms plugins for FireFox? one button and it will populate your form for you.
https://addons.mozilla.org/en-US/firefox/addon/autofill-forms/
I assume you want to do this in an active browser because you want to be able to interact with the site after logging in, correct?
A really simple way to do this and end up with a workable browser might be to try using WatiN. The library itself is generally used to automated in-browser testing. But at the hear of it, that's kind of what you're doing here. You just want an executable that will open a browser, navigate to a page, populate a form, submit, and present the result.
This isn't so much from the perspective of crafting the POST request manually, but rather just automating the UI interaction.
Ultimately, though, it's going to be a matter of testing it for what your user experience is like. Does it take longer than you want? Does it leave the application running in the background unnecessarily? etc.
Honestly, this might really be overkill. Browsers have form auto-population these days. Maybe a browser plugin to take advantage of that instead? How transparent does it need to be?
I need to ask the user if he/she wants to continue an operation (say, save operation).
So, after the user clicks the Save button, some stuff is checked on the server side. If one condition is met, the user must be asked if he/she wants to proceed.
Based on user's answer, the postback should be automatically performed carrying the user's reponse back to the server, so the server will now ask again. Is it possible to do it?
Thanks.
EDIT:
To be more specific, I want this:
The user clicks Save button. The postback is performed
I need to make some validations/checks on SERVER SIDE (this is important!)
In the middle of the postback I want to stop if a certain condition is met and ask the user if he/she really wants to continue.
If the user clicks Yes, I need to re-post the request, but now I need to carry the user's response.
If that "certain condition" is met again, I will just ignore it because the user wanted that.
So the solution to add the confirmation dialog right when the button is pressed is not an option because the checks are not simple and require some complex stuff involved (impossible to do it on client side).
Ajax/JS/Telerik, all OK.
You can use
btnExample.Attributes.Add("onclick", "javascript:return confirm('continue?')";
just one of the options...
EDIT:
for your needs you will want to use AJAX, call a method on the server and upon callback open the confirm window.
2nd Edit:
if the server side work isn't long I would this using AJAX.
AJAX works asynchronously and you want a synchronous procedure, right?
instead of posting back, call an AJAX method from the javascript, which will look something like this:
Service.ProccessRequest(data, OnSucceedJSFunction, OnFailJSFunction);
this way when the server side method finishes the OnSucceedJSFunction on the JS will be called.
in this function you can do something like
if (confirm('are you sure?'))
{
call another server method...
}
if you need to resend the data to the same server side method or to another server side method you can do this again and call a different OnSucceed js function.
Im not sure though about what you want to happen at the end of all the procedure...
Quick and dirty is to use javascript confirm function, tons of example on how to avoid the postback when user clicks cancel or ok.
if you need better ui control surely you can use javascript / jquery or whatever to show a nice dialog box and prevent the postback to happen or invoke it.
If non-JS users do not bother you then something like jQuery or AjaxControlToolkit could provide a modal popup solution.
If you are conscious or perhaps work for a company that needs to provide non-JS solutions then you could consider sending the user to another page asking for confirmation, you could carry any relevant info in either the Session or the Query String.
I've got a modal dialog created using ModalPopupExtender. There is an UI created in it using Webservices and a JQuery Templates. There is also a hidden ASP.NET button which is called from the javascript using the __doPostback() technique. The javascript hides the modal popup and __doPostback is called on the button (which is inside of the ModalPopupExtender)
I use this technique to pass some parameters are from the javascript. The server-side event handler does some processing and transfers to a page (in some cases, back to itself)
This works fine when the page it transfers to is a different one but if it transfers to the same page, the postback happens over and over again until the stack blows.
How do i stop the postback from re-occurring when I postback to the same page. I guess it doesn't happen the first time around because it posts to a different page and the postback is invalidated.
Code samples are difficult to provide as it's a fairly complicated system and it's difficult to break it apart.
It sounds horrible I know, all I want to do, however, it to call a server side function from javascript with some variables. Is there a better way to do this?
Well, you're posting back, so you have server-side control over your markup. Just stick your javascript that does the repost in a container and in the case that the page posts to itself, hide that container so it's not loaded into the page....
That or you could do client cookies or a querystring param. Both might be wonky.
With out a code sample I can only speculate and hopefully point you in the right direction.
When you transfer to a new page the old page (and therefore the javascript on that page) passes out of scope and therefore does not continue to execute. If, however, the page is reloaded and the condition that invoked the __doPostback continues then you have created the circular reference that causes your problem. Before you invoke __doPostback, but while you are still on the client, you need to clear whatever condition might be causing the chain of events.
If you can not uncover what is invoking your event chain then you might consider that instead of transferring back to the same page transfer to a new page (bounce.aspx) which in turn invokes a response.redirect BACK to the page so that it is not a Postback when it is being reloaded, but a fresh instance of the page. (Yes, this is a kludge, but it might be an effective stop gap...)
Cheers,
CEC
Thanks for the responses. I think i've found the solution.
In the server-side callback I was doing this:
setupPage();
Server.Transfer("mypage.aspx", true);
changing it to this:
setupPage();
Server.Transfer("mypage.aspx");
fixes the problem.
SetupPage() stores all of the data in hidden fields and I assumed that preserving the form state would be necessary so that this resided after the transfer. This doesn't seem to be the case as all of the setup I've done in the page before the transfer seems to still be present.
Odd or perhaps I'm misunderstanding something fundamental about .NET
Edit - Yes, I do misunderstand a lot about .NET. It makes my head hurt sometimes.
Thanks for the help
I have an ASP.NET (C#) page that has a long load time (like 2 minutes). The user is presented with a little animation and a "please wait" message. If the user accidentally loads this page, they need to wait for it to load.
My question is: Is there a way to stop the page load?
Thank you
If you want to stop the server side processing then its a tricky operation. Generally once a request is made that page is rendering on its own independant of other thigns going on. What you would probably need to do is re-engineer that page to check at regular intervals whether a stop command has been issued and abort whatever it is doing at that point. The stop flag could be put in session and should be cleared out after the stoppage.
You may also need to consider how to properly identify the right one to stop (in case there is more than one running). This could be done by returning a unique ID that can be used in part of a call to the "abort" page.
My approach though rather than this complciated rigmarole is to make efforts to stop the user from making this accident. Possibly make whatever link they are clicking pop up an alert saying "the following page will take several minutes to render, do you wish to continue" and then hopefully you will effectively be aborting the page request before it is even made.
I should note that I've never tried to do this sort of thing before so there may be easier ways to do it but this is how I'd probably think abotu going about the problem.
Try window.stop() in JavaScript.