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

Question

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?

Answer 1

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 en funcionamiento.

Answer 2

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.

Answer 3

En este tipo de situación, reescribiendo desde cero básicamente, el código anterior es útil para A) prueba, 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. Puede ahorrarse MUCHO tiempo y dinero.

Answer 4

Aquí es cómo lo hice usando Python en lugar de Perl, pero eso no debería importar:

1. separa HTML y código en archivos distintos. Usé un motor de plantilla para eso.
2. Creado funciones a partir del códigoque dictó una plantillacon un conjunto de parámetros.
3. Organizamos las funciones (que denominé vistas, inspiradas en Django) de una manera sensata. (Vistas de administrador, vistas de usuario, etc.) Todas las vistas siguen la misma convención de llamadas!
4. refactorizado la base de datos y solicitud de material de manera que los puntos de vista se sólo contienen código específico vista (léase: Manipulación del GET, POST peticiones, etc., pero nada de bajo nivel). Depende en gran medida de las bibliotecas existentes para eso.

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

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

Answer 5

Una de las suposiciones que hacen los marcos es que las direcciones URL se asignan al código. Por ejemplo, en un marco general se ven los siguientes:

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

Por lo general, aunque los viejos scripts CGI no funcionan de esa manera, es más probable que tenga algo 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.

También los marcos brindan soporte para algún tipo de ORM (asignador relacional de objetos) que abstraiga las llamadas de la base de datos y le permita 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.