Pregunta

Una cosa que realmente ha estado dificultando la vida para ponerse al día en la base de código de un proyecto clásico de ASP es que la situación del archivo de inclusión es un desastre. A veces encuentro la función que estaba buscando para ser incluida en un archivo de inclusión que no tiene ninguna relación. ¿Alguien tiene algún consejo sobre cómo refactorizar esto de tal manera que uno pueda decir más fácilmente dónde está una función si necesita encontrarla?

EDITAR: una cosa que olvidé preguntar: ¿tiene vbscript algún tipo de mecanismo para evitar que un archivo se incluya dos veces? Sorta como # ifndef's de C?

¿Fue útil?

Solución

Hay algunas cosas básicas que puedes hacer cuando te adueñes de una aplicación ASP clásica, pero probablemente terminarás arrepentiéndote de haberlas hecho.

  1. Eliminar archivos de inclusión duplicados . Todas las aplicaciones ASP clásicas que he visto alguna vez han tenido 5 " login.asp " páginas y 7 " datepicker.js " archivos y así sucesivamente. Busque y elimine todos los duplicados, y luego cambie las referencias en el resto de la aplicación según sea necesario. Tenga cuidado de hacer una verificación de diferencias en cada archivo cuando lo elimine, a menudo los archivos duplicados tienen pequeñas diferencias porque el autor original lo copió y luego solo cambió la copia. Esto es una gran cosa para la evolución, pero no tanto para el código.
  2. Crea una estructura de carpetas racional y mueve todos los archivos a ella. Este es obvio, pero es el que más lamentarás hacer. Ya sea que los enlaces en la aplicación sean relativos o absolutos, tendrá que cambiar la mayoría de ellos.
  3. Combine todos sus archivos de inclusión en un archivo grande . Luego, puede reordenar todas las funciones de forma lógica y dividirlas en archivos separados con nombres sensibles. Luego, tendrá que pasar por la página de la aplicación por página y averiguar cuáles deben ser las declaraciones de inclusión en cada página (o seguir con el archivo, e incluirlo en cada página; no puedo recordar si Esa es una buena idea en ASP). No puedo comprender el nivel de dolor involucrado aquí, y eso es suponiendo que los archivos de inclusión existentes no hacen un uso intensivo de los globales con el mismo nombre.

No haría nada de esto. Parafraseando a Steve Yegge (creo), " no hay nada de malo en una aplicación ASP clásica que no se pueda arreglar con una reescritura total " ;. Soy muy serio con esto, no creo que haya una pérdida de tiempo mayor para los programadores en este mundo que mantener una aplicación ASP, y el problema empeora a medida que ASP se vuelve más y más obsoleto.

Otros consejos

@ MusiGenisis lista de puntos es un buen consejo a seguir pero no estoy de acuerdo con -

"no haría nada de esto. Parafraseando a Steve Yegge (creo), "no hay nada de malo en una aplicación ASP clásica que no se pueda arreglar con una reescritura total". Estoy muy serio con esto, no creo que haya una pérdida de tiempo mayor para un programador en este mundo que mantener una aplicación ASP, y el problema empeora a medida que ASP se desactualiza más y más. & Quot;

Todo muy bien, pero si se trata de una aplicación legada de tamaño considerable, no es posible realizar reescrituras completas debido a la falta de tiempo / recursos del desarrollador.

Tenemos una aplicación ASP clásica bastante grande que ha crecido brazos y piernas a lo largo de los años, no es bonita pero satisface las necesidades del negocio. No tenemos tiempo para pasar los próximos seis meses haciendo una reescritura completa, sería bueno, pero no es posible. Nuestro enfoque es -

  1. Donde se requiere una nueva funcionalidad, se implementa en ASP.NET. Esto sucede el 95% del tiempo. El 5% de los casos de borde generalmente es que hay una gran cantidad de puntos en los que el nuevo código de la aplicación toca la aplicación anterior, lo que nos obliga a hacer una gran cantidad de trabajos de ASP clásicos que potencialmente hacen que la aplicación sea más frágil.

  2. Cuando hay un cambio en la funcionalidad, evaluamos si podemos refactorizar a ASP.NET con un impacto mínimo. Si esto no es posible, implementaremos el cambio en ASP clásico y ordenaremos el código existente a medida que avanzamos, por ejemplo. simplificando incluir el anidamiento de archivos, reemplazando javascript con un código más compatible con varios navegadores, ese tipo de cosa.

En respuesta a tu pregunta sobre # ifndef's, no tengo un equivalente, me temo.

  1. Use un archivo para encabezados globales e incluye (llamémoslo t-head.asp). Este archivo está incluido en todos los archivos asp.
  2. Use un archivo para hacer que el encabezado global visual del sitio (logotipos, menús, etc.) e incluirlo justo detrás. Vamos a llamarlo t-begin.asp
  3. Use un archivo para hacer que el sitio tenga un pie de página global (derechos de autor, Google Analytics, etc.) y cierre todos los divs o tablas abiertas en t-begin.asp. Permite llamar a este archivo t-end.asp
  4. Use una carpeta para colocar los archivos de lógica de negocios, llamado BUS. Los archivos en esta carpeta no pueden tener incluye. Cada función dentro del archivo debe ir precedida por el nombre de la unidad lógica (IE: toda función en products.asp debe comenzar con product_ *)
  5. Use una carpeta para poner un código de UI reutilizado llamado UI. Los archivos en esta carpeta no pueden tener incluye.

Ejemplo:

<%@  Language=VBScript %>
<% Option Explicit %>
<% Response.Buffer = true%>
<html>
<head>
<!--#include file="../general/t-head.asp"-->
<!--#include file="../bus/product.asp"-->
<title>Products page</title>
</head>
<body>
<!--#include file="../general/t-begin.asp"-->

   <% 'all your code  %>

<!--#include file="../general/t-end.asp"--> 
</body>
</html>

Wow. Me sorprende constantemente la cantidad de personas que odian a ASP. En buenas manos es un lenguaje perfectamente capaz para diseñar aplicaciones web.

Sin embargo, admitiré que la forma en que se administran los archivos de inclusión en ASP puede ser un poco de dolor de cabeza, ya que (dependiendo de cómo se usen) deben cargarse y analizarse incluso si no se está utilizando la mitad las funciones contenidas dentro.

Tiendo a tener un archivo de inclusión ( initialise.asp o algo similar) que incluye enlaces a varias bibliotecas de funciones ( lib_http.asp , lib_mssql. asp o similar) y todas las funciones de la biblioteca son autónomas, por lo que no hay que preocuparse por el cruce de variables. Cualquier vars global se declara y establece en el archivo maestro. Esto significa que puedo usar una función en cualquier lugar, en cualquier momento y sin preocuparme por dónde se definió, solo está ahí para su uso. Y los IDE como Visual Studio y Primalscript tienen la capacidad de " saltar a definición " cuando encuentra una llamada a una función que no reconoce.

Luego, cualquier inclusión específica de secuencia de comandos se incluye en la secuencia de comandos después de la llamada a este archivo de inclusión maestro.

Admito que este es un enfoque que consume mucha memoria, ya que todas las funciones de todas las bibliotecas se compilan para cada llamada de script, por lo que el método debe refinarse para cada sitio que desarrolle: decida qué llamar a través del maestro incluido y qué es más específico de la página. Sería bueno poder cargar solo lo que necesita, pero ese es el enfoque de DLL y no está disponible para la mayoría de los desarrollos del mundo real, y también tendría que sopesar el costo del procesador de compilación de scripts pequeños vs cargando componentes.

Una estructura de directorios concisa es un requisito y es fácil de desarrollar, pero puede ser una tarea para leer todo el código en un sitio existente y cambiar cualquier enlace o llamada de mappath. Además, tenga en cuenta que algunos administradores de IIS no permiten el método '.. \' para atravesar directorios a través de VBScript, por lo que todas las referencias de archivos deben ser rutas absolutas.

Creo que debería considerar mover su código de ASP VBScript a Visual Basic DLL COM. eso te facilitará si tienes demasiado incluye.

No conozco una forma de evitar una inclusión doble, aparte de recibir un mensaje de error. ¿Está viendo las publicaciones colocadas en toda la página, lo que dificulta su localización?

Por un lado, ¿está trabajando con una copia del código y la base de datos en un servidor de desarrollo? Desde mi experiencia, lo primero que debe hacer es separarse del sitio en vivo lo antes posible. Si bien inicialmente es una molestia, le dará la libertad de hacer cambios sin arruinar el sitio en vivo. ¡Es fácil hacer ese pequeño cambio en un include y BAM! todo el sitio se cae.

He trabajado en algunos proyectos, como has descrito y utilizado las siguientes estrategias:

Reescritura completa: perfecto cuando hay tiempo / dinero, pero generalmente recibo la llamada cuando algo sale mal y se necesitan resultados tan pronto como sea posible.

Proyectos más pequeños: abro todo en el IDE y simplemente comienzo a buscar todos los archivos de proyecto para las funciones / sub, con el fin de desarrollar un conocimiento de la lógica de inclusión. Casi cada vez, todo está extendido en todas partes, por lo que empiezo a reconstruir los elementos organizados por lógica empresarial. También me he encontrado con el código en línea (código sin procesar, no subs o funciones) incluido en una inclusión, por lo que normalmente solo devolveré el código a la página para refactorizarlo más tarde.

Proyectos más grandes: usaré un código que tengo para analizar las líneas de inclusión con encabezados de sub / function y los volcaré en un archivo de texto para crear una lista de las rutinas donde se encuentran y referirse a eso. Esto es útil cuando tienes un montón de artículos incluidos en cada página y no puedes entender el código base.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top