php - mvc - micro frameworks javascript

¿Deberían los frameworks de PHP generar JavaScript?

Question

Me di cuenta de que un framework de PHP; Zend , Cake y Symfony ; parece generar JavaScript o permitir que se incruste como una cadena en el PHP mismo. ¿Es esta una buena idea? De parte de personas que han usado estos marcos / bibliotecas, ¿cuál ha sido su experiencia trabajando con los ayudantes de Ajax y JavaScript? ¿Ha sido fácil de mantener? ¿Reduce el tiempo de desarrollo?

Answer 1

Creo que debes mantener los idiomas separados. A pesar de que se pueden complementar el uno al otro. De esta forma, puede elegir la implementación de dicho idioma y crear una combinación que le quede perfecta.

Answer 2

Esta es una pregunta bastante subjetiva, pero personalmente, no me gustaría que un marco de back-end haga esto por mí. Es mejor mantener una separación limpia entre la lógica de negocios, la presentación y los comportamientos de UI del lado del cliente por varias razones:

• Aplicaciones más mantenibles.
• Más fácil de probar componentes individuales.
• Una colaboración más sencilla. Diferentes conjuntos de habilidades pueden funcionar en diferentes áreas.
• Debería ayudar a garantizar que su aplicación no dependa de JavaScript en el entorno de los usuarios finales.

Answer 3

No, es una mala idea,

JavaScript generado generalmente significa que el sitio ni siquiera funcionará sin él (como muchos sitios asp.net). Si desea hacer cosas más complejas o desea mejorar la accesibilidad, no hay otra alternativa que separar claramente HTML de CSS y Javascript.

La separación de Javascript también hace que el código sea más fácil de mantener ya que no es necesario que los desarrolladores frontend del lado del cliente entren en problemas con su código PHP y viceversa.

La mejor manera de usar Javascript es primero dejar que php genere su html, luego, en la parte inferior de esa página, incluya sus archivos javascript y use funcionalidades como onDomReady. Esto tampoco te obliga a usar una biblioteca en particular solo porque tu framework lo usa como base para su Javascript generado.

Answer 4

Personalmente, me encanta escribir mi propio Javascript, así que realmente no quiero que se escriba para mí, pero no creo que sea particularmente "peligroso" o "dañino" tener marcos que lo hagan por usted, siempre que sea hecho correctamente Mi mayor problema con ellos es que la mayoría de ellos funcionará siempre que desee el comportamiento estándar de una función, pero tan pronto como desee algo un poco diferente para satisfacer las necesidades de su proyecto, se necesita mucho trabajo para personalizarlo. han sido mejor servidos para hacerlo usted mismo. Al menos esa fue mi experiencia con la automatización javascript de CakePHP.

Answer 5

Mi experiencia con los ayudantes de Javascript y Ajax en CakePHP ha sido muy positiva.

Han permitido a los desarrolladores del lado del servidor prototipar y construir características que de otro modo requerirían que alguien con experiencia real del lado del cliente lo haga, todo sin preocuparse por la calidad del código de JavaScript que "escriben" y dejando libres a los ingenieros de front-end reales para enfocarse en las características avanzadas del lado del cliente.

Answer 6

Personalmente, me gusta escribir mi Javascript a mano, de manera discreta, de modo que solo tengo que agregar un evento adicional al document.domReady con, por ejemplo, los parámetros correctos. Esa pequeña función de disparo hace rodar la pelota.

La mejor práctica del día:

Mantenga el código frontend y el código backend desenredado tanto como sea posible

Answer 7

No es una buena idea que PHP genere Javascript. El único javascript que recomendaría exportar es simples asignaciones JSON como las siguientes:

<script type="text/javascript"><!--
var MyNamespace.info = <?php echo json_encode($info_array) ?>
// --></script>

Esta es la forma más fácil de desinfectar la información de PHP y dejarla accesible para javascript en el cliente. Sin embargo, cualquier otra cosa debe escribirse en ARCHIVOS JAVASCRIPT reales a los que se hace referencia con etiquetas al principio del documento. La única otra apariencia de Javascript de los archivos del lado del servidor, que yo diría que está bien, es que las cosas se coloquen en "onclick" y otros atributos similares.

La razón de esto es que el Javascript debe ser escrito y mantenido por personas que conocen JavaScript, y el sitio debería poder funcionar (al menos parcialmente) sin javascript. No hay ninguna razón para generar spaghetti Javascript en línea.

Eche un vistazo a mi marco PHP, PHP On Pie ( http://phponpie.com ) para ver un ejemplo de cómo implementar esto correctamente. Mantiene el JS y PHP separados, excepto cuando se exporta JSON como se muestra arriba. Sin embargo, también proporciona convenciones para facilitar la interoperación entre el cliente y el servidor a través de AJAX.

Answer 8

Yo diría que depende, como cualquier cosa. Sin duda tiene algún valor tener widgets "inteligentes" del lado del servidor. Por ejemplo, un widget que "sabe" cómo actualizarse a través de AJAX, o un formulario que puede manejar la validación del lado del cliente y del lado del servidor. Este último es un ejemplo de lo cual sería costoso y lento y propenso a errores reescribir el código de validación aburrido en el cliente. No requiere Javascript de rocket science, por lo que siempre y cuando tu framework pueda manejarlo discretamente, en realidad aconsejaría esta ruta. Además, el código de marco que manejará las cosas de GUI también (a la ext o algo similar), tampoco es una mala idea.

Sin embargo, cualquier cosa más complicada que eso, usa el Javascript mismo.

Answer 9

Creo que definitivamente hay un lugar para javascript generado. (1)

La razón número uno para javascript generado es la facilidad de mantenimiento. Cualquier dependencia está codificada y configurada explícitamente desde el marco (PHP, ruby, scala, python). Por ejemplo, si mueve sus activos o cambia el directorio de carga, simplemente actualice la configuración y vea cosas que solo funcionan.

¿Necesita la validación de entrada del lado del cliente para quitar algo de carga de su servidor? (2) Permita que el marco genere un código de validación correcto derivado directamente de su modelo de datos. Con la población generada, javascripted, su marco puede servir formularios HTML preprocesados ​​y estáticos del caché. Esto podría ser una gran victoria si sus formularios contienen muchas selecciones y opciones.

1) Suponiendo que el cliente haya decidido que está bien que el sitio dependa (más o menos) de javascript, con todas las advertencias que esto conlleva. La degradación agraciada puede o no ser posible o deseable.

2) También necesita la validación del lado del servidor, pero lo sabía, ¿verdad?