[SOLUCIONADO] PHP OO ¿Una manera inteligente de recoger $_POST?

[guardarmicorreo]

Tengo un esquema tanto conceptual como en código de lo que debe ser un frontcontroller para que el usuario navegue por la web mediante $_GET.

Ahora tengo una duda y no tengo claro qué opción aplicar, me refiero a recoger $_POST.

Supongamos la siguiente situación:

Un usuario llega al home de la web, y le muestro un formulario que se enviará mediante $_POST.

Las dudas son ¿Dónde envío ese formulario?

¿Directamente a la clase y aprovecho la lectura de $_GET en el index.php para detectar $_POST así por ejemplo?

Código PHP:

try{
                        if(filter_input_array(INPUT_GET, $_GET) !== NULL){
                        echo (new \controller\FrontController())->invoke(filter_input(INPUT_GET, $_GET['class']),
                                filter_input(INPUT_GET, $_GET['method']),
                                filter_input(INPUT_GET, $_GET['args']));
                        }
                        
                        if(filter_input_array(INPUT_POST, $_POST) !== NULL)
                                (new controller\BackController())->invoke(filter_input(INPUT_POST, $_POST['class']),
                                filter_input(INPUT_GET, $_POST['method']));
                        
                    } catch (Exception $ex) {
                        echo $ex;
                    }
 

Y con esto haría una reconocimiento (isset) de $_POST en la clase y usaría los $_POST[''] que necesitara.

Otro modo es enviando el formulario al documento donde está la clase y con un try-catch haría un reconocimiento (isset) de $_POST e instanciaría la clase con tantos $_POST que necesite como argumentos.

No se me ocurre muchas más variantes, todas van por este estilo.

Recalcar que el frontcontroller que he construido (sin utilizar Reflection en el código) funciona perfectamente.

Un saludo.

[dashtrash]

La pregunta es previa: tiene alguna utilidad diferenciar entre parámetros GET y POST ? El formato que utilice el protocolo HTTP para enviar información a la página, pertence a ese protocolo, HTTP.Yo, personalmente, no los diferencio.Mis páginas reciben "parámetros", independientemente de que sean $_GET o $_POST

[guardarmicorreo]

Creo que sí tiene utilidad, porque con GET el usuario navega a través de la web:

www.miweb.com/biblioteca/nuevo-libro/

Con eso el usuario directamente estaría instanciando a la clase biblioteca y el método nuevo-libro.

Ahora bien, si el usuario envía el formulario con los datos de un nuevo libro, lo envía mediante POST, y con POST hay que indicar a dónde envía el formulario, entonces ahí ya hay una primera pregunta: ¿Cómo y dónde recojo POST para instanciar la clase que procese esa información?

Resumiendo, creo que solamente hay que utilizar GET para navegar mediante la web y POST para enviar la información entre usuario y servidor (en un ambiente donde no hay javascript, solamente PHP y HTML).

Tal vez en otros frameworks profesionales no haya que hacer la diferencia, pero lo que estoy haciendo y entiendo yo sí tengo esa necesidad de hacer la diferencia, porque con POST no puedes navegar por la web de forma que quede un rastro en el PATH del navegador y el usuario pueda acceder directamente a una sección sin tener que seguir pasos previos, como por ejemplo, ingresar un nuevo libro sin tener que comenzar desde el home.

[Italico76]

Iniciado por dashtrash

La pregunta es previa: tiene alguna utilidad diferenciar entre parámetros GET y POST ? El formato que utilice el protocolo HTTP para enviar información a la página, pertence a ese protocolo, HTTP.Yo, personalmente, no los diferencio.Mis páginas reciben "parámetros", independientemente de que sean $_GET o $_POST

Cierto, pero que no tome tu consejo como ... "usa $_REQUEST" por motivos obvios

De todas formas seria hasta mas seguro que se permitan 'actions' del tipo "delete", "update", "create" provinientes por POST unicamente... claro que obligaria a usar convenciones

[guardarmicorreo]

Si lo necesitais, os puedo dejar el código del pequeñísimo framework que estoy creando para que vean del por qué concluí con la necesidad de diferenciar entre POST y GET. Sin ningún problema, pero ojo, la idea no es mía.

[dashtrash]

Iniciado por guardarmicorreo

Creo que sí tiene utilidad, porque con GET el usuario navega a través de la web:

www.miweb.com/biblioteca/nuevo-libro/

Con eso el usuario directamente estaría instanciando a la clase biblioteca y el método nuevo-libro.

Da igual que al funcionamiento del sistema le lleguen parámetros por GET,POST o la Url de la request. Que se instancie una clase y se llame a un método no depende de que la petición http que llega a tu servidor contenga los parámetros codificados de una forma u otra.

Iniciado por guardarmicorreo

Ahora bien, si el usuario envía el formulario con los datos de un nuevo libro, lo envía mediante POST

...o por GET, si quieres.Porque son intercambiables.

Iniciado por guardarmicorreo

Resumiendo, creo que solamente hay que utilizar GET para navegar mediante la web y POST para enviar la información entre usuario y servidor

Y, si eso es lo que piensas, que es la convención habitual, y tomando exactamente esa frase, para qué necesitas diferenciar GET y POST más allá del enrutador?

[dashtrash]

Iniciado por Italico76

Cierto, pero que no tome tu consejo como ... "usa $_REQUEST" por motivos obvios

De todas formas seria hasta mas seguro que se permitan 'actions' del tipo "delete", "update", "create" provinientes por POST unicamente... claro que obligaria a usar convenciones

Creo que no me explico.Cómo se comunique un navegador web con un servidor http, sea por POST,GET,PUT,DELETE,etc, da lo mismo.Pertenece al protocolo HTTP.
Esa información puede ser usada por el enrutador de PHP , ya que PHP se utiliza para extender la gestión de Urls (cosa que teóricamente hace el servidor web).
Pero al controlador, de dónde han llegado los parámetros, debería darle igual.Como si le llegan de un fichero.
Y, precisamente por cuestiones de seguridad, es por lo que para cada página especifico qué parámetros existen, y su tipo.El enrutador comprueba la existencia de esos parámetros, los sanitiza, los almacena en un registro y establece GET y POST a NULL.
Así mi equipo no tiene la tentación de usar $_GET o $_POST en sitios donde sí que se produciría un problema de seguridad.

[Italico76]

Iniciado por dashtrash

Creo que no me explico.

Cómo se comunique un navegador web con un servidor http, sea por POST,GET,PUT,DELETE,etc, da lo mismo.Pertenece al protocolo HTTP.

Con todo respeto ....




Creo estamos armando mas confusion porque ni siquiera HTML5 soporta PUT ni DELETE ni HEAD y cuando se implementa es por debajo mediante POST

En aplicaciones WEB no se usa mas que POST y GET porque los otros tipos de REQUESTs no son soportados mas alla de un contexto Ajax.

[pateketrueke]

Iniciado por Italico76

[...] Creo estamos armando mas confusion porque ni siquiera HTML5 soporta PUT ni DELETE ni HEAD y cuando se implementa es por debajo mediante POST [...]

Bueno, seguramente necesitas informarte más para no confundirte sólo, HTTP no es parte de HTML5, son cosas diferentes.

Ahora, dichos métodos son soportados, si no me crees crea un objeto XMLHttpRequest y establece el método a mano, verás que sí funciona.

[Italico76]

Iniciado por Italico76

no son soportados mas alla de un contexto Ajax.

>> me referia a esto

[pateketrueke]

Bueno, seguramente te referías a un formulario tradicional de HTML pues HTML5 se suele entender como un conjunto de tecnologías modernas para web: HTML5 per se, Javascript (ES5) y CSS3.

O al menos así lo interpreto yo, por ende mi respuesta.

[Italico76]

Si Sr, me referia a:

Código HTML:

<FORM action="DELETE">
 

[guardarmicorreo]

Iniciado por dashtrash

Da igual que al funcionamiento del sistema le lleguen parámetros por GET,POST o la Url de la request. Que se instancie una clase y se llame a un método no depende de que la petición http que llega a tu servidor contenga los parámetros codificados de una forma u otra.


...o por GET, si quieres.Porque son intercambiables.


Y, si eso es lo que piensas, que es la convención habitual, y tomando exactamente esa frase, para qué necesitas diferenciar GET y POST más allá del enrutador?

Lo necesito por dos motivos obvios:

1) POST y GET son variables superglobales, vale, pero

¿cómo le digo al programa que está en una clase y no en un código suelto, sin encapsular que me ejecute una clase y no otra, un método y no otro?


2) Para que los datos que el usuario ponga en el formulario no se sumen al path del navegador.

Si con .htaccess realizo esto para que me separe los datos GET en tres conjuntos:

class, method y args

Código Apache:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^([^/]*)/*([^/]*)/*(.*)$ index.php?class=$1&method=$2&args=$3
</IfModule>
 

Ahora supongamos un formulario enviado por post para que un usuario desde el home se suscriba al newsletter que tuviera esta estructura

Código HTML:

<form method="post" action="">
    <label for="newsletter">Recibe noticias sobre mi, introduce tu correo electrónico</label>
    <input type="email" name="newsletter" id="newsletter" class="newsletter">
    <input type="submit" name="submit_newsletter" id="submit_newsletter" class="submit_newsletter">
</form>
 

Si por GET el usuario va instanciando sobre clases ¿qué debería poner en el action del form para que la clase indicada se ejecute? Evidentemente con los nombres explícitos de los parámetros que debe recibir por POST pero ¿cómo ejecuto esa clase?



Paketetrueke, creía que HTML5 es simplemente la última versión de HTML. Cada día aprendo más con vosotros :D

(Lamento haber tardado en responder, pero desde ayer noche que intenté cada 2x3 entrar al foro pero se ve que hubo problemas con el/los servidor/es.)

[hhs]

Creo que te estas complicando, lo que necesitas es únicamente capturar todas las peticiones y enviarlas a tu index.php

Código Apache:

<IfModule mod_rewrite.c>
            RewriteEngine On
            RewriteCond %{REQUEST_FILENAME} !-f
            RewriteRule ^(.*)$ /index.php [QSA,L]
</IfModule>
 

Las responsabilidad de tu Front Controller son las de recibir e inspeccionar la petición y determinar que esta mapeado a la url para ejecutarlo.
La forma básica es usando el patrón request/respònse que dicho sea de paso no es nuevo ya lo conoces de una u otra forma. El detalle es que trabajas con objetos, asi que tu petición a través de una URL la tienes que transformar a un objeto que puede usar el Front Controller para tomar decisiones (Service Controller ). y a su vez pueda ser manejado por otros componentes, como pasarlo al controlador y desde el, acceder a get o post si es el caso.
Los dos patrones estan explicados en el libro Servce Design Pattern, las ligas son parte del catalogo. Date un tiempo para leer te va ahorrar problemas y te va ayudar a comprender como hacen las cosas otros frameworks y sobre todo a tener herramientas para tomar decisiones de diseño o para aplicar el principio de otra forma.

[guardarmicorreo]

Muchas gracias a todos. He aprendido en este hilo.

Pude solucionar mi problema, que era el siguiente:

Cuando aprendí sobre formularios en HTML, lo que entendí es que el form tiene dos métodos (POST y GET), y entendí que la forma de enviar el form también varía según el method.

Es decir, si en el action yo escribo

Código HTML:

<form method="post" action="index.php?input=2&type=response">
 

Entendía que lo que estaba haciendo era enviar a index.php los datos por post.

Lo que no caí en la cuenta es que el action se envía por GET. Esa era la pieza que me faltaba para entender que da igual qué datos envíe, porque la ruta para enviarlos es por GET y una vez ya mediante GET instancie la clase y acceda al método concreto, ya ahí filtro el POST y descarto o incluyo parámetros.

Un dolor de cabeza debido a mi ignorancia en ese detalle.

Gracias a todos!!!