Uso de Formularios HTML

Otra de las caracterÃsticas de PHP es que gestiona formularios de HTML. El concepto bÃ¡sico que es importante entender es que cualquier elemento de los formularios estarÃ¡ disponible automÃ¡ticamente en su cÃ³digo PHP. Por favor refiÃ©rase a la secciÃ³n titulada Variables fuera de PHP en el manual para mÃ¡s informaciÃ³n y ejemplos sobre cÃ³mo usar formularios HTML con PHP. Observemos un ejemplo:

Ejemplo 2-6. Un formulario HTML sencillo
<form action="accion.php" method="POST"> Su nombre: <input type="text" name="nombre" /> Su edad: <input type="text" name="edad" /> <input type="submit"> </form>

No hay nada especial en este formularo, es HTML limpio sin ninguna clase de etiquetas desconocidas. Cuando el cliente llena Ã©ste formulario y oprime el botÃ³n etiquetado "Submit", una pÃ¡gina titulada accion.php es llamada. En este archivo encontrarÃ¡ algo asÃ:

Ejemplo 2-7. Procesamiento de informaciÃ³n de nuestro formulario HTML

Hola <?php echo $_POST["nombre"]; ?>. Tiene <?php echo $_POST["edad"]; ?> años
Un ejemplo del resultado de este script podrÃa ser:
Hola JosÃ©. Tiene 22 aÃ±os

Es aparentemente obvio lo que hace. No hay mucho mÃ¡s que decir al respecto. Las variables $_POST["nombre"] y $_POST["edad"] son definidas automÃ¡ticamente por PHP. Hace un momento usamos la variable autoglobal $_SERVER, ahora hemos introducido autoglobal $_POST, que contiene toda la informaciÃ³n enviada por el mÃ©todo POST. FÃjese en el atributo method en nuestro formulario; es POST. Si hubiÃ©ramos usado GET, entonces nuestra informaciÃ³n estarÃa en la variable autoglobal $_GET. TambiÃ©n puede utilizar la autoglobal $_REQUEST si no le importa el origen de la peticiÃ³n. Ã‰sta variable contiene una mezcla de informaciÃ³n GET, POST y COOKIE. TambiÃ©n puede ver la funciÃ³n import_request_variables().

add a note User Contributed Notes
Uso de Formularios HTML

verisimilidude at sourceforge dot com
18-Jul-2006 01:44


> It is easier to create a link called 

> /website/deleteuser.php?id=<userid> for each, where 

> deleteuser.php contains the (pseudocode):



> $sql = "DELETE FROM usertable WHERE id = " . (int) $_GET['id']; 



Never pass raw data from the user directly into a string that will be passed on to be executed by something else (in this case SQL).  In this case there is no check that the id coming back was ever on the table being displayed - you have given the web user the ability to delete anyone just by editing the name of the page requested.



In this case the id is cast to an int at least.  Without the cast it would be possible to inject ANY sql into the database by asking (for example) /website/deleteuser.php?id="0; select * from another_table;"

Joe
29-May-2006 03:52


Just wanted to add a note:



For beginners, it is wise to use the "GET" method in forms because you can see what is being sent between the server and the web browser.



For example, in the example above, if you change

<form action="action.php" method="post">



to <form action="action.php" method="get">



you would get something like...



http://www.myserver.com/action.php?name=A&age=B



in your web browser.



However, a good idea is to always change the "GET" to a "POST" because the user of the browser cannot change the contents of the information being sent from the form to the webserver.



In the example given above, 



<form action="action.php" method="post">



Would just have,



http://www.myserver.com/action.php



As you can see, no information is visible to the user of the browser.



In other words, _GET and _POST, has a lot of advantage over one another. I personally use "POST" in everything so that the user of the page cannot "spam" it by continually sending information with GET.



Simply put, with "GET" the user can physically change the values that the server gets, whereas with the "POST" method, the user will have a hard time changing the information sent to the server.



For example, if you have a user login service, you definitely want to submit the form by a "POST" so that if someone wants to "change" the account to something like admin, then he would have a hard time doing so because he cannot directly change the information on the browser URL line and then simply send it like that everytime.

David
22-May-2006 09:20


Grant Floyd's suggestion (in a two-year-old comment) to use HTTP GET for destructive actions like deleting users is an extremely dangerous one. It's a basic rule of the Web that HTTP GET should *never* do anything destructive -- any web agent that prefetches URLs for caching, etc., could end up deleting all of your users by following the links in the document.

yasman at phplatvia dot lv
05-May-2005 12:18


[Editor's Note: Since "." is not legal variable name PHP will translate the dot to underscore, i.e. "name.x" will become "name_x"]





Be careful, when using and processing forms which contains 


<input type="image">


tag. Do not use in your scripts this elements attributes `name` and `value`, because MSIE and Opera do not send them to server.


Both are sending `name.x` and `name.y` coordiante variables to a server, so better use them.

grant_floyd at yahoo dot not dot yohoo dot com
21-Apr-2004 09:54


Refering to the GET/POST usage in the HTML specification mentioned:





Although GET will normally be used for requesting information from a webserver the length of the URL is limited to a maximum number of characters. So if you have a form which submits lots of information and text selections you will have to use a POST.





Likewise, sometimes it doesn't make any sense to create a form with a POST method to do something to the server.





For example, if you have a website with a list of users and you want to select one of them to delete, each username could be a 'Delete user' link.  It is easier to create a link called /website/deleteuser.php?id=<userid> for each, where deleteuser.php contains the (pseudocode):





$sql = "DELETE FROM usertable WHERE id = " . (int) $_GET['id'];





Finally, $_REQUEST is the simplest default retrieval method as it combines GET, POST and COOKIE information. One thing to be aware of is that it combines the information in an order of precedence defined by the server.





For example, if a website has a cookie with $username and you make up a POST form and use a variable '$username' you may get the $_POST['username'] value instead of the $_COOKIE['username'], causing you some confusion.





The order is defined on the server as 'variables_order'. This set the order of the EGPCS (Environment, GET, POST, Cookie, Server) variable parsing. The default setting of this directive is "EGPCS". So in the above example 'P' for POST comes before 'C' for COOKIE.

sethg at ropine dot com
01-Dec-2003 12:55


According to the HTTP specification, you should use the POST method when you're using the form to change the state of something on the server end. For example, if a page has a form to allow users to add their own comments, like this page here, the form should use POST. If you click "Reload" or "Refresh" on a page that you reached through a POST, it's almost always an error -- you shouldn't be posting the same comment twice -- which is why these pages aren't bookmarked or cached.



You should use the GET method when your form is, well, getting something off the server and not actually changing anything.  For example, the form for a search engine should use GET, since searching a Web site should not be changing anything that the client might care about, and bookmarking or caching the results of a search-engine query is just as useful as bookmarking or caching a static HTML page.

add a note

MANUAL DE PHP

windsurf mercedes camper

Uso de Formularios HTML