Ресурсы
Yii имеет встроенный механизм публикации ресурсов (asset). Он полезен в следующих случаях:
- При оформлении кода как расширения, ресурсы которого содержатся в той же папке, что и код.
- При использовании ресурсов за корнем вебсервера.
- Для обработки ресурсов непосредственно перед публикацией. Например, сжатия CSS и JavaScript.
- При использовании одного и того же ресурса множеством компонент (для исключения дубликатов).
Note|Примечание: Для работы с ресурсами в корне вебсервера должна быть создана папка assets с правами
на запись для PHP.
Публикацией ресурсов активно пользуется сам фреймворк. Происходит это, например,
при использовании CLinkPager или CGridView.
Что находится в папке assets?
После нескольких запусков приложения в assets образуется примерно следующее содержимое:
Папки вида 1a6630a0 создаются для предотвращения конфликта имён ресурсов.
Здесь 1a6630a0 — хеш от полного пути к папке, в которой размещён
подключаемый ресурс.
Tip|Подсказка: Получить текущий или задать новый полный путь к папке
assets можно при помощи Yii::app()->assetManager->basePath ,
а URL при помощи Yii::app()->assetManager->baseUrl .
Публикация ресурсов
Для публикации ресурса или папки с ресурсами используется метод
CAssetManager::publish(), принимающий следующие параметры:
- $path — путь к ресурсу или папке с ресурсами.
- $hashByName — сохранять ли один и тот же хэш при нескольких публикациях. Полезно
при использовании ресурса несколькими компонентами. По умолчанию равен false . - $level — уровень вложенности при копировании папки. При -1 копирует всё. При 0 — только файлы в корневой папке.
- $forceCopy — копировать ресурс даже если он уже опубликован. Удобно использовать
во время разработки задав значение как YII_DEBUG. Не рекомендуется использовать
на живом проекте, так как производительность падает.
Возвращается абсолютный URL опубликованного ресурса.
Note|Примечание:
При публикации отдельного ресурса, во избежание ненужного копирования проверяется
время его модификации. При обновлении ресурса автоматически происходит его перепубликация.При публикации папки, её содержимое копируется рекурсивно. При этом метод проверяет
только наличие папки с таким же именем, но не отдельных ресурсов. То есть при изменении
ресурсов в этой папке её содержимое заново опубликовано не будет.
Примеры публикации и подключения ресурсов
JavaScript
Tip|Подсказка: вместо Yii::app()->assetManager->publish() можно использовать
его синоним CHtml::asset() .
Изображение
Получение путей и URL к уже опубликованным ресурсам
Для получения пути или URL опубликованного ресурса можно воспользоваться
CAssetManager::getPublishedPath() и CAssetManager::getPublishedUrl() соответственно.
Методы принимают два параметра:
- $path — путь к публикуемому ресурсу.
- $hashByName — сохранять ли один и тот же хэш при нескольких публикациях. Полезно
при использовании ресурса несколькими компонентами. По умолчанию равен false .
Если указанный ресурс не опубликован, возвращается false .
Размер папки assets и её очистка
Фреймворк не очищает папку assets , так что при длительной разработке в ней может
скопиться довольно много ресурсов. В том числе и тех, которые больше не используются.
Очищать папку assets полностью безопасно и даже рекомендуется это делать при
обновлении фреймворка.
Assets Folder in Android Studio
It can be noticed that unlike Eclipse ADT (App Development Tools), Android Studio doesn’t contain an Assets folder in which we usually use to keep the web files like HTML. Assets provide a way to add arbitrary files like text, XML, HTML, fonts, music, and video in the application. If one tries to add these files as “resources“, Android will treat them into its resource system and you will be unable to get the raw data. If one wants to access data untouched, Assets are one way to do it. But the question arises is why in the asset folder? We can do the same things by creating a Resource Raw Folder. So let discuss how the assets folder is different from the Resource Raw folder?
How the asset folder is different from the Resource Raw folder?
In Android one can store the raw asset file like JSON, Text, mp3, HTML, pdf, etc in two possible locations:
- assets
- res/raw folder
Both of them appears to be the same, as they can read the file and generate InputStream as below
But when to use which folder?
Below is some guidance that might be helpful to choose
1. Flexible File Name: (assets is better)
- assets: The developer can name the file name in any way, like having capital letters (fileName) or having space (file name).
- res/raw: In this case, the name of the file is restricted. File-based resource names must contain only lowercase a-z, 0-9, or underscore.
2. Store in subdirectory: (possible in assets)
- assets: If the developer wants to categories the files into subfolders, then he/she can do it in assets like below.
- res/raw: In this case, files can only be in the root folder.
3. Compile-time checking: (possible in res/raw)
- assets: Here, the way to read it into InputStream is given below. If the filename doesn’t exist, then we need to catch it.
- res/raw folder: Here, the way to read it into InputStream is:
So putting a file in the res/raw folder will provide ensure the correct file-name during compile time check.
4. List filenames at runtime: (possible in assets)
- assets: If the developer wants to list all the files in the assets folder, he/she has used the list() function and provide the folder name or ” “ on the root folder as given below.
- res/raw: This is not possible in this folder. The developer has to know the filename during development, and not runtime.
So, in assets, one can read the filename during runtime, list them, and use them dynamically. In res/raw, one needs to code them ready, perhaps in the string resources file.
5. Filename accessible from XML: (possible in res/raw)
- assets: No simple way the developer can arrange an XML file (e.g. AndroidManifest.xml) to point to the file in the assets folder.
- res/raw: In any XML files like in Java, the developer can access the file in res/raw using @raw/filename easily.
So if you need to access your file in any XML, put it in the res/raw folder. Let’s make a table to remember the whole scenario easily.
В чем отличие public и assets?
Что такое (public, assets) и что в нем хранить? Зачем нам это?
public — папка в которой лежат публично доступные файлы разого назначения например index.html, hello.html и.т.д. как правило это и есть корень сайта /
assets — папка в которой лежат ассеты сайта (картинки, скрипты, стили, шрифты) и которая может быть легко переписана компилятором webpack и им подобным без потери важных данных.
storage — папка куда пользователи могут например залить видеофайл или автарку но которая так или иначе учавствует в процессе работы сайта. Как правило управляеться backend скриптами.
static — папка куда разработчик кладёт ассеты сайта (картинки, скрипты, стили, шрифты). Но которая управляеться именно разработчиком, а не создаёться автоматический при компиляции webpack’ом.
А вообще такое разделение нужно не только что-бы было удобно пользоваться посткомпиляцией, но ещё активно учавствует в правильной настройке кеширования сайта.
Структура папок⚓︎
Поскольку Grav — это CMS на основе файлов, то есть ни одна база данных не поддерживает его, структура папок вашего сайта очень важна. На верхнем уровне вашей установки Grav структура папок выглядит следующим образом:
Итак, давайте углубимся в каждую из этих папок верхнего уровня и объясним, для чего они нужны:
/assets⚓︎
Папка assets используется новой системой управления активами в Grav для хранения обработанных .css и .js файлов.
Эта папка не должна использоваться для хранения каких-либо пользовательских данных, поскольку она обычно очищается от всех данных.
/backup⚓︎
Папка backup является папкой по умолчанию для резервных копий Grav.
Папка bin содержит консольные приложения Grav, которые могут быть использованы для выполнения некоторых полезных задач из командной строки. Это относительно продвинутая функция, в первую очередь предназначенная для разработчиков, поэтому мы отложим эту тему для дальнейшего обсуждения.
/cache⚓︎
Папка cache используется для хранения временных кэшированных файлов, которые автоматически создаются Grav для повышения производительности. По умолчанию Grav автоматически выбирает наилучший доступный вариант для вашего хостинга, чтобы обеспечить максимальную скорость работы вашего сайта.
Если Grav решит, что файловая система является лучшим методом кэширования, сгенерированные файлы будут сохранены в этой папке. Механизм шаблонов Twig также использует это расположение для хранения своих предварительно скомпилированных файлов шаблонов. Опять же, это сделано для того, чтобы Grav работал с оптимальной скоростью.
Эта папка не должна использоваться для хранения каких-либо пользовательских данных, поскольку она обычно очищается от всех данных.
/images⚓︎
Grav поставляется со встроенной мощной, но очень простой в использовании библиотекой для работы с изображениями. Это означает, что вы можете легко изменять размер изображения на лету из вашего контента или даже из плагина. Эти изображения хранятся в папке images , поэтому их можно использовать повторно, если снова запрашивается то же изображение с тем же размером.
Эта папка действует как кэш изображений и предназначена для автоматически генерируемых файлов. Предоставляемые пользователем файлы должны храниться в user/pages/ , user/themes/ или даже в пользовательской папке user/images/ .
Эта папка не должна использоваться для хранения каких-либо пользовательских данных, поскольку она обычно очищается от всех данных.
/logs⚓︎
Когда Grav обнаруживает ошибку или если у вас включено дополнительное ведение журнала или профилирование, он сохраняет соответствующие файлы журнала в папке logs .
/system⚓︎
Папка system — это место для хранения файлов ядра Grav. Вам не следует ничего редактировать в этой папке, потому что обновление Grav может перезаписать ваши изменения. Если вам нужно изменить что-то, связанное с тем, как работает Grav, вы можете использовать плагины, как описано в последующих главах.
Папка tmp используется Grav и плагинами для хранения временных файлов.
Эта папка не должна использоваться для хранения пользовательских данных, так как она регулярно очищается от всех данных.
/vendor⚓︎
Папка vendor содержит важные библиотеки, на которые опирается Grav. Эта папка похожа на папку system в том, что её содержимое не следует редактировать, если вы не абсолютно уверены в том, что делаете.
При установке Grav с GitHub папка vendor не устанавливается автоматически. Чтобы создать и заполнить папку vendor, вам нужно запустить команду bin/grav install или composer install из корня вашего экземпляра Grav. Более подробную информацию можно найти в разделе Установка.
/user⚓︎
Это самая важная папка для большинства пользователей Grav. В этой папке вы будете тратить время на создание контента, использование плагинов и редактирование тем. Давайте ещё немного углубимся в эту папку:
/user/accounts⚓︎
Папка account — это место, где вы будете определять учетные записи пользователей, если для определённых частей вашего сайта требуются ограничения доступа.
/user/blueprints⚓︎
Папка blueprints содержит ваши собственные чертежи для сайта.
/user/config⚓︎
Файлы в каталоге config используются для настройки веб-сайта и были рассмотрены в предыдущей главе.
/user/data⚓︎
Папка данные может использоваться плагинами для хранения данных, на которые вы можете ссылаться позже. Хорошим примером плагина, использующего эту папку, является плагин Forms, который может принимать веб-форму и хранить отправленные данные в текстовом файле в этой папке. Вы также можете хранить здесь пользовательские файлы или всё, что хотите.
По умолчанию эта папка недоступна через браузер.
/user/images⚓︎
Папка images может использоваться для хранения ваших изображений. Доступ к нему можно получить с помощью потока image:// .
/user/languages⚓︎
/user/pages⚓︎
Это сердце Grav. Папка pages — это место, где вы создаете и редактируете свой контент. Более подробно мы поговорим об этом в следующей главе.