I have a register system on a website at * When someone registers, it shows the error or if it is accepted, it shows "true". The javascript file (http://pastebin.com/mv9CWZcT) is meant to redirect the user if the register is successful but it is not working for me!
I have used this script before and I do know that it works but not here for some reason?
I am at school and cannot view any error dialogs etc.
Thanks, Josh.
Your AJAX is returning two line breaks and true, rather than just true. Use $.trim(html) before seeing if the value is true.
Related
I need to make an adjustment in an application developed in Notes, with the classic development without using xpages. The application needs to give the user an alert the moment an action button is clicked. In this button there is a validation in javascript, which when validating successfully submits the form, which in turn executes a lotusscript agent in its webquerysave event. At this point, some processing is performed, and after processing a condition is verified to generate an alert or not. I thought of generating the alert from the confirm function of javascript, but I do not know how to catch the return from the confirm function to know if I keep the agent code or I finish executing and return to the submitted document.
In the application only javascript client side and lotuscript agent are used. I want to know if it is possible from a lotuscript agent to execute a javascript code and return to the lotusscript code of the agent.
It would be very helpful to understand what language you are using to "confirm" the response. In most cases a timeout should be sufficient. Are you getting any kind of response at all?
You say that you are executing the WebQuerySave event. That means that you are submitting your form. If this is classic Domino web development with no AJAXy stuff going on, then the moment you submitted the form the code that is already loaded in your browser is done. The WebQuerySave agent will either directly generate or redirect to a new page, whose code will be loaded into your browser in place of what was already there. The logic in that agent will have to generate new script and set the appropriate field values that tells the script to put up your alert.
*And if there is AJAXy stuff going on, you're going to need to show your code in order for people to have enough understanding of what you're doing in order to help you.
I'm assuming you're trying to check the record against other data as part of the validation before allowing it to be saved. The problem is once a WebQuerySave agent is called the document is posted and you have to direct the user to a new page. So you need to do your validation before the post.
The simplest way is to do an xhttprequest during your javascript validation routine, before posting. You'll need to call a LotusScript agent (or SSJS Rest service or DDS) that returns a value that you can check against before submitting.
I am trying to save user changes to a form on the server with AJAX on tab/window close.
This is a similar question:
Intercept page exit event
I am using this code :
$(window).bind('beforeunload', beforeUnload);
...and it seems to work fine except for when using IE11.
It seems that when the user verification alert pops up in IE11, every JS piece of code that was previously running gets halted (and my data is not sent over the wire).
So, if the user chooses to leave, everything is gone.
Has anybody made it work on that browser?
Is it possible?
EDIT :
I see now that it works sometimes and it fails on others.
When it fails, it starts the AJAX call (it hits the breakpoint at that point), but never gets in the success/fail function... (and I see nothing being sent when using Fiddler)
In summary, it first hits the AJAX call breakpoint, it then displays the confirmation dialog, and when you choose to leave the page nothing gets sent... :(
Turns out that this method of saving data is not reliable and it is working only by pure luck.
Also, the synchronous XHR is marked as deprecated by now, so it's not a good idea to use that either.
So, I guess the web is not meant to work this way...
I'm trying to integrate Amazon's "Login and Pay with Amazon" payment method into my webshop. I followed the steps from the developer docs: http://docs.developer.amazonservices.com/en_UK/apa_guide/APAGuide_GettingStarted.html
The problems starts at the very beginning. I inserted the code for the head part, and also the button widget (explained in Getting Started > Step 1). But when I click the button in my shop, the popup shows the following error:
It says there is a problem with the handling of my order (although I just expected a login screen). And Amazon is about to fix that problem. But I get this error since the very first time I clicked this button, and that's about a week ago. And I can't find any statements to this error.
Is there anything I could have done wrong? I think I setup everything right (client-id, seller-id, return-url, scope- and popup-parameters). Also the onError function isn't called, so I can't really do any debugging.
What causes the error?
Have you setup the Allowed JavaScript Origins in application console? That might cause your problem.
I've looked at several other SO questions about this same error, but they don't seem to quite match what I'm doing.
I'm working up an AngularJS app & trying to do pagination within JSFiddle. When I click on my link, I get an error: {"error": "Please use POST request"}
Most sources say that I need to simply change my form method. But no where am I using GET or POST, so not sure where the hangup is happening. Even tried setting breakpoints, but that didn't help much.
Help would be appreciated!
note- To get the same error message: you need to select "RUN" & then click on the link
When you first link to the jsfiddle it works because the frame shows http://fiddle.jshell.net/enigmarm/L7CSD/6/show/. When you click RUN it posts the form to http://fiddle.jshell.net/_display/ to render your page. Going to http://fiddle.jshell.net/_display/ in the browser (ie: using GET) will give you the error.
You have an href="" which means that clicking it regets the page using the GET verb instead of the post that created the rendered page. Don't put href="" on that or stop it from requesting the page.
This can happen when using a XSS script-blocker like NoScript, which changes cross-site requests from POST to GET.
I'm trying to understand how this login page works by looking at the source from my browser (Chrome).
The source links to some CSS, pictures, and generic JavaScript libraries. Apart from a little jQuery at the very start (for changing the language), I don't see why the page isn't more than just dead HTML elements.
For example, if I click "LOGIN" with an empty username and password, the message "The username or password you entered is incorrect." appears. But I can't see anywhere in source where such behaviour is defined.
What am I missing?
The activity you are observing is one of the core functions of <form> elements. When a form is submitted, the user's browser is directed to the page defined by the action attribute in the form. In addition to directing the user to this page, all of the inputs included in the form are passed to the web server as variables.
One way of submitting a form is by including an input element of type submit within the form, which is what the web designer has done here. When that submit element is invoked (via a click, for example), the form is submitted.
The message you see is not shown by jQuery / Javascript.
Notice that when you click the "LOGIN" button, the page submits your request.
That means it Server Side code starts to run, code that you cant see.
This Server Side code handles your input and generates the Error Message that you see.
When you click the LOGIN button, the form is submitted to the server,which returns a new HTML containing the message. The logic for that is defined in server-side code, which you can't see from outside. 'View source' will only display what the server outputs.
I think the page is simply refreshing.
You can confirm this by opening the network tab in chrome console and watching it as you submit the empty form.
Thanks to http asset caching, this seems as if the page did not refresh - but chrome's network tab confirms it does.