2008-08-30 25 views
11

¿Cuál es una buena manera de eliminar el código de las páginas de visualización al desarrollar 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.¿Mejores prácticas de PHP?

He intentado mover bloques de código en 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 hacer mejor en mi desarrollo de PHP?

Respuesta

19

No necesita un "sistema" para realizar plantillas. Puede hacerlo por su cuenta manteniendo la lógica de presentación & por separado. De esta forma el diseñador puede estropear la pantalla, pero no la lógica detrás de ella.

Aquí está un ejemplo sencillo:

<?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 da a su diseñador):

<html> 
<body> 
<?php foreach($people as $name):?> 
    <b>Person:</b> <?=$name?> <br /> 
<?php endforeach;?> 
</body> 
</html> 
+0

El diseñador todavía puede estropear cualquier cosa, a menos que tenga algunas medidas en su lugar. Si bien no me gusta especialmente Smarty, su capacidad para restringir el uso del PHP función por función o en conjunto es un buen ejemplo. Pero es verdad que al menos el trabajo del diseñador será más fácil si se separa el diseño. –

0

Hay mucho que se puede decir sobre este tema, pero un punto de partida muy básico sería mover todo el código posible en archivos separados y luego usar declaraciones include.

5

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.

0

Normalmente 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. Denominar las variables y funciones con sensatez puede recorrer un largo camino también - por ejemplo:

$userName = "John Doe"; 
$dateOfBirth = "04/02/1982"; 

function calculateUserAgeFromBirth($userName, $dateOfBirth) 

variables de asignación de nombres de este tipo también ayuda a minimizar los comentarios acerca de lo que su código hace realidad.

2

¿Necesita la persona externa editar la lógica, o solo la pantalla (HTML)?

Si es el último caso, consulte el motor de plantillas Smarty.

1

Creo que me gustaría permanecer lejos de un unweildy marco de referencia. Solo un enfoque que puedo usar generalmente hace que las páginas sean más legibles con un código más limpio.

Stack Overflow quiere que decidamos qué respuesta es la mejor opción, cuando lo mejor es una opinión subjetiva. ¿Quién puede decir cuál es la "mejor" práctica?

1

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 forma de crear cosas es crear un sistema de plantilla propio en lugar de SMARTY, pero probablemente llevaría demasiado tiempo crear un sistema que satisfaga sus necesidades, que pasaría simplemente reemplazando algo como %% VARIABLE% % con un texto.

Nuestra empresa utiliza SMARTY e incluso con un montón de 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.

4

Me parece que necesita comenzar a implementar lo que se conoce como "separación de preocupaciones" entre 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 datos, lógica y presentación como se describe en el patrón de diseño Model-View-Controller (MVC). No necesita un marco completo de MVC 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).

De su descripción, parece que tiene ahora un patrón Transaction Script, 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 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 poder). 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.

Luego, separa todas sus funciones de acceso a datos en otro archivo, idealmente creando una clase (o varias clases, dependiendo de cuán complejos sean sus datos y con qué frecuencia debe reutilizarlos).

En este punto, su "dothis.php" se ha reducido a tal vez algún código de configuración (que puede separar a una inclusión, y algún código de autenticación (que puede separar a su propia clase), y solo llamar a las funciones de acceso a datos y llamar al archivo de plantilla incluido. Su controlador en sí mismo se simplifica enormemente y es más fácil de administrar.

2

Le recomendaría mucho leer el libro PHP In Action. 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 leyera este libro, el idioma tendría una reputación mucho mejor.

También tiene capítulos sobre refactorización, pruebas unitarias y el patrón de control MVC.