lite perl model-view-controller cgi catalyst

perl - lite - ¿Cuál es el mejor enfoque para migrar un CGI a un Framework?



install mojolicious:: lite (5)

Así es como lo hice usando Python en lugar de Perl, pero eso no debería importar:

  1. Separado HTML y código en archivos distintos. Usé un motor de plantillas para eso.
  2. Funciones creadas a partir del código que representa una plantilla con un conjunto de parámetros.
  3. Organicé las funciones (que denominé vistas , inspiradas por Django) de una manera sensata. (Vistas de administrador, vistas de usuario, etc.) Todas las vistas siguen la misma convención de llamadas .
  4. Refactorizó la base de datos y solicitó material para que las vistas solo contuvieran código específico de la vista (léase: Manejo de solicitudes GET, POST, etc. ¡pero nada de bajo nivel!). Depende en gran medida de las bibliotecas existentes para eso.

Estoy aquí en este momento. :-) El siguiente paso obvio es, por supuesto:

  • Escribe un despachador que mapea las URL de tus vistas . Esto también conducirá a mejores URLs y mejor manejo de errores y 404, por supuesto.

Tengo una gran aplicación web ejecutándose en CGI perl. Se está ejecutando bien, está bien escrito, pero como se hizo en el pasado, todos los html se definen como codificados en las llamadas CGI, así que como se puede imaginar, es difícil mantenerlos, mejorarlos, etc. Así que ahora me gustaría comenzar para agregar algunas plantillas e integrarlas con un marco (catalizador o aplicación CGI ::). Mi pregunta es: ¿alguien aquí tiene una experiencia como esa? Hay algunas cosas por las que debo prestar atención? Soy consciente de que con ambos frameworks puedo ejecutar scripts nativos CGI, por lo que es bueno porque puedo ejecutar ambos (código "CGI" generado por el anuncio nativo CGI) sin ningún trauma. ¿Algun consejo?


En este tipo de situación, la reescritura desde cero básicamente, el código anterior es útil para A) probar, y B) detalles de diseño. Sería ideal realizar un conjunto de pruebas, para todas las funcionalidades básicas que desea replicar, o al menos pruebas que analizan las páginas finales de resultados para que pueda ver que el nuevo código devuelve la misma información para las mismas entradas.

Los detalles de diseño dentro del código pueden ser inútiles, dependiendo de cuánto maneja el marco automáticamente. Si tiene un buen conjunto de pruebas y una conversión sencilla funciona bien, ya está. Si el comportamiento del nuevo no coincide con el anterior, probablemente necesite profundizar en el "¿por qué?" y eso probablemente sea algo extraño, eso no tiene sentido a primera vista.

Una cosa que debe recordar hacer primero es averiguar si alguien ha hecho algo similar en el marco que está utilizando. Podrías ahorrarte MUCHA cantidad de tiempo y dinero.


Extienda el HTML de la lógica de procesamiento en el script CGI. Identifique todo el código que afecta el resultado HTML, ya que estos son candidatos para convertirse en variables de plantilla. Separa eso en un archivo HTML, con las partes identificadas marcadas con variables de plantilla. Eventualmente, podrá refactorizar la página de manera que todo el procesamiento se realice al comienzo del código y la plantilla HTML que acaba de invocarse al final de todo el procesamiento.


Una de las suposiciones que hacen los marcos es que las direcciones URL se asignan al código. Por ejemplo, en un marco, a menudo verá lo siguiente:

http://app.com/docs/list http://app.com/docs/view/123

Por lo general, aunque los viejos scripts CGI no funcionan así, es más probable que tengas algo así como:

http://app.com/docs.cgi?action=view&id=123

Para aprovechar el marco, es posible que deba cambiar todas las URL. Si puede hacer esto y cómo mantiene trabajando los enlaces antiguos, puede ser una gran parte de su decisión.

Además, los marcos proporcionan soporte para algún tipo de ORM (asignador relacional de objetos) que abstrae las llamadas a la base de datos y le permite tratar únicamente con los objetos. Para Catalyst esto suele ser DBIx::Class . Debe evaluar cuál será el costo de cambiar a esto.

Probablemente encontrará que desea hacer una reescritura completa, con el código anterior como plataforma de referencia. Esto puede ser mucho menos trabajo de lo esperado. Sin embargo, comience con algunos sitios de juguetes para familiarizarse con el marco / marco / plantilla con el que decida ir.


Escribir pruebas primero (por ejemplo, con Test::WWW::Mechanize ). Luego, cuando cambias las cosas, siempre sabes si algo se rompe y qué es lo que se rompe.

A continuación, extraiga HTML en plantillas y utilice subs de forma habitual en módulos. Después de eso, es un pedazo de pastel cambiar a un marco.

En general, vaya paso a paso para que siempre tenga una aplicación que funcione.