Je compresse mon propre JS en utilisant YuiCompressor, mais y at-il une raison pour laquelle MicrosoftAjax.js n'est pas minifié? Ou existe-t-il des paramètres pour exécuter la version compressée (s'il existe une version compressée)? Ou dois-je le décompiler et réduire moi-même la ressource de script?Y a-t-il une raison pour laquelle MicrosoftAjax.js n'est pas minifié?
Je suis surpris de ces réponses trompeuses.
ASP.NET AJAX a toujours fourni à la fois le débogage et les versions compressées de MicrosoftAjax.js. Une combinaison du paramètre de débogage de web.config et ScriptManager's ScriptMode property contrôle quel script est référencé.
De plus, vous pouvez utiliser the "retail" setting pour forcer les scripts compressés indépendamment.
Merci pour ce Dave. Bon de savoir. – nickytonline
Brillant, je n'avais aucune idée du réglage "retail", notre société a l'habitude de déployer des choses en production en mode débogage, etc. – Matt
Je ne peux que supposer qu'il a été laissé en l'état pour faciliter la compréhension, et que vous avez déjà laissé entendre, je vois que vous connaissez des raisons pour lesquelles vous ne pouvez pas compresser vous-même, il est seulement JavaScript après tout - Bien que MS Vous aimeriez peut-être croire autrement, ils ne l'arrosent pas de poussière de lutin magique pour le rendre différent! :)
[Et regardons les choses en face; MS n'a jamais eu peur de la taille de son code, ont-ils?]
EDIT: Pour ma défense, au moment de l'écriture de cette réponse, je n'avais aucune expérience avec .NET 3.5; Je réalise maintenant qu'ils ont apporté plusieurs améliorations indispensables dans ce domaine.
Évidemment, MS ne pense pas que la taille du fichier JavaScript soit très importante (ce qui est fou). De plus, en fonction de mon expérience avec MS Ajax, ils injectent également plusieurs balises SCRIPT (parfois plus de 10) dans le balisage. Ces balises apportent des scripts à partir d'un gestionnaire WebResource.axd. Donc, dix demandes ou plus doivent être faites juste pour obtenir le Javascript nécessaire à l'exécution de la page! Juste pour ajouter au ridicule, ils clouent sur une chaîne de requête folle sur l'URL du gestionnaire, ce qui empêche probablement le script d'être mis en cache par le navigateur.
Cette folie est une raison suffisante pour moi de fossé MS Ajax complètement et passer à jQuery, ce qui est beaucoup mieux bibliothèque, surtout depuis Visual Studio now has Intellisense for jQuery.
Qui a voté contre cette réponse, et pourquoi? –
Pas sûr, en hausse de vote de moi parce que je partage votre opinion sur ASP.NET Ajax. –
J'ai été downvoted aussi - peut-être nous avons un staffer MS sur SO? :) Je souhaite que les votants expliqueraient pourquoi ils ont voté ainsi ... – CJM
qui préféreriez-vous:
pourquoi pas les deux? jQuery entre dans les deux, non? –
Alors qu'il serait trivial d'avoir les deux versions, et assez utile aussi, si vous alliez prendre la voie facile, vous devriez fournir la version non compressée. +1 parce que cela ne méritait pas un vote négatif. – CJM
@Neil N. Je suis d'accord, pourquoi pas les deux? Lors du développement utilisez non compressé et en prod utilisez la version minifiée/obfusquée. – nickytonline
Voir http://www.codeproject.com/KB/aspnet/AspNetOptimizer.aspx, vous avez besoin
enableScriptMinification="true"
et ajouter à la liste MicrosoftAjax.js
J'ai déjà lu cet article, mais merci de l'avoir posté ici. Ce que je cherchais cependant était une solution prête à l'emploi de Microsoft Ajax. On dirait que le bricolage est le moyen d'aller sur celui-ci. – nickytonline
Tous les scripts sont System.Web.Extensions minified - il existe deux versions de chacun, comme une excellente réponse de Dave Ward souligne. ScriptManager utilisera par défaut la version de débogage lorsque le fichier web.config est en mode débogage. Retournez-le pour libérer avec le paramètre de vente au détail ou debug = "false", et regardez le script ensuite.
Aussi, les scripts servis par WebResourceHandler ou ScriptResourceHandler sont en fait mises en cache.Ils sont cachés de la meilleure façon possible - pour toujours, de sorte qu'ils n'ont même pas besoin de 301 lors de futures visites. La chaîne de requête est telle qu'elle est, car elle contient des données cryptées. Il est chiffré car il contient des informations sur la ressource de script, y compris un nom d'assembly, ainsi que parce qu'il empêche les attaques d'inondation du cache.
Je ne cherche pas de représentant ici, je voulais juste donner plus de détails.
Bon à savoir sur le WebResourceHandler ou le ScriptResourceHandler mis en cache. Donc, je suppose que lorsque vous effectuez des modifications et que vous les redéployez, elles sont à nouveau mises en cache mais en tant que fichiers différents car la chaîne de requête cryptée a changé? – nickytonline
Yup. Toute modification de la ressource modifie la chaîne de requête, ce qui entraîne la création d'un élément nouvellement mis en cache. Aussi, je n'ai pas mentionné que les scripts sont compressés par gzip, aussi. – InfinitiesLoop
+1 Bonne question! –
Eh bien, d'après les réponses que j'ai reçues, il ne semble pas y avoir de moyen d'obtenir une version réduite/compressée de MicrosoftAjax.js. Donc, il semble que le bricolage est la voie à suivre, comme je l'ai mentionné dans la réponse que j'ai choisie. Comme je l'ai mentionné à Josh, dans ASP.NET 3.5, vous pouvez combiner des scripts maintenant, http://msdn.microsoft.com/en-us/library/cc488552.aspx. Nous n'avons pas encore migré vers la version 3.5, mais quand nous le ferons, je le vérifierai. J'ai lu des critiques mitigées à ce sujet. De plus, j'ai ajouté jQuery au projet il y a un certain temps, donc je suis en train de jouter lentement tout ce qui peut être qualifié. – nickytonline
Mon commentaire ci-dessus n'est plus vrai. La réponse de Dave Ward est la bonne, donc pas de bricolage. – nickytonline