Inspiré par ce post.
Il s'agit d'un exemple d'application développée avec asp et typescript classiques.
Parfois, nous sommes simplement coincés avec d’anciennes applications exécutées en asp classique.
TypeScript ajoute des outils utiles pour le développement comme IntelliSense, la refactorisation, un véritable système de classes, un système de types, les erreurs de compilation, l'auto-complétion, jsdocs, etc.
Il peut être utilisé dans des applications existantes, en partageant le code et l'état de session.
En plus, c'était amusant à faire :)
Pour récupérer les packages js et css à partir de nuget, exécutez la commande Update-Package -Reinstall
depuis la console du gestionnaire de packages.
Le package handlebars.TypeScript.DefinitelyTyped installe deux fichiers .d.ts, il faut supprimer celui de la version 1.0.0.
Il fonctionne sur IIS Express, il peut être exécuté directement depuis Visual Studio (sans débogage).
Les scripts s'exécutent en asp classique dans l'ordre suivant :
<script runat="server">
qui ne correspondent pas à la langue par défaut ;<% %>
);<script runat="server">
qui correspondent à la langue par défaut. Pour pouvoir exécuter la fonction main()
après les scripts inclus, le langage par défaut actuel a été conservé comme VBScript avec la directive <%@ language="VBScript" %>
.
Une option pour utiliser TypeScript avec asp serait d'ajouter une étape au processus de construction qui entoure le contenu dans des balises asp et modifie l'extension en .asp.
Source
Quelques configurations importantes pour TypeScript lors du ciblage d'ASP classique :
{
"compilerOptions" : {
"target" : "es3" ,
"lib" : [ "es5" , "scripthost" ] ,
"module" : "none"
}
}
ASP peut s'exécuter avec VBScript ou JScript, qui est la version Microsoft de Javascript, et il est conforme à la spécification ECMAScript 3.
Les bibliothèques de types par défaut utilisées par TypeScript incluent de nouvelles API de navigateur qui définissent un objet Request et Response, nous devons donc définir les bibliothèques que nous voulons utiliser pour pouvoir définir ces objets avec l'API d'ASP.
Enfin, asp ne prend en charge aucune des sorties possibles du module.
Le code généré côté serveur aura l'extension .js, que IIS envoie normalement au client. Pour masquer les sources d'asp, nous pouvons ajouter la configuration suivante :
<!-- IIS 7+ -->
< system .webServer>
< security >
< requestFiltering >
< hiddenSegments >
< add segment = " src " />
</ hiddenSegments >
</ requestFiltering >
</ security >
</ system .webServer>
Cette configuration ne fonctionne pas pour IIS 6 ou version antérieure.
Pour cette application, au lieu d'utiliser différents fichiers .asp incluant les sources js nécessaires, un workflow mvc a été utilisé avec un seul point d'entrée, Default.asp, un routage avec des paramètres QueryString.
Une autre option serait de rediriger les erreurs 404 vers un fichier asp, qui effectue le routage en lisant le chemin tenté.
La syntaxe classique utilisée par asp pour définir l'état de la session ou de l'application n'est pas prise en charge par TypeScript :
<%
Session("user_id") = 1
Application("connectionstring") = "some string"
%>
L'alternative serait de définir une fonction pour les définir et de déclarer l'interface en dactylographié. Par exemple :
function setSession ( key , val ) {
Session ( key ) = val ;
}
Puis en dactylographié :
declare function setSession ( key : string , val : any ) : void ;
Malheureusement, l'objet Error de JScript ne définit pas la propriété stack, il n'existe donc pas de moyen simple de créer une trace de pile, puisque les méthodes de l'objet sont émises en tant que fonctions anonymes par typescript.
Cette application utilise Handles pour la création de modèles et Moment.js pour la gestion des dates. Les deux ont une structure UMD (Universal Module Definition), qui n'est pas compatible avec l'asp classique, car l'objet global n'existe pas.
Dans asp JScript classique, une variable dans une fermeture est "exportée" vers la portée globale si elle est définie sans être déclarée. Par exemple :
( function ( ) {
var localFn = function ( ) {
// ...
} ;
// classic asp export
// this makes globalFn available in the global scope
globalFn = localFn ;
} ) ;
A cause de ce comportement, il est nécessaire de remplacer les contrôles UMD dans les deux bibliothèques par cette syntaxe "d'exportation".
Notez que seules les bibliothèques qui ne dépendent pas du DOM fonctionneront.