¿Cuál es el punto del AssetManager de Yii?

No puedo encontrar mucha información sobre el AssetManager de Yi’s para la gestión de archivos JS y CSS. Mi pregunta aquí es ¿para qué sirve usar AssetManager? No estoy seguro de qué valor agrega a mi proceso de desarrollo, de hecho, parece que complica mi código … cada vez que cambio mis scripts o css, debo ingresar y eliminar mi carpeta de activos para asegurarme de que Tengo las últimas versiones.

Parece que es mucho más simple simplemente poner todos los archivos Javascript en / webroot / js / y solo usar las tags para cargar los archivos en lugar de pasar por el problema de AssetManager. Además, la función registerCoreScript de Yii siempre coloca tags de script dentro de la etiqueta del encabezado, en lugar de colocarlas en la parte inferior del código, cerca de la etiqueta del cuerpo de cierre, según lo recomendado por YSlow.

Creo que debe haber un vacío en mi comprensión del AssetManager de Yii. ¿Alguien tiene alguna idea de por qué usar AssetManager es mejor que codificar las tags de script dentro del código PHP? Estoy un poco confundido…

¡Gracias!

Estoy seguro de que alguien puede responder esto mejor que yo mismo, pero básicamente es para que sus archivos JS y CSS de origen puedan permanecer en su carpeta protegida.

Esto es un poco más seguro para una cosa, pero el principal beneficio para mí es que puede comprimir y minimizar y, de lo contrario, procesar sus activos con el sistema de publicación de activos, y hace que sea más fácil alojar su JS y CSS en una CDN ya que es separado de su código base.

Además, aquí hay una respuesta oficial de qiang (el tipo que escribió Yii) sobre esto.

El principal beneficio del administrador de activos de Yii es que le permite estructurar sus componentes de manera autónoma .

Un cuento de un widget.

Considere un componente que es un widget de interfaz de usuario. Asummos que la distribución incluye un par de activos junto con la implementación del componente, por ejemplo, estos archivos:

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

Considere cómo incorporaría este widget en su aplicación si el administrador de activos no existiera. Los pasos típicos pueden incluir:

  1. Copie SuperWidget.php algún lugar dentro del directorio protected/
  2. Copie superwidget.js a su directorio js/
  3. Copie superwidget.css a su directorio css/
  4. Copie image_for_css.png en su directorio de images/ o quizás también dentro de css/ para ayudar a reducir las dependencias de ruta relativas

Luego, en el tiempo de ejecución, SuperWidget emitiría las tags adecuadas para incluir el CSS y JavaScript; para hacer esto, necesitaría saber dónde ha colocado exactamente estos activos . En otras palabras: algunas opciones con respecto a la instalación se pueden hacer de manera arbitraria, pero luego se establecen en piedra a menos que vaya y edite la fuente .

¿Es el widget reutilizable?

Si este widget estuviera altamente personalizado y fuera una parte inseparable de su aplicación, este enfoque funcionaría bien y no habría mucha necesidad de tener un administrador de activos. Pero, ¿y si es un componente útil que desea distribuir?

Los problemas comienzan a surgir.

En primer lugar, el esquema de implementación que hemos examinado requiere que los usuarios del widget copien diferentes archivos en diferentes directorios, lo que complica el procedimiento de instalación y aumenta la posibilidad de error.

Pero el mayor problema es que su esquema de implementación podría entrar en conflicto con el de cualquier otro componente desarrollado independientemente del suyo. ¿Qué pasa si alguien más decidió tener un archivo superwidget.js también?

Si las instrucciones de instalación de estos dos componentes entran en conflicto, obviamente uno de ellos no se puede instalar como se esperaba y luego se recurre a cambiar algunos detalles y piratear el código fuente del componente para adaptarse a estos cambios. Si posteriormente actualiza a una versión más nueva de ese componente, se verá obligado a contabilizar cuidadosamente sus personalizaciones, haciendo imposible una actualización de “copia / sobrescritura”.

Todo esto realmente no es bonito, y si bien es poco probable que suceda en la práctica, ciertamente no se siente bien.

Gestor de activos, hazlo asi

Aquí es donde entra el administrador de activos. Supongamos que decide estructurar su componente de esta manera:

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

Puede copiar esto directamente en algún lugar dentro de su directorio protected/ no importa qué otros componentes haya instalado; Lo peor que podría pasar aquí es que tendrías que cambiar el nombre de superwidget/ a otra cosa si hubiera un conflicto.

Usando el gestor de activos, SuperWidget.php publica el directorio assets/1337c0de/ , con la copia que termina en eg. No entra en conflicto con ningún otro activo publicado.

Esto significa que los recursos para SuperWidget no pueden entrar en conflicto con los de ningún otro componente , lo que hace que SuperWidget sea realmente reutilizable. Y dado que la estructura del directorio dentro de 1337c0de/ será la misma que en su distribución, CSS puede referirse a imágenes usando la ruta relativa ../images/ sin necesidad de referirse al valor del hash aleatorio (que solo se conoce después de la publicación) .

Lo que el administrador de activos no es

  • No es una forma de boost la seguridad. Su fuente de componente estaría en algún lugar dentro de un lugar protected/ todos modos (por lo tanto, no habrá mejoras), y los activos deben ser accesibles desde la web sin importar dónde se copien (no hay seguridad para ellos sin importar qué).
  • No es una solución completa para procesar sus activos (p. Ej., CSS de reducción). Si bien es posible instalar un administrador de activos personalizado que haga esto, no olvide que los activos incluidos con componentes reutilizables serán una pequeña minoría entre todos sus activos de “aplicación base”; Si desea una minificación general, también deberá procesar todo lo demás y el administrador de activos no lo ayudará.

TL; DR

El administrador de activos le permite crear componentes que son fácilmente distribuibles y se pueden incluir en las aplicaciones sin el temor de crear conflictos con otros componentes.

Otra ventaja que me gusta del administrador de activos, es que le permite actualizar sus archivos de activos sin tener que decirles a sus usuarios que borren su caché.

http://www.yiiframework.com/wiki/311/assetmanager-clearing-browser-s-cache-on-site-update/