Cada ejemplo que he visto de CGI/Perl, básicamente, un montón de declaraciones impresas que contienen HTML, y esta no parece ser la mejor manera de escribir una aplicación CGI. ¿Hay una mejor manera de hacer esto? Gracias.¿Cuál es la mejor manera de escribir una aplicación Perl CGI?
EDIT: he decidido utilizar CGI :: Application y HTML :: Template, y uso el siguiente tutorial: http://docs.google.com/View?docid=dd363fg9_77gb4hdh7b. ¡Gracias!
Absolutamente (probablemente esté buscando tutoriales de los años 90). Querrá elegir un marco. En Perl-tierra son las opciones más populares:
Esta es realmente una gran pregunta. En resumen, la mejor forma se llama Model/View/Controller (también conocida como MVC). Con MVC, su aplicación se divide en tres partes.
El modelo es su lógica de datos y de negocios. Son las cosas que conforman el núcleo de tu aplicación.
La vista es el código para presentar cosas al usuario. En una aplicación web, esto normalmente será algún tipo de sistema de plantillas, pero también podría ser una hoja de cálculo en PDF u Excel. Básicamente, es la salida.
Finalmente, tiene el Controlador. Esto es responsable de poner juntos el Modelo y la Vista. Toma la solicitud de un usuario, obtiene los objetos modelo relevantes y llama a la vista apropiada.
mpeters ya mencionados varios frameworks MVC para Perl. También querrás elegir un motor de plantillas. Los dos más populares son Template Toolkit y Mason.
El Perl5 Wiki proporciona una buena lista (aunque no completa) de web frameworks & templates.
Merece la pena leer los artículos de comparación vinculados en la entrada de la wiki "templates". También recomendaría leer este artículo push style templating systems en PerlMonks.
Para plantillas, entonces Template Toolkit es el que he usado más y lo recomiendo encarecidamente. También hay un O'Reilly book y es probablemente el sistema de plantillas más utilizado en el reino de Perl (dentro o fuera de los marcos web).
Otro enfoque que me ha atraído cada vez más es el de las soluciones de "generador" sin plantilla. Los módulos como Template::Declare & HTML::AsSubs se ajustan a esta ley.
También puede separar la presentación del código y simplemente utilizar un sistema de plantillas sin necesidad de incorporar todos los gastos generales de un marco completo. Template Toolkit se puede usar solo de esta manera, como puede Mason, aunque tiendo a considerarlo como un marco más disfrazado como un sistema de plantillas.
Sin embargo, si realmente quieres separar el código de la presentación, ten en cuenta que TT y Mason permiten (o incluso fomentan, dependiendo de qué documentos lees) el código ejecutable que se incorporará en las plantillas. Personalmente, creo que el código de incrustación en su HTML no es mejor que incrustar HTML en su código, por lo que tiendo a optar por HTML::Template.
Por el momento, dejando la cuestión del marco CGI vs MVC, lo que va a querer es uno de los módulos de plantillas de salida del CPAN.
El Template Toolkit es muy popular (Template.pm en CPAN) También son populares Text :: Template, HTML :: Template y HTML :: Mason.
HTML :: Mason es mucho más que un módulo de plantilla, y como tal podría ser demasiado pesado para una simple aplicación CGI, pero vale la pena investigarlo un poco para decidir cuál sería el mejor para usted.
Texto :: La plantilla es razonablemente simple y usa Perl dentro de las plantillas, por lo que puede recorrer los datos y realizar la lógica de visualización en Perl. Esto es visto como un pro y un engaño por las personas.
HTML :: La plantilla también es pequeña y simple. Implementa su propio pequeño conjunto de etiquetas para procesamiento if/then/else, configuración de variables y bucles. Eso es. Esto se ve como pro y como contra por las razones exactamente opuestas a Text :: Template.
Template toolkit (TT) implementa un lenguaje de plantillas muy grande y perlish que incluye bucles y lógica, y mucho más.
Usé HTML :: Plantilla uno, y encontré que quería algunas características más. Luego utilicé Text :: Template con éxito, pero encontré su deseo de juguetear con los espacios de nombres para ser un poco molesto. Conozco y amo a Template Toolkit. Para mí, se siente bien. Su millaje puede variar.
Por supuesto, todavía existe el antiguo método de "impresión HTML", a veces basta con un par de instrucciones de impresión. Pero has llegado a la idea de separar tu pantalla de tu lógica principal. Lo que es algo bueno.
Es el primer paso en el camino hacia Modelo/Vista/Controlador (MVC) en el que mantiene separada su lógica de negocio del modelo de datos & (su código acepta la entrada, hace algo con ella y decide qué debe ser salida), su entrada/salida (Plantillas o instrucciones de impresión - HTML, PDF, etc.) y el código que conecta las dos (CGI, CGI :: Aplicación, Catalyst MVC Framework, etc.). La idea es que un cambio en su estructura de datos (en el Modelo) no debería requerir cambios en sus rutinas de salida (Vista).
CGI vs MVC no tiene sentido. CGI (Common Gateway Interface) es una interfaz independiente de la plataforma para ejecutar programas externos, software o puertas de enlace en un servidor web/de información. MVC (Model-View-Controller) es un patrón de diseño que divide una aplicación en tres áreas de responsabilidad. Si está utilizando Perl para crear una aplicación web, va a utilizar CGI de una forma u otra. El uso del patrón de diseño de MVC es opcional y recomendado, pero en última instancia no está relacionado con el uso de CGI. –
No tiene sentido si eres pedante sobre terminología e insistes en los significados denotativos de CGI y MVC, mientras ignoras sus significados connotativos. Si bien es perfectamente razonable construir una aplicación CGI utilizando el patrón MVC, es el caso de que los programadores evolucionen desde CGI.pm, CGI :: Application, etc., creando su propia estructura MVC a medida que avanzan y refactorizan su código, a los frameworks MVC. como Catalyst, en ese punto también tienden a evolucionar hacia FCGI o mod_perl. Entonces pragmatismo, no tonterías. –
Las palabras significan cosas. También lo hacen los acrónimos. Cuando dejamos de estar de acuerdo con eso, volvemos a gruñir el uno al otro en los árboles. http://en.wikipedia.org/wiki/Common_Gateway_Interface –
Una solución que me siento un equilibrio adecuado en el Marco/Roll-su-propio dilema es el uso de tres módulos de perl clave: CGI.pm, Template Toolkit, y DBI. Con estos tres módulos, puede realizar una programación MVC elegante que sea fácil de escribir y mantener.
Los tres módulos son muy flexibles con Template Toolkit (TT), lo que le permite generar datos en html, XML o incluso en pdf, si es necesario. También puede incluir la lógica perl en TT, incluso agregar allí su interfaz de base de datos. Esto hace que tus scripts CGI sean muy pequeños y fáciles de mantener, especialmente cuando usas el pragma "estándar".
También le permite poner cosas de JavaScript y AJAXy en la plantilla misma que imita la separación entre el cliente y el servidor.
Estos tres módulos se encuentran entre los más populares en CPAN, tienen una excelente documentación y una amplia base de usuarios. Además de desarrollar con estos medios, puede pasar rápidamente a mod_perl una vez que haya creado un prototipo de su código que le brinda una transición rápida al entorno de perl integrado de Apache.
En conjunto, un conjunto de herramientas compacto pero flexible.
Esta es de lejos la mejor respuesta a la pregunta. –
Actualizaría mi respuesta para instar a consideración de Xslate, una solución de plantillas rápida. Tiene una opción de sintaxis TT para facilitar la migración desde TT, y está en las primeras etapas de la migración a Golang. – jeremiah
Gracias! Los probaré y aceptaré tu respuesta cuando tenga tiempo de probarlos (debería ser la próxima semana, me voy de vacaciones :-)) – ristonj
Me pregunto si Jifty sigue siendo una buena opción. ¿Se mantiene? Observo que se está eliminando de Debian por no ser ampliamente utilizado. La última actualización de Jifty para el CPAN fue en 2011. – jeremiah
Sí, Jifty probablemente debería ser eliminado de esa lista. Pero otros definitivamente se han levantado para tomar su lugar. Ahora agregaría Dancer y Mojolicious a esa lista. – mpeters