Ayuda con recojer una variable y preguntar si trae datos o esta vacia

[saymon]

hola a tod@s!!!

Tengo una pequeña consulta, para ver si algun bondadoso o bondadosa me puede ayudar!!

Yo tengo un archivo que evia una data desde un texbox (cantidad) por GET, a otro archivo que se ejecuta, es el script que pongo abajo,

Código PHP:

  <? 
include("lib_carrito.php"); 
$_SESSION["ocarrito"]->introduce_producto($_GET["id"], $_GET["nombre_adulto"], $_GET["precio_adulto"], $_GET["cantidad_adulto"]); 
?>   

eso funciona bien.

Mi consulta esta en que ahora tengo dos texbox en el form, esto hace que repita el codigo de arriba, ya que va a traer datos distintos, tengo que ejecutar el escrip dos veces, pero tengo que tomar en cuenta si los dos textbox envian data, osea que si lleno un solo texbox con data igual se me va a insertar otra linea con el texbox vacio, Coloco el scrip

Código PHP:

  include("lib_carrito.php"); 
$_SESSION["ocarrito"]->introduce_producto($_GET["id"], $_GET["nombre_adulto"], $_GET["precio_adulto"], $_GET["cantidad_adulto"]); 
 
$_SESSION["ocarrito"]->introduce_producto($_GET["id"], $_GET["nombre_child"], $_GET["precio_child"], $_GET["cantidad_child"]);  
   

Este es el codigo que debo ejecutar, pero primero debo preguntarle si el campo $_GET["cantidad_adulto"]) esta vacio o lleno para ejecutar el script y si el campo $_GET["cantidad_child"]) esta tambien vacio o o trae data para ejecutarlo tambien,

Lo que no se es como hago eso son la sintaxis como pregunto eso??
Please, les agradesco cualquier ayuda..

de ante manos muchas gracias y saludos

[DINASEN]

if !isset(($_GET["cantidad_child"])){
si no existe cantida lo que sea
}


Un Saludo

[saymon]

sep, dejame intentarlo, pero mas bien debo preguntar:

La variable viene vacia, Si, ejecuta esto, No: no hace nada, y asi....

[saymon]

hola miren, el codigo que ahora tengo es este :

Código PHP:

  include("lib_carrito.php"); 
 
if !isset($_GET["cantidad_child"]){ 
$_SESSION["ocarrito"]->introduce_producto($_GET["id"], $_GET["description_child"], $_GET["precio_child"], $_GET["cantidad_child"]); 
} 
 
if !isset(($_GET["cantidad_adult"])){ 
$_SESSION["ocarrito"]->introduce_producto($_GET["id"], $_GET["description_adult"], $_GET["precio_adult"], $_GET["cantidad_adult"]); 
}  
   

pero me manda el sioguiente errror:

Código HTML:

Parse error: parse error, expecting `'('' in C:\Documents and Settings\User\My Documents\My Websites\Sitios de Extracion de Code\testing\insert-order.php on line 4

RECAPITULO:
Lo que deseo hacer es confirmar que la variable cantidad_child y cantidad_adult traigan datos (los recojo de un texbox) para despues ejecutar el script que ven dentro de la condicion "if"

Saludos y gracias por cualquier ayuda

[dwaks]

Falto un parentesis

Código PHP:

  include("lib_carrito.php");  
 
if(isset($_GET["cantidad_child"]){  
$_SESSION["ocarrito"]->introduce_producto($_GET["id"], $_GET["description_child"], $_GET["precio_child"], $_GET["cantidad_child"]);  
}  
 
if(isset($_GET["cantidad_adult"])){  
$_SESSION["ocarrito"]->introduce_producto($_GET["id"], $_GET["description_adult"], $_GET["precio_adult"], $_GET["cantidad_adult"]);  
}  
   

Saludos,

[saymon]

gracias dwaks!!

la sintaxis la corregi pero aun asi el mismo script no hace lo que debe hacer, que es ejecutar el script (dentro de if) si la variable cantidad_child (primera condicion) trae datos, osea que no este vacia (el mismo es un textbox que recoje unos numeros)

En resumida la condicion debe ejecutarse si el usuario lleno este campo.

Saludos y gracias por cualquier ayuda

[sebtev]

Todo debería de funcionar, salvo q en el código anterior falta un !
es decir:

Código PHP:

  if(!isset($_GET["cantidad_child"])  
   

Saludos cuidate

[dwaks]

Bueno tengo entendido que el signo ! es una negativa osea que si la funcion isset devuelve true por defecto si la variable esta setiada entonces pasa lo que saymon quiere.

Pero si le colocas !isset entonces es la negativa que seria Si no esta setiada que coloque valores a la variable de session.

Po eso le quite el signo !.

Saludos,

[Neuron_376]

isSet = Si la variable ha sido asignada/creada...

Entonces aunque la variable este vacia es muy posible que tome esa condicion como VERDADERA, porque la variable si esta creada pero con un valor nulo o vacio.

Entonces, bueno, puedes intentar esto:

if (empty(trim($variable)))

Suerte!!

[Spielberg]

Si no he entendido mal lo que quieres es que las dos variables vengasn llenas no?pues entonces deberías hacer algo del tipo;

if (!$_GET["cantidad_child"] == ""){
if !isset(($_GET["cantidad_adult"]{
}}

pero no sé si es esto un saludo

Spielberg

------------------------------
Nos vemos en www.inmonet.net

[saymon]

Me funciono perfecto la primera linea if (!$_GET["cantidad_child"] == ""){ eso era lo que deseaba hacer, gracias por la ayuda Spielberg

Y a todos los que dieron sus opiniones.
Saludos de Panama

Iniciado por Spielberg

Si no he entendido mal lo que quieres es que las dos variables vengasn llenas no?pues entonces deberías hacer algo del tipo;

if (!$_GET["cantidad_child"] == ""){
if !isset(($_GET["cantidad_adult"]{
}}

pero no sé si es esto un saludo

Spielberg

------------------------------
Nos vemos en www.inmonet.net

[nicolaspar]

Igual, disculpen que me meta, pero eso no es del todo correcto. Lo correcto es que si esta seteada (isset), ahí veamos si esta vacia o no (empty), y no al revez, por que puede, depende de la configuración del servidor, tirar error, o que es peor, no tirar error en pantalla pero si tener un error lógico en la aplicación. Por lo que el código sería:
if(isset($_GET["cantidad_child"]) && !empty($_GET["cantidad_child"] ) ){
...aca lo que necesites...
}

;)

[Neuron_376]

Pero lo mas seguro es esto:

$variable = $_GET["variable"];

if (empty(trim($variable)))

Asi validas cualquier caso raro.

[nicolaspar]

Eso no soluciona lo que yo mensionaba.
Pero, en que es mas seguro eso?

[Neuron_376]

Yo no hablo del caso exacto que estan poniendo aqui, simplemente del metodo que se debe siguir para validar una variable...

Por ejemplo:

Si mandas una variable con datos ratos, o espacios en blanco, etc. lo cual es posible si la manda ENCODE, entonces simplemente decir ISSET no funcionara bien, hay que eliminar los caracteres raros y revisar que no este vacia, es un metodo de validacion general para, Session, Cookies, Post, Get, etc.

$var = $_GET["var"]; ... Si esta variable viene con un Tab, un Retorno de Carro, etc.

ISSET($Var) = True

Pero:

if (empty(trim($Var))) = False

Por eso digo que es la mejor manera de estar seguro, bueno, todo depende claro, pero por eso dije que lo probara segun sus necesidades...

La filosofia es:

1. Recupera la variable
2. Valida la variable
2.1 Que no tenga caracteres que no permites para esta variable
2.2 Que no este vacia

Ese metodo se aplica para todas las variables.

Pero por lo que mencinas seria asi entonces...

if (isset($_GET["var"])
{
$var = $_GET["var"];
if (empty(trim($Var))) = False
}

Esto para evitar el error que dices, pero necesitas hacerlo por separado para que funcione bien, hablo del ISSET y del empty, ademas añades el TRIM

[nicolaspar]

Quiero aclarar que este tipo de "charlas" no las tomo, ni como criticas, ni como peleas (aclaro esto antes de continuar, por que mucha gente cree eso y despues terminamos todos en la pileta de barro y aceite:D), sino como cruces de conocimientos, ya que para esos estamos aca, y es para aprender, y esta en particular esta interesante.
Aclarado eso, te comento que tenes los conseptos mezclados, y no muy claros.
Es válido lo que decis de validar el contenido, pero poniendo un trim no lo estas haciendo.
Una cosa es el isset que lo que hace es devolverte 1 o 0 dependiendo de si la var esta seteada o no.
Siguiendo con esto, y tratando de no salirme mucho del tema, si vos haces:
$var = $_GET["otraVar"];
Estas asignando a $var algo que no esta seteado (en el caso de que otraVar no este por get), por lo que en si el php.ini decis no mostrar los warning, no tendrás un error en pantalla, pero si un error lógico en la aplicación.
O sea, para esto lo logico es:
#Si es un string:
$var = isset($_GET["otraVar"]) ? $_GET["otraVar"] : 'undefined';
Esto te asegura que $var estará siempre seteada, sea con el valor pasado por get, o por el valor puesto entre los ''.
El tema de la sintaxis es algo de cada uno, por lo que es lo mismo que hacer:
if(isset($_GET["otraVar"])):
$var = $_GET["otraVar"];
else:
$var = 'undefined';
endif;
O hacer:
if(isset($_GET["otraVar"])){
$var = $_GET["otraVar"];
}else{
$var = 'undefined';
}

A esto agregale un trim (que no te solucionara nada), o pasalo por alguna función que te limpie este str de ',--,/**/, etc.
Si es un valor númerico entero, con pasarlo por un intval() será mas que suficiente.
Si queres mas seguridad podes pasarlo por un hash y un md5, validar integridades y demás que salen para otro lado.
El tema que decis "pero necesitas hacerlo por separado para que funcione bien" es lo que esta haciendo el if, podrías usar el and, para decir haceme la primer condicion y la segunda, o el && para decir haceme la primera, y la segunda solo si la anterior es valida, por lo que hacer esto:

if(isset($_GET["cantidad_child"]) && !empty($_GET["cantidad_child"] ) ){

Es hacer ambas cosas en la manera que están ordenadas en el if, primero el isset, despues el not empty.
Si me equivoque en algo, que esprovable, que alguién lo corrija.

Saludos.

[Neuron_376]

Si, bueno, para empezar, yo tampoco lo veo como pelea, si no al contrario, veo muy provechosas estas palticas.. asi lo veo yo...

Tu sentencia:

if(isset($_GET["cantidad_child"]) && !empty($_GET["cantidad_child"] ) ){

No se exactamente como trabaja el compilador de php, pero por lo general y normal lo que quieres hacer funcionaria asi...

if isset($_GET["cantidad_child"] = False --> Aun sigue la compilacion porque es una sola linea.

if !empty($_GET["cantidad_child"]) ---> Aqui ocurre el error que mencionabas, porque esta variable no existe, que es el error que mencionabas

Entonces, tener todo en una sola linea esa sentencia puede tener el error que tu mencionaste, asi que esa linea no soluciona el problema...

Por eso mencionaba esta forma:

if (isset($_GET["var"]) --> Verificar si existe la variable.
{

$var = $_GET["var"]; --> Recuperar la variable tal como esta.
$var = trim($Var); --> Limpias la variable de espacios en blanco, y caracteres raros como TAB.

if empty($Var) --> Ahora si sabes que la variable esta totalmente limpia, y aseguras que esta sentencia es correcta, despues de esto y puedes convertir la variable al tipo que necesitas y ver errores de TIPO_DE_DATOS, algo como:

$var = (int)%var;

}

Pero ya te aseguraste de que la variable es valida... con el Isset solamente pasa esto:

_ = Espcio en blanco

$var = "__cadena_" = True
$var = "___" = True
$var = "[TAB]" = True

Entonces, ahi esta el error de usar solo Isset y Empty, porque Empty dice que la cadena no esta vacia porque encuentra espacios vacios.

Tambien algo como

$var = NULL = True (Isset), False(Empty)

Entonces ese es el detalle donde veo que cae el error.

Por eso decia que era mejor, primero tener las lineas separadas por como trabaja el compilador al evaluar esa linea, y tambien el detalle de tener cadenas sucias que no seran detectadas por esa linea.

Bueno, esa es mi manera de mirar ese caso, y de hecho a ese tipo de validaciones aplica como te digo para todo, Get, Post, Session, Cookies, etc, y tambien para otros lenguajes como ASP.

Ademas... jejejeje, validar de esa forma te quita muchos problemas, como SQL Injection, etc.

Bueno, ese es mi punto de vista... un saludo

[nicolaspar]

Iniciado por Neuron_376

Si, bueno, para empezar, yo tampoco lo veo como pelea, si no al contrario, veo muy provechosas estas palticas.. asi lo veo yo...

Tu sentencia:

if(isset($_GET["cantidad_child"]) && !empty($_GET["cantidad_child"] ) ){

No se exactamente como trabaja el compilador de php, pero por lo general y normal lo que quieres hacer funcionaria asi...

if isset($_GET["cantidad_child"] = False --> Aun sigue la compilacion porque es una sola linea.

if !empty($_GET["cantidad_child"]) ---> Aqui ocurre el error que mencionabas, porque esta variable no existe, que es el error que mencionabas

Entonces, tener todo en una sola linea esa sentencia puede tener el error que tu mencionaste, asi que esa linea no soluciona el problema...

Por eso mencionaba esta forma:

if (isset($_GET["var"]) --> Verificar si existe la variable.
{

Claro, acá es donde no es así, sino que ejecuta primero uno, y después el siguiente, por eso no use "and", sino "&&".

Iniciado por Neuron_376

$var = $_GET["var"]; --> Recuperar la variable tal como esta.
$var = trim($Var); --> Limpias la variable de espacios en blanco, y caracteres raros como TAB.

if empty($Var) --> Ahora si sabes que la variable esta totalmente limpia, y aseguras que esta sentencia es correcta, despues de esto y puedes convertir la variable al tipo que necesitas y ver errores de TIPO_DE_DATOS, algo como:

$var = (int)%var;

}

Pero ya te aseguraste de que la variable es valida... con el Isset solamente pasa esto:

_ = Espcio en blanco

$var = "__cadena_" = True
$var = "___" = True
$var = "[TAB]" = True

Entonces, ahi esta el error de usar solo Isset y Empty, porque Empty dice que la cadena no esta vacia porque encuentra espacios vacios.

Tambien algo como

$var = NULL = True (Isset), False(Empty)

Entonces ese es el detalle donde veo que cae el error.

Por eso decia que era mejor, primero tener las lineas separadas por como trabaja el compilador al evaluar esa linea, y tambien el detalle de tener cadenas sucias que no seran detectadas por esa linea.

Bueno, esa es mi manera de mirar ese caso, y de hecho a ese tipo de validaciones aplica como te digo para todo, Get, Post, Session, Cookies, etc, y tambien para otros lenguajes como ASP.

Está bien, eso es válido, pero con mas razón, no esta mal lo que yo puse, intenta, hacete un archivo con esto:
if(isset($_GET["cantidad_child"]) && !empty($_GET["cantidad_child"]) ){
echo "si";
}else{
echo "no";
}
Y llamalo y probá de ponerle un espacio en el get a esa variable, y verás que el resultado es siempre "no".

Iniciado por Neuron_376

Ademas... jejejeje, validar de esa forma te quita muchos problemas, como SQL Injection, etc.

Está perfecto tener en vista medidas para sql injection, pero con el trim() no solucionas nada...lo primero que debes tener en cuenta es que no puedan meterte sentensias como having, group y demás esta decir que si pasa un drop estas frito, aunque quien vaya directo a esto no es peligroso

Bueno, ese es mi punto de vista... un saludo

De la misma manera, y espero que no termine acá

[Neuron_376]

Ya nos estamos poniendo de acuerdo...

Yo no sabia que con && evitabas el problema del compilador, tu dices que esto pasa entonces

if (!isset($_GET["cantidad_child"]) --> False ... el compilador se sale porque tienes el && y NO SE EJECUTA LA SEGUNDA LINEA

?????

Ahi es donde aun me queda la duda, de hecho yo pensaba que el && era exactamente lo mismo que and, y de hecho me parece que && realmente fuerza a ejecutar la segunda sentencia, no recuerdo porque, pero me parece que asi es, que con el && fuerzas a ejecutar ambas para evaluarlas porque las estas asociando para obtener resultado, mientras que and va evaluando 1 por 1 porque no tiene propiedad asociativa, eso es lo que recuerdo mas o menos. Pero igual, creo que con ambas la linea se ejecuta completa.

Solo que asi:

&& --> (sentencia1 && sentencia2)
and -> sentencia1 and sentencia2

Es decir, primero 1 y luego la otra, un ejemplo que encontre de esto ahorita:

$a && $b || $c -----> (a [y] b) or c
$a AND $b || $c ----> a [y] (b or c)

Lo investigue ahorita para no escribir mentiras de esto, pero igual aun pienso que se ejecuta la linea completa, aunque si no fuera asi, tendria que ser con AND y no con &&, porque && si esta forzando a realizar las dos sentencias, mientas que AND no, y asi con AND el compilador podria decir...

a = False ---> Sigue un AND ? Si si sigue un AND, entonces el resultado es False porque ya se que lo primero es falso.

En cambio con el && nunca podria hacer esa distincion porque por la propiedad de asociacion del && esta obligado a ejecutar las sentencias completas.

Lo que menciona del $_GET, bien, no puedes mandar datos con basura, pero si lo pasas como URLENCODE entonces podras mandar cadenas sucias como "__valor" "_[TAB]" etc, y esa linea que tienes no funcionara, el Isset dira true y el Empty dira False, lo que hace que pueda continuar adelante, en cambio de trim si te limpia de espacios a los lados, y de caracteres raros, por lo tanto deja una cadena vacia totalmente correcta como:

trim("_") = ""
trim("_[TAB]") = ""
trim("cadena__") = "cadena"

Entonces si sirve de mucho el trim, del SQLInjection tienes razon, faltan mas validaciones, pero este proceso es solo la primera parte, como dije, el sieguiente paso es convertir y verificar el TIPO de dato que debe ser esa variables, etc... pero eso es mas adelante.

Poco a poco sacamos los detalles no crees...

[nicolaspar]

Iniciado por Neuron_376

Ya nos estamos poniendo de acuerdo...

Yo no sabia que con && evitabas el problema del compilador, tu dices que esto pasa entonces

if (!isset($_GET["cantidad_child"]) --> False ... el compilador se sale porque tienes el && y NO SE EJECUTA LA SEGUNDA LINEA

?????

Ahi es donde aun me queda la duda, de hecho yo pensaba que el && era exactamente lo mismo que and, y de hecho me parece que && realmente fuerza a ejecutar la segunda sentencia, no recuerdo porque, pero me parece que asi es, que con el && fuerzas a ejecutar ambas para evaluarlas porque las estas asociando para obtener resultado, mientras que and va evaluando 1 por 1 porque no tiene propiedad asociativa, eso es lo que recuerdo mas o menos. Pero igual, creo que con ambas la linea se ejecuta completa.

Solo que asi:

&& --> (sentencia1 && sentencia2)
and -> sentencia1 and sentencia2

Es decir, primero 1 y luego la otra, un ejemplo que encontre de esto ahorita:

$a && $b || $c -----> (a [y] b) or c
$a AND $b || $c ----> a [y] (b or c)

Lo investigue ahorita para no escribir mentiras de esto, pero igual aun pienso que se ejecuta la linea completa, aunque si no fuera asi, tendria que ser con AND y no con &&, porque && si esta forzando a realizar las dos sentencias, mientas que AND no, y asi con AND el compilador podria decir...

a = False ---> Sigue un AND ? Si si sigue un AND, entonces el resultado es False porque ya se que lo primero es falso.

En cambio con el && nunca podria hacer esa distincion porque por la propiedad de asociacion del && esta obligado a ejecutar las sentencias completas.

Creeme lo he investigado, hace unos meses se me vino la duda. Sino, probalo y veras, no es tan tremendo hacer un archivoto php y testear lo expuesto

Iniciado por Neuron_376

Lo que menciona del $_GET, bien, no puedes mandar datos con basura, pero si lo pasas como URLENCODE entonces podras mandar cadenas sucias como "__valor" "_[TAB]" etc, y esa linea que tienes no funcionara, el Isset dira true y el Empty dira False, lo que hace que pueda continuar adelante, en cambio de trim si te limpia de espacios a los lados, y de caracteres raros, por lo tanto deja una cadena vacia totalmente correcta como:

trim("_") = ""
trim("_[TAB]") = ""
trim("cadena__") = "cadena"

Entonces si sirve de mucho el trim, del SQLInjection tienes razon, faltan mas validaciones, pero este proceso es solo la primera parte, como dije, el sieguiente paso es convertir y verificar el TIPO de dato que debe ser esa variables, etc... pero eso es mas adelante.

Poco a poco sacamos los detalles no crees...

Las cosas se aclaran, pero te repito, si es de espacios, no es necesario para lo que yo expuse.
Si hablas del trim con sql injection no te saca ningun codigo maligno.
No digo con esto que sea una función que no sirva para nada, sino que en este caso no esta justificada.

[Neuron_376]

Lo de trim de Sql Inyection dejemoslo por la paz, olvidemos sql inyection, fue un error mencioanarlo , bueno de lo otro...

1. Estas seguro que con && si no se cumple la primera condicion, el compilador se para y no sigue a la segunda condicion ?

Mira, aqui lei eso del ejmplo, lo recordaba pero no lo tenia claro, y creo que esa fue mi razon principal para usar AND simepre en lugar en &&, hace mas de 1 año que hice mis funciones de recuperacion, entonces no recordaba la razon exacta, por eso volvi a buscar:

http://mx.php.net/manual/es/language...ors.precedence

2. Que pasa si a tu script llegas asi:

"<a href='tuarchivo.php?var=' . URLENCODE(' ')" .... (NO recuerdo la funcion para URLENCODE)

Lo que pasa es esto:

Isset = True
Empty = False

Esto hace que puedas manipular esta variable como hubiera algo.. para evitar eso usas TRIM, para quitar elementos sucios, y caracteres en blanco inservibles.

Estas de acuerdo con eso ?, sino, dime que pasa en verdad con esa posibilidad ?

3. Recuerda que aunque tu nunca vas a hacer esto en tu codigo, cualquier atacante puede crear paginas espejo y llegar a tu script poniendo los valores que le pegue la gana, sin que tu tengas control, entonces debes preparar tu script para cualquier caso extraño, no solo para los casos normales.

Un saludo.. esto esta muy interesante.

Gracias.

[nicolaspar]

Iniciado por Neuron_376

Lo de trim de Sql Inyection dejemoslo por la paz, olvidemos sql inyection, fue un error mencioanarlo , bueno de lo otro...

1. Estas seguro que con && si no se cumple la primera condicion, el compilador se para y no sigue a la segunda condicion ?

Mira, aqui lei eso del ejmplo, lo recordaba pero no lo tenia claro, y creo que esa fue mi razon principal para usar AND simepre en lugar en &&, hace mas de 1 año que hice mis funciones de recuperacion, entonces no recordaba la razon exacta, por eso volvi a buscar:

http://mx.php.net/manual/es/language...ors.precedence

Esta bien, es lo que trataba de explicar...o no?

Iniciado por Neuron_376

2. Que pasa si a tu script llegas asi:

"<a href='tuarchivo.php?var=' . URLENCODE(' ')" .... (NO recuerdo la funcion para URLENCODE)

Lo que pasa es esto:

Isset = True
Empty = False

Esto hace que puedas manipular esta variable como hubiera algo.. para evitar eso usas TRIM, para quitar elementos sucios, y caracteres en blanco inservibles.

Estas de acuerdo con eso ?, sino, dime que pasa en verdad con esa posibilidad ?

Acá ya metemos a urlencode, y urldecode para este caso y no es lo que se trataba antes...como tu ejemplo te puedo nombrar 1000 básicos, pero me salgo del tema.

Iniciado por Neuron_376

3. Recuerda que aunque tu nunca vas a hacer esto en tu codigo, cualquier atacante puede crear paginas espejo y llegar a tu script poniendo los valores que le pegue la gana, sin que tu tengas control, entonces debes preparar tu script para cualquier caso extraño, no solo para los casos normales.

Un saludo.. esto esta muy interesante.

Gracias.

Se, el control se puede tener tranquilamente, pero nuevamente, ese es otro tema...yo había planteado algunas dudas del tema en un post por estos lugares.

[Neuron_376]

Tambien ya me salgo del tema , de todas forma un gusto haber hablado esto... se que soy un traumado con el orden y la logica en la programacion, para mi todo se tiene que hacer con un orden especifico que te asegure muchas cosas, aun lo del compilador no me es claro, entonces es mejor hacerlo por separado la sentencia, eso basado en tu comentario del posible error me deja mas claro que el orden del isset es correcto, y lo implementare de aqui en adelante, por otra parte lo del trim, es solo seguridad de que mis datos estan limpios y ademas que realmente no estan vacios, tal vez como dices, es posible que en GET no aplique, y esta bien, pero en POST creo que sera totalmente valido porque ya me ha pasado antes, eso lo digo por experiencia, entonces estamos bien, no me ha tocado hacer pruebas sobre un cliente que arroje el error que mencionas, pero si me dices que ocuerre entonces tomare mis precauciones usando el metodo que te mencione, usar el isset antes que nada, y despues dedicarme a limpiar y verificar la variable, esto porque no estoy seguro de la forma de trabajar del compilador, entonces es mejor prevenir que lamentar, estoy enfermo con eso de la seguridad y el orden, pero creeme que es lo mejor

Aqui en los foros he leido muchas cosas acerca de errores imprevistos, y cuando ponen sus codigos te das cuenta que estan muy mal diseñados, entonces mejor asi

Habia quien decia que era mejor validar solo en JavaScript , por Dios, que es eso... jajajaja, pero bueno, muy buen tema, me deja cosas buenas como el error que mencionaste que debo prevenir.

Suerte!!

Consejo: No te fies del codigo "seguro", ni de las variables que recibes, siempre debes hacer todo lo necesario para asegurar que todo esta correcto.

Un gusto platicar contigo.

[nicolaspar]

Ok!...y también ha sido un gusto hablar del tema, aunque sea de manera muy especifica sobre este caso en particulas (el isset y el and|&&).