@diosmosis opened this Issue on October 1st 2014 Member

As title. Instead of using the AssetManager events, we can load javascripts/stylesheets via entries in plugin.json, ie:

    stylesheets: [
    javascripts: [

CC @mattab @tsteur Do you think this will cause problems?

@mattab commented on October 2nd 2014 Member

We can make the change I think as long as we keep BC. Something similar is actually already implemented in plugin.json (theme and javascripts attributes should work)

Maybe @tsteur has some other thought

@tsteur commented on October 2nd 2014 Member

I would personally not put it there as it is not "metadata" of the plugin. Logically, it does not really belong there. As we want to name it "composer.json" in the future and also reuse their structure I would not really add new fields to it or only if it is like metadata.

Would rather create a PHP class for this or use an assets.json file (might be confusing as well - why sometimes PHP, why sometimes json, ...) or something else. Maybe by default all JS and less files are included once plugin is activated and event is only there to restrict files. Problem: This works only as long as there is no order of the files which might work for JS files but can be problematic for LESS files (but shouldn't as long as it is not a theme which we can treat differently).

@diosmosis commented on October 2nd 2014 Member

Some random thoughts:

  • automatic inclusion sounds workable, but may possibly allow hard to trace bugs.
  • maybe we could use bower.json for this stuff? not sure if that's possible
  • if not bower, maybe we could create a composer plugin. i know it's possible to create a custom composer type.
@tsteur commented on October 3rd 2014 Member

bower.json is similar to composer.json only a manager for packages and would therefore only specify metadata for the package itself but not really specify any behavior or so :( Would love to find a very nice, intuitive / natural solution here. Like normally you would either include the files you want in an html file via link/script element or call a method in a framework like $this->getHead()->addStylesheet($file).

Had a look how other frameworks like Symfony handles it but it is not really comparable. Would have to find an application that does something similar that we do. Just another idea which might be stupid but sounds kinda natural. Not sure whether doable etc though. Maybe developers could place a file like templates/head.twig and include files via {{ asset() }} or {{ stylesheet('stylesheets/test.css') }} or {{ js('javascripts/file.js') }} or maybe naming could be better with link()/script(). Would be maybe more "natural / intuitive". To restrict assets the event could still be used and/or we could maybe also assign some default variables to this view like {% if hasSuperUserAccess %}{{js('')}}{% endif %}

@diosmosis commented on October 3rd 2014 Member

Here's the bit about a composer type in the docs: https://getcomposer.org/doc/04-schema.md#type

The sentence These types will all be specific to certain projects, and they will need to provide an installer capable of installing packages of that type. leads me to believe there's some possibility of automation. Maybe the 'installer' mentioned would be able to read custom properties in the composer.json and & automagically make things work? Perhaps instead of merging & minifying ALL JS/stylesheets for every plugin, each plugin has its own merged/minified assets and these assets are generated on composer install when the composer.json type is "piwik-plugin". What do you think?

I'm not sure if a solution that uses Twig should be used, since we're trying to move away from twig, but $this->getHead()->... could be made available for Plugin classes. Or maybe Controller classes... That would feel better than an event to me.

@tsteur commented on October 3rd 2014 Member

I'm a bit confused about composer since there is not really anything to be installed. I think something like this is rather interesting once we allow plugins to define to depend on other plugins and then install them via the Marketplace as well.

Compiling/minifying the assets after installation via composer could be done probably but this could be easily done in Piwik itself as well. Especially since one can also a plugin just by copying it there. I'm also not really sure whether we are actually using composer later or only the composer.json structure and file name to not having to define a plugin.json and a composer.json with duplicated data. (Maybe we will use composer internally instead of git submodules)

Good point re twig. We wanna get rid of it long term. In long term I wanna get rid of the Plugin class as well as there should be only metadata (no logic or whatsoever) and this metadata should be actually defined in composer.json. Maybe it can be still used for events in the future but we'll see when having DI etc ;)

Not sure if it is the controllers responsibility as well. Often a plugin does not even have a controller as it is not needed when defining a widget or a report. In core we have an AssetManager so maybe each plugin could have a class AssetManager as well and define all the js,less files there (which might depend on user permission etc). Could be a method like getJsFiles() and getStylesheetFiles() but not really convinced by this solution as well :(

@diosmosis commented on October 3rd 2014 Member

Quick comment: AssetManager component could be named Assets, would work well I think.

Maybe it's a bit early to think about this, there would be a lot of work in between here and something like this being implemented (at least via composer).

This Issue was closed on May 6th 2016
Powered by GitHub Issue Mirror