What's the point of Yii's AssetManager?

I can't find much information about Yii's AssetManager for the management of JS and CSS files. My question here is what is the point of using the AssetManager? I'm开发者_Python百科 not sure what value it adds to my development process, in fact, it seems like it complicates my code... every time I change my scripts or css code, I have to go in and delete my assets folder to make sure I have the latest versions.

Seems it is much simpler to just put all Javascript files under /webroot/js/ and just use the tags to load the files instead of going through the trouble of AssetManager. Plus, Yii's registerCoreScript function always places script tags inside the header tag, instead of placing them at the bottom of the code, near the closing body tag, as recommended by YSlow.

I think there must be a gap in my understanding of Yii's AssetManager. Anybody have any ideas why using the AssetManager is better than hard-coding the script tags inside the PHP code? I'm a bit confused...

Thanks!

I'm sure someone can answer this better than myself, but basically it's so that your source JS and CSS files can remain in your Protected folder.

This is a little more secure for one thing, but the main benefit to me is that you can compress and minify and otherwise process your assets with the asset publishing system, and it makes it easier to host your JS and CSS on a CDN since it's separate from your codebase.

Also, here's an official response from qiang (the guy who wrote Yii) about this.

The main benefit of Yii's asset manager is that it allows you to structure your components in a self-contained manner.

A tale of a widget

Consider a component that is a UI widget. Let's assume the distribution includes a couple of assets along with the component implementation, for example these files:

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

Consider how you would incorporate this widget into your application if the asset manager did not exist. Typical steps might include:

1. Copy SuperWidget.php somewhere inside the protected/ directory
2. Copy superwidget.js to your js/ directory
3. Copy superwidget.css to your css/ directory
4. Copy image_for_css.png to your images/ directory or perhaps also inside css/ to help reduce the relative path dependencies

Then at runtime SuperWidget would emit appropriate tags to include the CSS and JavaScript; to do this, it would need to know where exactly you have placed these assets. In other words: some choices regarding the installation can be made arbitrarily, but then they are set in stone unless you go and edit the source.

Is the widget reusable?

If this widget were highly customized and meant to be an inseparable part of your application then this approach would work fine and there wouldn't be much need to have an asset manager. But what if it's a broadly useful component that you want to distribute?

Problems start arising.

First of all the deployment scheme we have examined requires users of the widget to copy different files into different directories, complicating the installation procedure and increasing the chance of error.

But the greater issue is that your deployment scheme could conflict with that of any other component developed independently of yours. What if someone else decided to have a superwidget.js file too?

If the installation instructions for these two components conflict then obviously one of them cannot be installed as intended, and then you resort to changing some details and hacking the source code of the component to accommodate these changes. If you later upgrade to a newer version of that component you will be forced to carefully account for your customizations, making a "copy/overwrite" upgrade impossible.

All of this is really not pretty, and while it can be unlikely to happen in practice it certainly doesn't feel right.

Asset manager, make it so

Here's where the asset manager comes in. Let's assume you decide to structure your component like this:

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

You can directly copy this somewhere inside your protected/ directory no matter what other components you have installed; the worst thing that could happen here is that you'd have to rename superwidget/ to something else if there was a conflict.

Using the asset manager, SuperWidget.php publishes the whole superwidget/assets/ directory, with the copy ending up at e.g. assets/1337c0de/ where assets/ is your application's base asset path and 1337c0de/ is a random hash created by Yii and guaranteed to not conflict with any other published asset.

This means that the assets for SuperWidget cannot possibly conflict with those of any other component, making SuperWidget truly reusable. And since the directory structure inside 1337c0de/ will be the same as in your distribution, CSS can refer to images using the relative path ../images/ without needing to refer to the value of the random hash (which is only know after publishing).

What the asset manager is not

• It's not a way to increase security. Your component source would be somewhere inside protected/ anyway (so no improvement there), and the assets need to be web-accessible no matter where they end up being copied (no security for them no matter what).
• It's not a catch-all solution for processing your assets (e.g. minifying CSS). While it is possible to install a custom asset manager that does this, don't forget that assets included with reusable components will a small minority among all of your "base application" assets; if you want minification across the board, you 'll have to also process everything else and the asset manager will not help you there.

TL;DR

The asset manager allows you make components that are easily distributable and can be included in applications without the fear of creating conflicts with other components.

Another perk that I like about the asset manager, is that it allows you to update your asset files without having to tell your users to clear their cache.

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