You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, global plugins are declared in a list (which is – by default – ordered). However, this is not the case for vocabulary-specific plugins, please see https://github.com/NatLibFi/Skosmos/wiki/Plugins#activating-plugins. This will cause trouble as I can not guarantee/change their respective execution order.
I think implementing this will request two kinds of changes to the code base:
Deprecate skosmos:usePlugin in favor of skosmos:usePlugins (the name can be different, that was just an example) that takes a list as a parameter
In case there are similarly named plugins in skosmos:usePlugins and skosmos:globalPlugins, use the order for them declared in skosmos:usePlugins. For a reasonable default order, it should be decided whether to append or prepend skosmos:globalPlugins plugins with skosmos:usePlugins in order to determine their respective execution order.
Alternatively, one could just add a specific skosmos:executionOrder/Priority value for each plugin. However, this would make it impossible to have plugins in different order in different vocabularies.
Regarding plugins: it would be better to require a true object relation instead of plain strings. This would enable us to mix parameterized plugins with 'normal' ones in the list. Actually, this way we could still use skosmos:usePlugin in the same clever way it is used in parameterized plugin and just shift its use from vocabulary level (deprecate it there) to plugin level.
The text was updated successfully, but these errors were encountered:
The pull request #1201 fixes this issue only partly. PluginRegister class loads plugins in alphabetical order and changes the order made by vocabularyConfig class and defined by skosmos:vocabularyPlugins in Skosmos configuration.
The order in which the plugins are loaded is actually not the same in which they are rendered to a concept page. Several NatLibFi's Skosmos widgets render the widget content after concept-info element in the concept page. This means that the last element in order will be the first element visible after concept info and the order is reverse of skosmos:vocabularyPlugins. It needs more planning to decide how the rendering of plugins could be done in the order listed in skosmos:vocabularyPlugins.
As said in the original issue notes the configuration property skosmos:usePlugin should be deprecated in future since skosmos:vocabularyPlugins does the same, but in a shorter manner. However, skosmos:useParamPlugin needs skosmos:usePlugin to define the name of the plugin it uses.
At the moment, global plugins are declared in a list (which is – by default – ordered). However, this is not the case for vocabulary-specific plugins, please see https://github.com/NatLibFi/Skosmos/wiki/Plugins#activating-plugins. This will cause trouble as I can not guarantee/change their respective execution order.
I think implementing this will request two kinds of changes to the code base:
skosmos:usePlugin
in favor ofskosmos:usePlugins
(the name can be different, that was just an example) that takes a list as a parameterskosmos:usePlugins
andskosmos:globalPlugins
, use the order for them declared inskosmos:usePlugins
. For a reasonable default order, it should be decided whether to append or prependskosmos:globalPlugins
plugins withskosmos:usePlugins
in order to determine their respective execution order.Alternatively, one could just add a specific
skosmos:executionOrder/Priority
value for each plugin. However, this would make it impossible to have plugins in different order in different vocabularies.Regarding plugins: it would be better to require a true object relation instead of plain strings. This would enable us to mix parameterized plugins with 'normal' ones in the list. Actually, this way we could still use
skosmos:usePlugin
in the same clever way it is used in parameterized plugin and just shift its use from vocabulary level (deprecate it there) to plugin level.The text was updated successfully, but these errors were encountered: