Práctica recomendada: secuencias de comandos autorreferenciales en un sitio web

Question

Siguiendo el consejo de un desarrollador más experimentado, siempre he codificado mis páginas web que requieren la entrada del usuario (procesamiento de formularios, administración de bases de datos, etc.) como páginas autorreferenciales. Para las páginas PHP, configuro la acción del formulario en el elemento 'PHP_SELF' de la variable predefinida $ _SERVER , y dependiendo de los argumentos que paso, la lógica de la página determina qué bloque (s) de código ejecutar (s).

Me gusta que todo el código esté contenido en un archivo y no se extienda a varias páginas de resultados. El único problema que he encontrado es que mis programas de análisis de estadísticas no pueden diferenciar entre la primera vista de la página y las vistas posteriores (por ejemplo, cuando se ha enviado el formulario). Hace mucho tiempo, cuando usaba CGI o CF para crear las páginas, dirigía al usuario a una página de resultados diferente, que mostraba muy claramente cuántas veces se usaba realmente el formulario.

¿Cuál es la mejor práctica para este tipo de páginas en el desarrollo web? ¿Hay otras razones más convincentes para usar (o no usar) páginas autorreferenciales?

Answer 1

Yo diría que las páginas autorreferenciales, como usted dice, no siguen una separación apropiada de preocupaciones. Estás haciendo 2 cosas diferentes con la misma página, donde una separación más clara de la lógica te haría hacerlas en 2 páginas diferentes.

MVC (model-view-controller, http: // es hace referencia a esta práctica. .wikipedia.org / wiki / Model-view-controller ), como Ruby on Rails, Django y ASP.NET MVC (no conozco ninguno de PHP fuera de mi cabeza, aunque yo Estoy seguro de que hay algunos).

Esta también es una característica esencial de las prácticas RESTful (REpresentational State Transfer), donde cada URL representa un recurso y una sola acción que se realizará con ese recurso. Una página autorreferencial, por otro lado, tendría '' 2 '' acciones por URL / página, como "nuevo" (para completar el formulario) y " crear " (para crear realmente el objeto).

Practicando MVC y RESTful ( http://en.wikipedia.org/wiki/RESTful ) las prácticas para sitios web a menudo dan como resultado un código más limpio y una mejor separación de preocupaciones. La razón por la que esto es importante es que facilita las pruebas (y por prueba me refiero a las pruebas unitarias y funcionales, no a "probar la página en mi navegador").

El desorden de sus estadísticas es un ejemplo de cómo no separar sus preocupaciones puede conducir a una complejidad no deseada. Algunas personas podrían abordar este problema intentando detectar el referente de la solicitud y ver si era la misma página o no. Todos estos son realmente solo vendajes de código que abordan el síntoma, en lugar de solucionar el problema. Si mantiene diferentes '' acciones '' en diferentes páginas de su sitio web, puede enfocar esas páginas en su 1 trabajo y asegurarse de que lo hagan bien, en lugar de saturar el código con todo tipo de condicionales y complejidades adicionales que se evitan por completo si 1 página solo tiene 1 trabajo.

Answer 2

El argumento más fuerte detrás del enfoque de un solo archivo para el manejo de formularios es que es simplemente más fácil de mantener.

Permítanme jugar al abogado del diablo: si su enfoque original de dos archivos funciona y es medible, ¿por qué cambiarlo, particularmente si cambiarlo lo obliga a encontrar soluciones para medir el envío del formulario?

Por otro lado, si se trata de algo más complejo de lo que estoy imaginando como un simple envío de formulario de contacto (por ejemplo), entonces podría corresponderle a aprenda a registrar sus acciones en lugar de depender de un paquete de estadísticas web.

Answer 3

En el caso en que le pido a alguien que complete un formulario (generado por la secuencia de comandos en un archivo), me gusta publicar de nuevo en la misma secuencia de comandos para que pueda colocar las verificaciones de error en la parte superior, y luego volver a -generar el formulario si se encuentran errores. Esto me permite escribir la generación del formulario una vez y volver a usarla hasta que la entrada sea aceptable (es decir, " Corrija los campos que se muestran en rojo " ;, etc.).

Una vez que la entrada pasa todas las comprobaciones de cordura, puede emitir la página de resultados desde el mismo script o cancelar a otro script, dependiendo de cuál sea el más limpio para su situación. Pero personalmente no veo ningún problema con los guiones autorreferenciales que usted describe.

Dicho esto, siempre llamo al código genérico y a las bibliotecas para que realicen la generación de formularios y la verificación de errores, por lo que incluso esto "compartió". el código de generación de formularios termina siendo bastante compacto y simple.

Answer 4

Una opción potencial sería configurar alias mod_rewrite que apunten a la misma URL. Por ejemplo:

RewriteEngine on
RewriteRule ^form$ form.php [QSA]
RewriteRule ^form/submit$ form.php [QSA]

Esto le permitiría rastrear solicitudes mientras mantiene el código en el mismo archivo.

Answer 5

Puede usar páginas separadas y solo hacer que la página de resultados incluya la página del formulario.