Reorganization of assets libs

[magefad]

Maybe we should split it into /assets/vendor/lib-name? To be able to just put all the plugin files/libraries in his folder instead of looking where to put them and how to name css and js files?

[hijarian]

More than that, I think that ideally each widget should be self-contained, and placed in it's own folder. Don't know for now how it should work with packages like jQueryUI or Bootstrap, but for individual widgets like Select2 it definitely should be done that way.

[magefad]

About widgets like Editable_.php in originak I think to do the same :/widgets/vendors/editable.Editable_.php

And class /widgets/TbEditable*.Php extends /widgets/vendors/editable.Editable *.Php

[hijarian]

It should not extend it, it'll become untestable as a result. However, I agree with it. As I said, I was going to do it myself anyway.

[magefad]

I mean, will we work as I described above, ultimately? All third-party widgets through extended vendor, all core Booster ones leave as they are.

Ну я имею ввиду так и будем, как описывал в своем посте выше, в итоге то? Все сторонние виджеты через extended vendor, ну а те что в ядре Booster'а так же оставить как есть сейчас

[magefad]

Via "extended" is a bad choice, checked it... Question is, how to separate widgets themselves (X-Editable being the example).

Через extended плохой вариант, посмотрел.. Вопрос - как разделять сами виджеты (на примере X-Editable)

[hijarian]

My opinion is this: we should completely drop the current separation of assets folder by file type. There should not be the css, js, fonts and other shit. There should be subfolders ideally according to our packages, so each widget will be able to just grab everything it needs from single place and that's all. This way it'll be much easier to both add new widgets and update existing.

By the way, why do we still store the LESS files? Are they needed anywhere?

[hijarian]

Okay, as of 2.0.0 assets will be stored as assets/package-name.

All packages will be listed in packages.php and all widgets will use the packages and not direct file inclusion.

Unfortunately, it would mean that we'll need our own packages processor, because there's no built-in way in Yii to specify where to place the CSS and JS files: in head or before end of body, and there's libraries which require correct order of assets placement (i. e., one file in head, one at end of body). Also, javascript loaded from head is an impact on performance.

[gureedo]

What about localization files in packages?

[hijarian]

Each assets/package-name will be structured exactly like the original library was structured. You can see the example of it by comparing the Bootstrap and Select2 assets folders - former is structured into css, img, js and latter is just a bunch of files, all in same folder.

So, if locales would be included in original library package, they'll be inside assets/package-name according to original file organization.

I don't want to reorganize 3rd-party libraries (however I would really prefer to), because it potentially has to be done each upgrade of a library in question and if there's stylesheets dependent on image files then I would need to make changes to foreign CSS files which is the thing I will avoid at all costs.

[gureedo]

No, i'm talking about how will be managed localizations in packages of asset manager? Currently some packages generated dynamically and some statically in packages.php

[hijarian]

Oh. Got it. That's interesting problem. I think that we can push the knowledge about the internal structure of the individual widget away from the main Bootstrap component and down to the widget itself. Widget will generate the proper package specification and register it in the main component's assetRegistry. Something like

class AnyYiiBoosterWidget extends Something implements CrucialWidgetBehavior 
{
    public function registerAssets()
    {
        $package = $this->makeMyPackageSpecification();
        Yii::app()->booster->assetRegistry->addPackage($package);
        Yii::app()->booster->assetRegistry->registerPackage('any-yii-booster-widget');
    }
}

It's still horrible, though, but this way we completely remove the handling of assets from the main component and make possible dynamic generation of asset packages, including all locales/plugins/whatever, retaining the dependency management capabilities we have now.

It's also the first sane usage of Bootstrap.assetRegistry, which is 100 times better than calling Yii::app()->clientScript.

[digitalcrab]

Postponed to version 3.0.0. Will be done together with the integration of new Bootstrap.