Для виджета нужно создавать отдельный Bndle?

[denisOgr]

Есть шаблон админ панели, в которой много взяких js(jquery) виджетов.
Есть один одбий бандл, который подключает общие асеты.
Но у каждого виджета есть свои(уникальные) css,js.
Нужно ли для каждого виджета создавать свой бандл в котором писать ассеты и зависимые бандлы?
Если да, то получается в самом виджете мне нужно будет выполнить код:

Код: Выделить всё

MyWidgetAssetsBundle::register($this->view) 

Но в документации (http://www.yiiframework.com/doc-2.0/gui ... set-bundle), в разделе Registering asset bundle написан вот такой код:

Код: Выделить всё

AppAsset::register($this->view);

Не пойму, зачем мне регистрировать в глобальном бандле вью? А где и как переносить js/css/image в assets и где их подключать?

Сейчас я так сделал:

Код: Выделить всё

$view = $this->getView();
$js = '$("#' . $this->wrapperId . '").jarvisWidgets({.............})';
//JARVIS WIDGETS
\Yii::$app->assetManager->publish(dirname(dirname(__FILE__)) . '/assets/js/smartwidgets/jarvis.widget.min.js');
$jsFile = \Yii::$app->assetManager->getPublishedUrl(dirname(dirname(__FILE__)) . '/assets/js/smartwidgets/jarvis.widget.min.js');
$view->registerJsFile($jsFile,['yii\web\JqueryAsset']);
$view->registerJs($js);
 

[zelenin]

все верно пишите. Надо бандлы делать и регистрировтаь их в нужной вьюшке.

Только пока вы тут про бандлы, на гитхабе решили разработку еще на год продлить, переделав систему ассетов (да-да, очередное глобальное изменение после выхода беты).

[Stepan Selyuk]

Только пока вы тут про бандлы, на гитхабе решили разработку еще на год продлить, переделав систему ассетов (да-да, очередное глобальное изменение после выхода беты).

Серьезно?

[zelenin]

Только пока вы тут про бандлы, на гитхабе решили разработку еще на год продлить, переделав систему ассетов (да-да, очередное глобальное изменение после выхода беты).

Серьезно?

вполне
https://github.com/yiisoft/yii2/pull/4855

причем когда за пару-тройку месяцев до этого один разработчик предложил подобную систему, его резко осадили. Но вот решили переделать, многократно усложнив для того программиста, на которого рассчитан фреймворк.
Сказать честно, меня стал раздражать этот спонтанный, бесцельный, бестолковый стиль разработки. Заявлялось, что после выхода беты не будет изменения апи, но этих изменений уже было предостаточно. Конца и края разработке не видно.

[zelenin]

https://github.com/yiisoft/yii2/issues/4926
пожалуйста. баг, непозволяющий использовать категории через точку, будет исправлен к 2.0.1) офигеть)

ладно, это уже оффтоп.

[Stepan Selyuk]

Нда.. придется много переделывать. Особенно я не понимаю, как теперь выпускать и продавать приложение в виде скрипта. Ну не на всех хостингах установлен Node.js. Считаю со стороны разработчиков фреймворка некорректно ставить пользователей в такие узкие рамки. Не говорить же покупателям, вот скачайте этот образ и залейте его в облако. Никто не хочет переплачивать. Ну чтож, будем посмотреть.

[Stepan Selyuk]

https://github.com/yiisoft/yii2/issues/4926
пожалуйста. баг, непозволяющий использовать категории через точку, будет исправлен к 2.0.1) офигеть)

ладно, это уже оффтоп.

Я давно от этого отошел в сторону автогенерации категорий через crc32 от имени файла. Все равно все хранится в базе и разные категории я полагаю только для того, чтобы иметь возможность ставить разные переводы одного исходного сообщения, в разные категории. Что-то вроде: FAQ - ЧаВо и FAQ - Вопросы и Ответы.

И сейчас (пока что идет разработка) использую враппер для Yii::t:

Код: Выделить всё

/**
 * Обертка для Yii::t()
 *
 * @param string $message
 * @param array  $params
 * @param string $language
 * @param int    $debug_btrace_level
 *
 * @throws yii\base\InvalidParamException
 * @return string
 */
function __( $message, $params = [ ], $language = null, $debug_btrace_level = 1 )
{

    // Примерно занимает ~15 микросекунд
    $debug = debug_backtrace( null, $debug_btrace_level );

    $filepath = $debug[ $debug_btrace_level - 1 ][ 'file' ];

    static $categories = null;
    static $app_path = null;

    // Устаналиваем путь к каталогу protected приложения
    if (is_null( $app_path )) {
        $app_path = Yii::getAlias( '@app' ) . DIRECTORY_SEPARATOR;
    }

    $cfile = build_path( Yii::getAlias( '@runtime' ), 'i18n.categories' );

    if (is_null( $categories )) {
        if (is_file( $cfile )) {

            $categories = unserialize( file_get_contents( $cfile ) );

            // На случай ошибки десериализации
            if ($categories === false) {
                $categories = [ ];
            }

        } else {
            $categories = [ ];
        }
    }

    // Получаем относительный путь к файлу вида "components/utils/file.php"
    $filepath = substr( $filepath, strlen( $app_path ) );

    // Получаем категорию перевода и сохраняем данные в $data если их нет
    if (isset( $categories[ $filepath ] )) {
        $category = $categories[ $filepath ];
    } else {
        $category = $categories[ $filepath ] = abs( crc32( $filepath ) );
        file_put_contents( $cfile, serialize( $categories ) );
    }

    return Yii::t( $category, $message, $params, $language );
}
 

Когда сообщения сохраняются в базу, еще сохраняется md5 их содержимого. И поиск таким же образом идет через поиск по хешу (и категории).

[zelenin]

у вас частный случай использования перевода. Разные категории нужны например для разных расширений или модулей.

[Stepan Selyuk]

А смысл? Конечному пользователю важно одно - все должно быть локализовано на его языке. Я везде применяю эту конструкцию в своем коде, в разных модулях и т.д. и потом есть отдельный модуль для переводчиков всех этих сообщений. Когда еще только изучал Yii1, я понял что категории в своей массе нужны, чтобы сократить поиск текста сообщения в массиве (если исходить из хранения сообщений в файлах, в массивах php), но для базы проще искать сообщения по хешу, поставив туда индекс.

Какие-то сторонние расширения могут использовать другие механизмы для хранения и поиска сообщений.

[zelenin]

А смысл? Конечному пользователю важно одно - все должно быть локализовано на его языке. Я везде применяю эту конструкцию в своем коде, в разных модулях и т.д. и потом есть отдельный модуль для переводчиков всех этих сообщений. Когда еще только изучал Yii1, я понял что категории в своей массе нужны, чтобы сократить поиск текста сообщения в массиве (если исходить из хранения сообщений в файлах, в массивах php), но для базы проще искать сообщения по хешу, поставив туда индекс.

Какие-то сторонние расширения могут использовать другие механизмы для хранения и поиска сообщений.

смысл простой: переводы разных расширений не должны пересекаться. для этого они должны иметь разные категории.

[Stepan Selyuk]

Ну и у меня так же, только зависимость не от конкретной категории, которая может быть одна на несколько файлов одного расширения, а от конкретного файла (crc32 от его пути относительно каталога приложения). Я не говорю что нужно отказываться от именных категорий, где-то это полезно. Но с моей точки зрения, раз все сохраняется в базе, проще так. В процессе публикации скрипт проходится по файлам и выдергивает все сообщения из файлов в базу.

[zelenin]

без разницы. не вижу смысла crc хранить - это ненаглядно и не дает преимуществ.

[Stepan Selyuk]

По сути crc32 хранится только для того, чтобы переводчики смогли сделать разные переводы одного и того же сообщения в разных файлах. Но и также потому что поиск по цифровому индексу быстрее, чем по varchar индексу. А насчет наглядности, - его (crc32) же никто не видит. В коде просто:

Код: Выделить всё

__('у меня {n, plural, =0{нет котлет} other{есть котлеты}}', ['n'=>0]);
// вместо
Yii::t('path/to/my/category', 'у меня {n, plural, =0{нет котлет} other{есть котлеты}}', ['n'=>0]);
 

[zelenin]

понял вас. то есть при загрузке инстанса приложения у вас подгружаются с файловой системы десятки файлов для прочтения кода, потом эти же файлы обсчитываются crc32, потом у вас заходят сотни пользователей в минуту, и вы открываете новую тему с вопросом: почему так медленно работает мое приложение?

[Stepan Selyuk]

Обсчитываются только пути и там карта по ним делается постепенно. Это почти мгновенно (впрочем полную карту файлов, где используются такие вызовы можно создать при публикации приложения). Также сообщения же кешируются в sqlite, поэтому видятся затраты только на составление карты "path/to/file"=>"crc32", и потом мгновенная выборка с нее, а дальше уже оптимизированный поиск сообщения в mysql, или загрузка из кеша sqlite. Опять же так как используются цифровые категории, это очень быстро. В одной категории в базе врядли будет больше 10-20 сообщений.

[zelenin]

но зачем?

[Stepan Selyuk]

Ну как зачем)) для удобства кодирования и красоты кода конечно. У меня уже были приложения с тысячами сообщений (>100тыс общий объем переводимых сообщений) и с десятком локализаций. Вот после этого начинаешь думать о централизации. К тому же после копипасты кто-то обязательно забудет, или поленится изменить категорию очередного сообщения.

[zelenin]

то есть у вас в приложении например 100 файлов с Create и соответственно сто слов Create в разных категориях надо изменить?

[Stepan Selyuk]

Немного не понял вас, но если вы о том, что нужно поменять неправильный перевод фразы на правильный и сделать это везде, то модуль для переводчиков это умеет и также, когда добавляются новые сообщения в базу (при публикации приложения и скана файлов), то выполняется поиск уже переведенных сообщений с таким же хешем, без внимания на категорию.

[mickgeek]

Stepan Selyuk, довольно интересная задумка и реализация. Возьму на заметку.