this is a question about the best way (or least effort of the best ways) to overlay an html page with a form. Best in this context meaning best user experience whilst meeting the functional requirements.
Let's say I have a page with a short form on it; the user has to enter some financial details. To assist the user to enter an accurate value for one of the fields there's another, much longer form. The longer form needs to be displayed only if the user requests the help.
For users without javascript, clicking a link will submit the short form (persisting already filled fields in a session) and the server will respond with the long form. They'll submit the long form and the server will combine the submitted data with the persisted data and serve the short form again - with the fields populated.
For users with javascript I want to overlay the short form page (in a lightbox stylee) with the long form, allow them to populate the long form and then go back to the short form with less round-trips to the server.
Do I:
Overlay the short form page with an iframe whose target is the long form?
Request the long form over ajax and stuff it into a div?
Generate the long form entirely on the client-side?
Some other wizadry I haven't thought of?
A short explanation of the best mechanism will do me very nicely indeed. Thank you very much!
I'd be thinking about option #2.
When the user asks for help, load the help-form dynamically into a div that you can pretty up with a lightbox of sliding drawer effect or whatever.
If possible, I'd do all the processing of the long form on the client side, and use the results to dynamically update the short form.
I use Colorbox for this kind of stuff it's really good.
You can specify the content inline or via another URL (which is what I do). It's probably better to use this second method as it keeps your webpage a lot cleaner and only requests the form content if required. It also means you can post back to that form itself (via AJAX if required) keeping the whole experience cleaner
Check it out here - click "Tag this smiley". The form is taken from a remote URL and posted back to it inside the form using jQuery. It's obviously a simple version of what you want but works, and looks, really nice.
For your scenario where you want a decent fallback for users without javascript I would have the form on the webpage but hidden via javascript, then use Colorbox to load use that content for the popup when required.
Related
The problem is quite simple to understand but quite hard to execute. I am currently facing some clients that turn off their browser Javascript by default and this screw up my website a bit. Since my website send ajax requests on form submit, stop the form submit using Javascript, turning JS off means the form will be sent through and that's unexpectedly.
What I am trying to ask and achieve is whether it is possible to just using html purely to stop a form from submitting?
I think the best answer is; to have the original form action point to an error page, asking the user to turn on javascript.
Then let your javascript code fill in the form action parameter, once the ajax state is complete.
Alternatively or additionally, you could use a <noscript> tag as suggested in the comments, to generate a message on the original page.
I think you can simply change your submit button tag to an input and style it to look like a button and remove the type="submit" that's all. with out ajax it will not respond.
I have a radio button field on a lotus notes form (say main form). If it is selected as "Yes", a link gets unhidden. On click of this link, another form opens up. If in the radio button, "Yes" is selected in the main form, the contents in the second form must be filled. So I need to write a validation if the radio button field is "yes" and the field inside the second form is not filled, then it should show a popup asking to fill the field in the second form. How do I get the value of the field in the second form on the main form for me to perform the validation?
You literally cannot do what you've described you want to do. The second (pop-up) form and its content no longer exist in the client (browser) context when you want to do validation on the first form's data. There are three possible ways to tackle the problem but only two of them are actually practical.
Let's dispense with the impractical method first. That would have the pop-up form write something back to its parent/opener, either as a JavaScript variable or as DOM content (a field outside of the Domino form or hidden element or some such) or, perhaps as a cookie value. Setting up the opener relationship reliably can be a problem cross-browser, but it is doable. The problem is that no matter how you do this, you have no guarantee that the value will be there when you need it (or expect it) except when the parent form is initially filled out. If the document is ever edited, you have no way of knowing whether or not the user has filled in the data on the pop-up. Anything you may have written to JS variables or the DOM during the initial session with the form only exist during the initial session. Cookies aren't permanent; they can be cleared by the user even if you try to give them eternal life via the expires value. No matter how you do it, you'd be telling anybody who has previously filled out the data you want that they need to fill it out again.
The second method would be to make a call back to the server to see if the pop-up form has been submitted and turned into a Notes document. That doesn't scale at all; even if everything is happening on a single server, there's no way to guarantee that the document you are looking for will have been written and indexed by the time you need it, and there is a time factor involved. If the user has already seen the validation nagging once, does what you tell them to do, and then gets the nag again, you're not making any friends.
The third method is to do everything you need to do on one form. (You can use CSS to do the pop-up if you're married to the pop-up idea.) And, you know, it really doesn't matter at all whether or not you would prefer to do it another way, it's the only way that will be reliable and make happy users. Yes, it will mean a little bit of extra work on your part. You're a developer - that's what you do for a living. You can even keep the structure of the existing application intact; WQO and WQS agents mean that you can glue documents together before sending them to your user, and pull them apart again before you save them. This is the only method that is guaranteed to be fast enough and reliable enough to be usable on the web.
I have a multi-step form for capturing leads and generating potential client estimates. I modified a framework that I found elsewhere on the web. The form looks and works beautifully now, but I need to pass the values from the form through PHP to email. I'm not a stranger to this process, but I believe that something in the Javascript required to make the form beautiful and interactive is voiding the values that should be passing from the form to the email.
What I have done to test (trust me, I hate to bother people, but this is driving me nuts):
I eliminated the fieldsets and any other extra form-formatting, all links to CSS and Javascript. I tested the form and it worked as expected. I took the name in the name="name" field and emailed it to me no problems.
I systematically reconstructed the form until it was complete with fieldsets and CSS. I tested at every step and the form continued to pass the name into the email.
Finally, I added the javascript used for transitions and calculations to the bottom of the page and it no longer performs as expected. It triggers the PHP, but it doesn't redirect as I want it to. and it sends the labels in the email, but doesn't pass the values from the form. If I move the Javascript links to the head, the transitions don't occur making it impossible to navigate to the submit button. Any clues?
Here is the link to the form: http://bigislandwebsitedesign.com/test_form.html
You can follow the links to the various scripts from the source.
Sorry if this one has been answered somewhere else but couldn't quite find the fool proof answer I need.
I have a update form page that contains a number of iframes, each iframe contains another form. I need to be able to hit submit on the parent page and as well as submitting the parents form fields but also the iframes form fields all to the same php script.
Looks like javascript is the way to go but I am a complete beginner with javascript so need some extremely dumbed down help and how to.
I am trying to figure out the best way to acompish "unobtrusive" forms for a user (within a web app).
The purpose: keep user on the site by not asking to fill unnecessary form in. Ask for the details as only when such are needed.
The requrements are:
User should provide additional details only when it is required (email to receive notifications, login required for account page, save credit card details when checking out).
User should not leave the current page providing the additional details.
The implementation would be fairly easy if all requests would be AJAX ones. It would be easy to analyse the response (401 or so) and show the appropriate lightbox-form.
I do not see how it can be done "the right way" with plain anchors and form submits as in both cases the user actually leaves the page (by following the link or submitting a form) and there is no way to analyse the response on the client side.
Converting all links and forms to AJAX ones would be just silly.
The closest analog to what I want to achieve is the default Basic Authentication dialog in most of the browser. But obviously that just doesn't fit my requirements.
Any creative suggestions how to do that for non-AJAX requests?
Regards,
Dmytrii.
In a page sense, where "page" refers to what the user sees and not what the URL is, I only can think of following ways to update independent parts in a page with JavaScript (and thus Ajax) switched off:
Frames
Iframes
Using held-open connections there are two more ways to update a page, however these do not work reliably in all cases:
Animated GIF
CSS DIV tags with absolute positioning.
Note that this needs that your Server can keep open a session for each person looking at the page, which can be thousands. If this does not work the only possible workaround is with FRAMEs and automatic refresh, which is somewhat clumsy.
As I think that you do not want to use Frames and you do not want to render animated GIFs, I explain the CSS DIV way:
When you load the page you do not finish loading it. Instead the connection is kept open by the web server and the script handling the connection waits for additional information to arrive. When there is additional data, this is sent to the browser by encapsulating it into additional DIV tags which can overwrite other parts of the page.
Using "style" in the DIV tag and CSS position:absolute these can overwrite other information on the page like a new layer. However you need either position:absolute or must add this data to the end of the page.
How does this work with forms?
Forms usually have a known size so you can put them into IFRAMEs. These IFRAMEs get submitted to the webserver. The script there notifies the other script that new data must be output, so the waiting script renders the response and displays it in the page while the script which took the submit redisplays the form with fresh values only.
How does this work with 404 and anchors?
I don't really know because this must be tested, but here is a hint how I would try to implement this:
We have 2 issues here.
First the URL must not point to other pages but back to a server script again, so the href is under control. This script then notifies the waiting script to update the page accordingly, for example by retrieving the page and sending it to your browser. The script can check for 404 as well.
Second you must hinder the browser to switch the page when clicking on the anchor. This probably involves some clever tricks using CSS, target and server side status codes (like "gone" or redirect to the current page, whatever) to keep the browser from switching the page. I am not completely sure if that works, but if you remember download pages, these show URLs which do not switch the page but have an effect (downloading the file). That's where to start to try to hack browsers not leaving the current page without using JavaScript.
One idea not followed here is not keeping the connection of the page open but the CSS file and send new css information to the browser which then "fills in empty stubs" using the CSS way. But I doubt that this works very well, most browsers probably will parse the CSS only after loading finished, but perhaps I am wrong.
Also note that keeping a connection open never finishes the page loading, so you will see the busy-logo spinning all the time, which is unavoidable with this technique.
Having said this all I doubt you get around JavaScript.
What I wrote here is very difficult to do and therefor usually is not used because it scales badly. And it is a lot more difficult than using JavaScript alone (that's why I explained it).
With proper AJAX it is much more easy to reach your goal. Also note that you do not need to change your page source much, all you need is to add a script which augments the page content such, that for example forms suddenly use AJAX instead of a direct POST with re-rendering the page. Things which cannot be detected easily then need some hints in the tags such that the tag scanner knows how to handle the tag. The good thing then is, that with JavaScript switched off your page still works - however it then "leaves the page".
Normal HTML just was not designed to create application-like web pages like we want to see today. This all was added using JavaScript.
About popup forms
The Basic-Auth-Handler reloads the page after the user enters something into this dialog, only if cancel is hit the current page is displayed.
But there are two ways to present additional query-popups in a page using JavaScript:
The first one is the javascript "prompt", like in following example:
http://de.selfhtml.org/javascript/objekte/anzeige/window_prompt_vor.htm
(Click on the "Hier").
The second one is "JavaScript forms" which are like popups within an HTML-page.
However I consider popups to be far too intrusive and bad design.
Ajax and JavaScript is the easiest way
Unfortunately using JavaScript is never easy, but if you think JavaScript is improper or too difficult, there is no other technique which is easier, that's why JavaScript is used everywhere.
For example your page onload-Script can cycle through all Anchor-Tags and modify them such, that clicking on them invokes a function. This function then must do something clever.
Same is true for Forms. Fields which can be modified (like the user's eMail address) then have two views, on is visible, the other one hidden. The hidden one is a form. Clicking on the eMail address then switches the view (disables the first div and enables the second), such that suddenly instead of the eMail address a text form field is there containing the eMail address. If you click on the "OK" button the button changes the look into a spinner until the data is submitted, then the view switches back to the normal one.
That's the usual way to do it using JavaScript and Ajax. And this involves a lot of programming until it works well.
Sorry for not shortening this post and missing code snippets, I am currently lacking time ;)
Hidden iframe.
Set target attribute of the form to the name of the iframe. use the onload event of the iframe to determine what is the response.
Or, if you really dont like any javascript, don't hide the iframe and instead present it in a creative manner.
CSS to hide an element
#myiframe { position:absolute; left: -999em; display: none; visibility: hidden; }
But normally, display: none is enough. This is just an overkill.