Quel est le point de AssetManager de Yû?

Question

Je ne peux pas trouver beaucoup d'informations sur la AssetManager de Yû pour la gestion des fichiers JS et CSS. Ma question ici est quel est le point d'utiliser le AssetManager? Je ne sais pas quelle valeur il ajoute à mon processus de développement, en fait, il semble que cela complique mon code ... chaque fois que je change mes scripts ou code css, je dois aller et supprimer mes actifs dossier pour vous assurer Je les dernières versions.

On peut dire qu'elle est beaucoup plus simple de mettre juste tous les fichiers Javascript sous / Webroot / js / et il suffit d'utiliser les balises pour charger les fichiers au lieu de passer par la peine de AssetManager. De plus, la fonction registerCoreScript de Yû place toujours les balises de script dans la balise d'en-tête, au lieu de les placer en bas du code, à proximité de la balise body de fermeture, tel que recommandé par YSlow.

Je pense qu'il doit y avoir une lacune dans ma compréhension du AssetManager de Yû. Tout le monde a des idées pourquoi l'utilisation de la AssetManager est mieux que coder en dur les balises de script dans le code PHP? Je suis un peu confus ...

Merci!

Answer 1

Je suis sûr que quelqu'un peut répondre à cette question mieux que moi-même, mais au fond, c'est pour que source les fichiers JS et CSS peut rester dans votre dossier protégé.

Ceci est un peu plus sûr pour une chose, mais le principal avantage pour moi est que vous pouvez compresser et rapetisser et de traiter autrement vos actifs avec le système d'édition d'actifs, et il facilite la votre hôte JS et CSS sur un CDN car il est séparé de votre base de code.

En outre, voici réponse officielle de qiang (le gars qui a écrit Yii) à ce sujet.

Answer 2

Le principal avantage du gestionnaire d'actifs est que Yû il vous permet de structurer vos composants de manière autonome .

Un conte d'un widget

Considérons un composant qui est un widget de l'interface utilisateur. Supposons que la distribution comprend deux actifs ainsi que la mise en œuvre des composants, par exemple ces fichiers:

SuperWidget.php
superwidget.css
superwidget.js
image_for_css.png

Voyez comment vous intégrer ce widget dans votre application si le gestionnaire d'actifs n'existait pas. étapes typiques pourraient inclure:

1. Copier quelque part de SuperWidget.php dans le répertoire protected/
2. Copier superwidget.js dans votre répertoire js/
3. Copier superwidget.css dans votre répertoire css/
4. Copier image_for_css.png dans votre répertoire images/ ou peut-être aussi à l'intérieur css/ pour aider à réduire les dépendances de chemin relatif

Ensuite, lors de l'exécution SuperWidget émettrait balises appropriées pour inclure le CSS et JavaScript; pour le faire, il aurait besoin de savoir exactement où vous avez placé ces actifs . En d'autres termes:. certains choix concernant l'installation peut être faite de façon arbitraire, mais ils ne sont pas immuables, sauf si vous allez modifier la source

Le widget réutilisable?

Si ce widget était très personnalisé et censé être une partie intégrante de votre application alors cette approche fonctionnerait très bien et il n'y aurait pas beaucoup besoin d'avoir un gestionnaire d'actifs. Mais si c'est un élément largement utile que vous souhaitez distribuer?

Problèmes de démarrage résultant.

D'abord le schéma de déploiement, nous avons examiné exige que les utilisateurs du widget de copier des fichiers dans des répertoires différents différents, ce qui complique la procédure d'installation et d'augmenter le risque d'erreur.

Mais la question est plus grande que votre schéma de déploiement pourrait entrer en conflit avec celle de tout autre composant développé indépendamment de la vôtre. Que faire si quelqu'un d'autre a décidé d'avoir un fichier superwidget.js aussi?

Si les instructions d'installation pour ces deux conflits composantes alors évidemment l'un d'entre eux ne peuvent pas être installés comme prévu, et vous avez recours à changer quelques détails et le piratage du code source du composant pour tenir compte de ces changements. Si vous mettez à niveau à une version plus récente de ce composant sera obligé de tenir compte soigneusement pour vos personnalisations, en faisant un « copier / Ecraser » Mise à jour impossible.

Tout cela est vraiment pas assez, et alors qu'il peut être peu probable de se produire dans la pratique, il ne se sent pas bien sûr.

Gestionnaire d'actifs, font donc

Voici où le gestionnaire d'actifs est disponible en Supposons que vous décidez de structurer votre composant comme ceci:.

superwidget/
  SuperWidget.php
  assets/
    css/
      superwidget.css
    js/
      superwidget.js
    images/
      image_for_css.png

Vous pouvez copier directement ce quelque part dans votre répertoire protected/, peu importe ce que les autres que vous avez installé des composants; la pire chose qui puisse arriver ici est que vous auriez à renommer superwidget/ à autre chose s'il y avait un conflit.

Utilisation du gestionnaire d'actifs, SuperWidget.php publie l'ensemble superwidget/assets/ répertoire, avec la copie se retrouver par exemple à assets/1337c0de/ où assets/ est le chemin d'actifs de base de votre application et 1337c0de/ est un hachage aléatoire créé par Yû et garanti de ne pas en conflit avec tout autre actif publiée.

Cela signifie que les actifs pour SuperWidget ne peut pas entrer en conflit avec ceux de tout autre composant , ce qui rend SuperWidget vraiment réutilisable. Et puisque la structure de répertoire à l'intérieur 1337c0de/ sera le même que dans votre distribution, CSS peut se référer à des images en utilisant la ../images/ de chemin relatif, sans avoir besoin de se référer à la valeur du hachage aléatoire (qui sait seulement après la publication).

Qu'est-ce que l'actif gérerr est pas

• Ce n'est pas un moyen d'augmenter la sécurité. Source composante serait quelque part à l'intérieur de toute façon protected/ (donc pas d'amélioration là-bas), et les actifs doivent être accessible sur le Web, peu importe où ils finissent par être copiés (pas de sécurité pour eux peu importe).
• Ce n'est pas un fourre-tout solution pour le traitement de vos actifs (par exemple minifying CSS). Bien qu'il soit possible d'installer un gestionnaire d'actifs personnalisée qui fait cela, ne pas oublier que les actifs inclus avec des composants réutilisables sera une petite minorité parmi tous vos actifs « application de base »; si vous voulez minification à tous les niveaux, vous aurez aussi tout processus autre et le gestionnaire d'actifs ne vous aidera pas là.

TL; DR

Le gestionnaire d'actifs vous permet de faire des composants qui sont facilement distribuables et peuvent être inclus dans les applications sans la crainte de créer des conflits avec d'autres composants.

Answer 3

Un autre avantage que je aime sur le gestionnaire d'actifs, est qu'il vous permet de mettre à jour vos fichiers d'actifs sans avoir à dire à vos utilisateurs de vider le cache.

http: // www .yiiframework.com / wiki / 311 / AssetManager-compensation-navigateur-s-cache sur le site de mise à jour /