Question

Une chose qui a vraiment rendu difficile la mise au point de la base de code d’un projet classique ASP est que la situation du fichier d’inclusion est en quelque sorte un gâchis. Je trouve parfois que la fonction que je cherchais était incluse dans un fichier d’inclusion totalement indépendant. Quelqu'un a-t-il des conseils sur la manière de procéder à une refactorisation de telle sorte que l'on puisse plus facilement savoir où se trouve une fonction s'ils ont besoin de la trouver?

EDIT: J'ai oublié de demander: vbscript dispose-t-il d'un mécanisme permettant d'empêcher l'inclusion d'un fichier deux fois? Un peu comme # ifndef de C?

Était-ce utile?

La solution

Vous pouvez effectuer quelques opérations de base lorsque vous reprenez une application ASP classique, mais vous finirez probablement par le regretter.

  1. Éliminer les fichiers à inclure en double . Chaque application ASP classique que j'ai jamais vue a déjà eu 5 " login.asp " pages et 7 "datepicker.js" fichiers et ainsi de suite. Traquez et supprimez tous les doublons, puis modifiez les références dans le reste de l'application si nécessaire. Veillez à effectuer une vérification diff sur chaque fichier lorsque vous le supprimez - les fichiers dupliqués présentent souvent de légères différences, car l'auteur d'origine l'a copié puis modifié uniquement la copie. C’est une bonne chose pour Evolution, mais pas tant pour le code.
  2. Créez une structure de dossiers rationnelle et déplacez-y tous les fichiers. Celui-ci est évident, mais c'est celui que vous regretterez le plus. Que les liens dans l’application soient relatifs ou absolus, vous devrez en changer la plupart.
  3. Associez tous vos fichiers inclus dans un seul et même fichier volumineux . Vous pouvez ensuite réorganiser toutes les fonctions de manière logique et les diviser en fichiers distincts, nommés de manière judicieuse. Vous devrez ensuite parcourir l'application page par page et déterminer ce que les instructions include de chaque page doivent être (ou coller avec le fichier unique et l'inclure simplement sur chaque page. Je ne me souviens plus si oui ou non. c'est une bonne idée en ASP). Je ne peux pas comprendre le niveau de douleur impliqué ici, et cela en supposant que les fichiers d'inclusion existants n'utilisent pas beaucoup de globals portant le même nom.

Je ne ferais rien de tout ça. Pour paraphraser Steve Yegge (je pense), "il n’ya rien de mal avec une application ASP classique qui ne puisse pas être corrigé avec une réécriture totale ". Je suis très sérieux à ce sujet. Je ne pense pas qu'il y ait une perte de temps d'un programmeur dans ce monde plutôt que de maintenir une application ASP, et le problème ne fait que s'aggraver à mesure que l'ASP devient de plus en plus obsolète.

Autres conseils

@ MusiGenisis est un bon conseil à suivre, mais je ne suis pas d'accord. avec -

"Je ne ferais rien de tout cela. Pour paraphraser Steve Yegge (je pense), "il n’ya rien de mal avec une application ASP classique qui ne peut pas être corrigé avec une réécriture totale". Je suis très sérieux à ce sujet. Je ne pense pas qu'il y ait une perte de temps d'un programmeur dans ce monde plutôt que de maintenir une application ASP, et le problème ne fait que s'aggraver à mesure que l'ASP devient de plus en plus obsolète. "

Très bien, mais s’il s’agit d’une application héritée de taille considérable, il est souvent impossible de procéder à une réécriture complète du fait du manque de temps / ressources des développeurs.

Nous disposons d'une application ASP classique assez volumineuse qui a pris de l'ampleur au fil des ans. Ce n'est pas beau, mais cela répond aux besoins de l'entreprise. Nous n'avons pas le temps de passer les six prochains mois à faire une réécriture complète, ce serait bien, mais tout simplement impossible. Notre approche est -

  1. Là où de nouvelles fonctionnalités sont requises, elles sont implémentées dans ASP.NET. Cela se produit 95% du temps. Les 5% de cas particuliers sont généralement dus au fait qu’il existe un grand nombre de points où le nouveau code de l’application touche l’ancienne application, ce qui nous oblige à effectuer beaucoup de remaniements classiques d’ASP, ce qui pourrait rendre l’application plus fragile.

  2. En cas de changement de fonctionnalité, nous déterminons si nous pouvons refactoriser ASP.NET avec un impact minimal. Si cela n’est pas possible, nous allons mettre en œuvre le changement dans l’ASP classique et ranger le code existant au fur et à mesure, par exemple. simplifier l’imbrication des fichiers à inclure, remplacer le javascript par un code plus convivial pour tous les navigateurs, ce genre de chose.

En réponse à votre question sur # ifndef, il n’ya pas d’équivalent, je le crains.

  1. Utilisez un fichier pour les en-têtes globaux et inclut (appelons-le t-head.asp). Ce fichier est inclus dans tous les fichiers asp.
  2. Utilisez un fichier pour créer un en-tête global du site (logos, menus, etc.) et l'inclure juste derrière. Appelez-le t-begin.asp
  3. Utilisez un fichier pour créer le pied de page global du site (droits d'auteur, Google Analytics, etc.) et la fermeture de tous les divs ou tables ouverts dans t-begin.asp. Permet d’appeler ce fichier t-end.asp
  4. Utilisez un dossier pour placer les fichiers de logique métier, appelés BUS. Les fichiers de ce dossier ne peuvent pas avoir d’inclus. Chaque fonction du fichier doit être précédée du nom de l’unité logique (IE: toutes les fonctions de products.asp doivent commencer par product _ *)
  5. Utilisez un dossier pour mettre du code d’UI réutilisé appelé UI. Les fichiers de ce dossier ne peuvent pas avoir d’inclus.

Exemple:

<%@  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. Cela me surprend constamment de voir combien de personnes détestent ASP. C'est un langage parfaitement adapté à la conception d'applications Web entre de bonnes mains.

Cependant, je concéderai que la façon dont les fichiers d'inclusion sont gérés dans ASP peut être un casse-tête, car (selon leur utilisation), ils doivent être chargés et analysés même si vous n'utilisez pas la moitié. les fonctions contenues dans.

J'ai tendance à avoir un fichier d'inclusion ( initialise.asp ou similaire) contenant lui-même des liens vers plusieurs bibliothèques de fonctions ( lib_http.asp , lib_mssql. asp ou similaire) et toutes les fonctions de la bibliothèque étant autonomes, vous ne craignez pas le croisement de variables. Tous les vars globaux sont déclarés et définis dans le fichier maître. Cela signifie que je peux utiliser une fonction n'importe où, n'importe quand et ne pas m'inquiéter de l'endroit où elle a été définie, elle est juste là pour l'utiliser. Et les IDE tels que Visual Studio et Primalscript ont la possibilité de "passer à la définition". lorsque vous trouvez un appel à une fonction que vous ne reconnaissez pas.

Ensuite, tous les inclus spécifiques au script sont inclus dans le script après l'appel de ce fichier d'inclusion principal.

J'admets qu'il s'agit d'une approche gourmande en mémoire, car toutes les fonctions de toutes les bibliothèques sont compilées pour chaque appel de script. La méthode doit donc être affinée pour chaque site que vous développez. est plus spécifique à la page. Ce serait bien de ne pouvoir charger que ce dont vous avez besoin - mais c'est l'approche de la DLL et elle n'est pas disponible pour la plupart des développements réels, et vous auriez également à peser le coût en processeur de la compilation de petits scripts par rapport à chargement des composants.

Une structure de répertoire concise est requise et facile à développer, mais cela peut être une corvée de parcourir tout le code d'un site existant et de modifier les liens ou les appels mappath. Sachez également que certains administrateurs IIS interdisent la méthode '.. \' de parcourir des répertoires via VBScript. Par conséquent, toutes les références de fichier doivent être des chemins absolus.

Je pense que vous devriez envisager de déplacer votre code d'ASP VBScript vers des DLL COM Visual Basic. cela vous soulagera d'avoir trop d'inclus.

Je ne connais pas de moyen d'empêcher une double inclusion, autre que de recevoir un message d'erreur. Voyez-vous des inclus placés tout au long de la page, ce qui les rend difficiles à repérer?

En passant, travaillez-vous avec une copie du code et de la base de données sur un serveur de développement? D'après mon expérience, la première chose à faire est de vous séparer du site en direct dès que possible. Bien que ce soit un problème au début, cela vous donnera la liberté d’apporter des modifications sans gâcher le site en direct. Il est facile de faire ce petit changement dans un include et BAM! tout le site tombe en panne.

J'ai travaillé sur quelques projets, comme vous l'avez décrit, et utilisé les stratégies suivantes:

Réécriture complète - parfait quand il y a du temps / de l'argent, mais je reçois généralement l'appel lorsque quelque chose ne va pas et que les résultats sont nécessaires dès que possible.

Projets plus petits - J'ouvre tout dans l'EDI et je commence simplement à rechercher tous les fichiers de projet pour les fonctions / sous-titres, afin de développer une connaissance de la logique d'inclusion. Presque à chaque fois, tout est éparpillé partout, alors je commence à reconstruire les inclus, organisés par logique métier. J'ai également rencontré du code en ligne (code brut, pas de sous-programmes ni de fonctions) jeté dans un include, aussi je vais généralement extraire le code dans la page pour le refactoriser plus tard.

Grands projets - Je vais utiliser le code que j'ai en main pour analyser l'inclusion des lignes avec des en-têtes de sous / fonction et les vider dans un fichier texte pour créer une liste des routines où elles se trouvent et y faire référence. Cela est pratique lorsque vous avez une tonne d’inclusions sur chaque page et que vous ne pouvez pas comprendre le code.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top