I wonder the difference between:
<form method="post" action="">
and
<form method="post" action=".">
I have read this interesting thread. It looks like blank action is handled by all browsers. Some say the period is not a good idea but they don't say why.
Furthermore, this thread is quite old now so i think it would be useful to have an update on the subject.
Thanks.
The blank represents that the result display of the form will display within the same page. Let say if you input the name, address, tel # etc.... and press the submit button. The collected information will display within the same page (probably below the form). I usually do this when i design a form to make sure it works. But there are various reason why they leave it blank instead putting another target page.
Related
Does anyone know how to get the relevant u code in this strng from mail chimp? they used to have chiclets that included this string but not anymore.
Here is an example of one that works and outputs that number:
http://themebeans.us6.list-manage2.com/subscriber-count?b=00&u=57e41705-395c-4dc2-a09b-78cff10f08f6&id=739445b065
I have tried to follow this method with mine e.g.:
http://richpearsondesigner.us7.list-manage.com/subscriber-count?b=1&u=5b14adb7f3334132a65f527cb&id=e98cecd630
However as you can see when you add both URL's to the browser themebeans works and mine errors, I'm assuming it's the 5b14adb7f3334132a65f527cb part that is wrong (no - in the string)
Any help from anyone pleaseeeee.
So, a quick look through the coding on this Smashing Magazine page revealed the following:
<script type="text/javascript" language="JavaScript" src="http://smashingmagazine.us1.list-manage1.com/subscriber-count?b=34&u=e768e688-36c3-4c2d-88fa-982d9d3f254b&id=a1666656e0"></script>
Note how this script simply relies on the user knowing the correct information for the various parameters. This means we can go and find out what our ‘list-manage.com’ datacenter is, our ‘u’ ID number is, and finally our ‘ID’ number.
How to
Log into your MailChimp account and select the list you wish to use for your subscriber count button. Select Signup Forms then Embedded, so that we can reveal the code used to make a signup form specifically for the selected list.
Select the Naked option, and you should see code similar to the following:
<!-- Begin MailChimp Signup Form -->
<div id="mc_embed_signup">
<form action="http://YOUR-USERNAME-HERE.YOUR-DC.list-manage.com/subscribe/post?u=YOUR-U-NUMBER&id=YOUR-ID-NUMBER" method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate" target="_blank" novalidate>
So we simply replace these details with those in the code above, and we get your very own Subscriber Count Button!
Originally posted here
I'm creating a form where the user will enter data, then click "Review" to see the data they entered. Then after review, "Save" the record.
I'm using a <cfform> to submit the form but wonder how to submit the data to the database from the "Review" page since there's no form here.
Should I set variables like FORM.Name = VARIABLES.Name to display on the review page, then convert them back after they submit the "Save"?
Not really sure what to do here. Overthinking?
Just keep in form scope. Basic output of form values, using baked in form.fieldList:
<cfloop list="#form.fieldList#" item="fieldName">
<cfoutput>
#fieldName#: #form[fieldName]#<br>
<input type="hidden" name="#fieldName#" value="#form[fieldName]#">
</cfoutput>
</cfloop>
Link to original form or submit to page where you save it, using values from hidden fields (which should mirror original form values)
A few other ways you could do this, but this seems simplest to me.
Why not using a second form with hidden input fields for the review page? Confirm would be a submit button to the page that saves the data to the server.
Second possibility (not that proper): save the data directly into the database and load it for the review from there. Trick: use a flag with "confirmed" and set it if confirmed. Bad part about that: you have to clean up older data that has not been confirmed.
Improving on Billy Cravens answer. This protects against the fields having Embedded Attacks
<cfoutput>
#lcase(fieldName)#: #xmlFormat(form[fieldName])#<br>
<input type="hidden" name="#fieldName#" value="#xmlFormat(form[fieldName])#" />
</cfoutput>
Also this will not work for image uploads. The lcase(fieldName) is to keeps the fields from being displayed as all caps. Lowercase is often easier to read.
I need to have a form submitted using the enter key, however, I have to use a BUTTON instead of SUBMIT as the type in order for the page to not refresh. How can I get my BUTTON to act as a SUBMIT and be executed whenever someone pushes their enter key?
<form>
<input type=text ...>
<input type=button ...>
</form>
A lot of the information I found about this mentions Netscape/IE/lots of outdated material.
This is my HTML output, I'm looking to hide the submit button and use ENTER:
http://i.stack.imgur.com/Ohepe.png
with Javascript enabled
<input type="button" onclick="this.form.submit()" ... />
should work
I have to use a BUTTON instead of SUBMIT as the type in order for the page to not refresh
Nah. Use a normal submit button that refreshes the page. (And ideally, for accessibility, make it work!) Then add progressive enhancement to replace the submission action of the form with something smoother when JS is available. Use return false (or event.preventDefault() in the DOM 2 Events model) to stop the form submitting in this case.
<form id="foo" method="POST" action="dosomething.script">
...
<input type="submit" value="Do something"/>
</form>
document.getElement('foo').onsubmit= function() {
beginAJAXSubmission();
return false;
};
Catching the submit event of a form is generally better than trying to pick up click on buttons, because it will always fire when the form would normally be submitted, including on Enter keypresses. click on the first submit button in a form will usually be fired on an Enter keypress, but there are cases (depending on number of controls in the form and what browser it is) where it doesn't happen and so you can end up falling through to actually submitting the form.
as other said, you have to use Javascript. I recommend JQuery framework.
But i don't understand the refresh thing?
Normal way is you hit submit and your form will be sent over a request to the server.
Server process the data and return a response (HTML/JSon..etc) this response will normally be redirect to a result page (to avoid the famous warning about re-post on refresh).
Now if your form is only a little piece of a bigger page, you might want to use ajax to post the little form and then take the result and update your DOM.
All this said, nothing prevent you to use submit type for the button, it is actually the best way to make your enter key defaut to this action. All you have to do is to use Jquery and intercept the submit of your form and make an ajax call instead of going the normal way.
you will find plenty of example to use JQuery since its probably the most used javascript framework.
Hope it help
I have a little problem here. Actually, more of an annoyance.
I have a form on my index page that has a small search form:
<form action="search.php" method="post">
<input name="search" type="text" />
<input type="submit" name="submit">
now on the search.php file I just use the $_POST['search'] to retrieve the value that I'm searching. This file also displays the actual search results, which I can click on to go to that page.The search is actual done on the database. Also, because my search returns the top 10 random results from the DB, if I hit the 'back' button and confirm the warning, the search will be executed again, and will return a different set of results.
The problem, as you know, is that when you click on one of the search results and then hit 'back' on the browser, you get that browser warning about 'To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier.'.
What's the easiest way to prevent this from happening? I looked into that PRG technique but I'm not sure how to implement that.
Any help would be great.
Thanks.
Bruno.
Is it OK to use GET method here, users won't see warning if form sent by GET method.
I am wondering if anyone can give a "best practices" response to using blank HTML form actions to post back to the current page.
There is a post asking what a blank HTML form action does here and some pages like this one suggest it is fine but I'd like to know what people think.
The best thing you can do is leave out the action attribute altogether. If you leave it out, the form will be submitted to the document's address, i.e. the same page.
It is also possible to leave it empty, and any browser implementing HTML's form submission algorithm will treat it as equivalent to the document's address, which it does mainly because that's how browsers currently work:
8. Let action be the submitter element's action.
9. If action is the empty string, let action be the document's address.
Note: This step is a willful violation of RFC 3986, which would require base URL processing here. This violation is motivated by a desire for compatibility with legacy content. [RFC3986]
This definitely works in all current browsers, but may not work as expected in some older browsers ("browsers do weird things with an empty action="" attribute"), which is why the spec strongly discourages authors from leaving it empty:
The action and formaction content attributes, if specified, must have a value that is a valid non-empty URL potentially surrounded by spaces.
Actually, the Form Submission subsection of the current HTML5 draft does not allow action="". It is against the spec.
The action and formaction content attributes, if specified, must have a value that is a valid non-empty URL potentially surrounded by spaces. (emphasis added)
The quoted section in mercator's answer is a requirement on implementations, not authors. Authors must follow the author requirements. To quote How to read this specification:
In particular, there are conformance requirements that apply to producers, for example authors and the documents they create, and there are conformance requirements that apply to consumers, for example Web browsers. They can be distinguished by what they are requiring: a requirement on a producer states what is allowed, while a requirement on a consumer states how software is to act.
The change from HTML4—which did allow an empty URL—was made because “browsers do weird things with an empty action="" attribute”. Considering the reason for the change, its probably best not to do that in HTML4 either.
Not including the action attribute opens the page up to iframe clickjacking attacks, which involve a few simple steps:
An attacker wraps your page in an iframe
The iframe URL includes a query param with the same name as a form field
When the form is submitted, the query value is inserted into the database
The user's identifying information (email, address, etc) has been compromised
References
Bypassing CSRF protections with ClickJacking and HTTP Parameter Pollution
This will validate with HTML5.
<form action="#">
IN HTML 5 action="" IS NOT SUPPORTED SO DON'T DO THIS. BAD PRACTICE.
If instead you completely negate action altogether it will submit to the same page by default, I believe this is the best practice:
<form>This will submit to the current page</form>
If you are sumbitting the form using php you may want to consider the following. read more about it here.
<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">
Alternatively you could use # bear in mind though that this will act like an anchor and scroll to the top of the page.
<form action="#">
I think it's best to explicitly state where the form posts. If you want to be totally safe, enter the same URL the form is on in the action attribute if you want it to submit back to itself. Although mainstream browsers evaluate "" to the same page, you can't guarantee that non-mainstream browsers will.
And of course, the entire URL including GET data like Juddling points out.
Just use
?
<form action="?" method="post" enctype="multipart/form-data" name="myForm" id="myForm">
It doesn't violate HTML5 standards.
I used to do this a lot when I worked with Classic ASP. Usually I used it when server-side validation was needed of some sort for the input (before the days of AJAX). The main draw back I see is that it doesn't separate programming logic from the presentation, at the file level.
I use to do not specify action attribute at all. It is actually how my framework is designed all pages get submitted back exact to same address. But today I discovered problem. Sometimes I borrow action attribute value to make some background call (I guess some people name them AJAX). So I found that IE keeps action attribute value as empty if action attribute wasn't specified. It is a bit odd in my understanding, since if no action attribute specified, the JavaScript counterpart has to be at least undefined. Anyway, my point is before you choose best practice you need to understand more context, like will you use the attribute in JavaScript or not.
When you put empty action then some security filtration consider it malicious or phishing. Hence they can block your page. So its advisable not to keep action= blank.