studio - Las mejores prácticas de PHP?
subir archivos a servidor android studio (9)
¿Cuál es una buena manera de eliminar el código de las páginas de visualización cuando se desarrolla con PHP? A menudo, las páginas en las que trabajo deben ser editadas por una persona externa. Esta persona a menudo se confunde con muchos bloques de PHP y también le gusta romper mi código.
Intenté mover bloques de código a funciones, por lo que ahora hay funciones repartidas por todo el HTML ahora. A medida que algunas páginas se vuelven más complejas, se vuelve a convertir en un programa y el procesamiento de POST es cuestionable.
¿Qué puedo estar haciendo mejor en mi desarrollo de PHP?
¿Necesita la persona externa editar la lógica, o solo la pantalla (HTML)?
Si es el último caso, consulte el motor de plantillas Smarty .
Eche un vistazo a cómo algunos de los marcos de PHP populares usan plantillas. Los ejemplos incluyen CakePHP, Zend Framework y Code Igniter. Incluso si no va a basar su sitio en estos marcos, el patrón de diseño de la plantilla es una buena manera de mantener el código de PHP lejos de sus diseñadores web, para que puedan enfocarse en el diseño y no en la funcionalidad.
Hay mucho que se puede decir sobre este tema, pero un punto de partida muy básico sería mover la mayor cantidad de código posible en archivos separados y luego usar declaraciones include.
No necesita un "sistema" para hacer plantillas. Puede hacerlo por su cuenta al mantener la presentación y la lógica separadas. De esta forma, el diseñador puede estropear la pantalla, pero no la lógica detrás de ella.
Aquí hay un ejemplo simple:
<?php
$people = array(''derek'',''joel'',''jeff'');
$people[0] = ''martin''; // all your logic goes here
include ''templates/people.php'';
?>
Ahora aquí está el archivo people.php (que le das a tu diseñador):
<html>
<body>
<?php foreach($people as $name):?>
<b>Person:</b> <?=$name?> <br />
<?php endforeach;?>
</body>
</html>
Usualmente uso incluye, ya que pueden ser muy útiles para organizar y agrupar funciones juntas. Además, comenta tu código. No hay nada peor que que alguien más vea tu trabajo y no sepa por qué lo has hecho. Nombrar variables y funciones de forma sensata también puede ser muy útil, por ejemplo:
$userName = "John Doe";
$dateOfBirth = "04/02/1982";
function calculateUserAgeFromBirth($userName, $dateOfBirth)
Nombrar variables como esta también ayuda a minimizar los comentarios sobre lo que realmente hace su código.
Creo que me gustaría mantenerme alejado de un marco poco sólido. Solo un enfoque que puedo usar generalmente hace que las páginas sean más legibles con un código más limpio.
quiere que decida cuál es la mejor respuesta, cuando lo mejor es una opinión subjetiva. ¿Quién puede decir cuál es la "mejor" práctica?
Si decides continuar usando las funciones, puedes obtener algo de inspiración de WordPress. Probablemente pueda reducir el "programa" al mínimo haciendo que las plantillas sean más granulares.
Además, las buenas herramientas (es decir, los editores de HTML) pueden ayudar a los diseñadores a ignorar su PHP y trabajar en el diseño sin romper el código. (Pero no tengo sugerencias, lo siento)
La otra manera para algunas cosas es crear su propio sistema de plantilla en lugar de SMARTY, pero probablemente llevaría demasiado tiempo crear un sistema que funcione para satisfacer sus necesidades que iría más allá reemplazando algo como %% VARIABLE %% con un texto.
Nuestra compañía usa SMARTY e incluso con mucho código en plantillas, los diseñadores saben cómo trabajar con ella. Para sitios CMS simples usamos ExpressionEngine, que usa etiquetas similares a HTML para insertar lógica en plantillas.
Me parece que necesita comenzar a implementar lo que se conoce como "separación de preocupaciones" en su aplicación en general. Los ejemplos que la gente brinda sobre la creación de plantillas, en respuesta a su queja específica acerca de que los editores de la página rompan su código, son importantes, pero representan solo un ejemplo de esta táctica. A medida que su programa se hace más grande y más complejo, se vuelve más difícil de modificar y depurar, incluso si su diseñador no está rompiendo su código.
Probablemente, la separación más común es una división de tres vías entre los datos, la lógica y la presentación, tal como se describe en el patrón de diseño Model-View-Controller (MVC). No necesita un marco de MVC completo para implementar los mismos principios básicos. La idea es simplemente encapsular el código que trata con sus datos (modelo) en un solo lugar, el código que presenta estos datos al usuario (vista) en otro. Vincula ese código junto con el código que solo se ocupa de presentar los datos correctos al usuario correcto en el momento adecuado (controlador).
Según su descripción, parece que ahora tiene un patrón de secuencia de comandos de transacción , donde tiene un archivo php "dothis.php" que está cargado en el navegador, y todas las definiciones de función y HTML para la pantalla están juntas. Ya tiene funciones, por lo que ya está comenzando a encapsular elementos de lógica.
La forma en que abordaría esto sería, de acuerdo con las otras respuestas aquí sobre la creación de plantillas, es eliminar todo el HTML en otro archivo solo haciendo referencia a variables PHP simples y tal vez algunos bucles (pero con tan poca conmutación condicional como sea posible). Eso hará que la plantilla sea más fácil de leer y más difícil de romper. Cuando su editor de página quiera modificar el diseño, proporciónele ese archivo.
A continuación, separa todas sus funciones de acceso a datos en otro archivo, idealmente creando una clase (o varias clases, según la complejidad de los datos y la frecuencia con la que debe reutilizarlos).
En este punto, su "dothis.php" se ha reducido a tal vez a algún código de configuración (que puede separar a un include, y algún código de autenticación (que puede separar a su propia clase), y solo está llamando a los datos funciones de acceso y llamar al archivo de plantilla incluido. Por lo tanto, su controlador se simplifica enormemente y es más fácil de administrar.
Recomiendo leer el libro PHP en acción . Le lleva a abstraer sus conexiones de base de datos, sistemas de plantillas y todos los demás aspectos básicos de una aplicación web. Si cada desarrollador de PHP lee este libro, el idioma tendrá una reputación mucho mejor.
También tiene capítulos sobre refactorización, pruebas unitarias y el patrón de control MVC.