Métadonnées dans la déclaration des plugins/thèmes

[bruno]

Si on veut étendre les fonctionnalités des thèmes, on n'a aujourd'hui pas vraiment d'autre choix que d'ajouter un attribut à dcModule::registerModule(). Cela force à saisir tous les paramètres optionnels avant ce nouveau paramètre, ce qui est moche.

Je propose de passer un tableau de paramètres plutôt que d'ajouter sans cesse des paramètres, afin d'avoir quelque chose de plus évolutif.

Ancienne méthode :

public function registerModule($name,$desc,$author,$version,$permissions=null,$priority=1000)

Nouvelle méthode :

public function registerModule($name,$desc,$author,$version,$permissions=null,$priority=1000,$properties=array())

Idéalement, je mettrais bien $permissions et $priority dans $properties, mais il faut voir comment gérer les modules déjà existants... peut-être en jouant du func_get_args...

[bruno]

pour approfondir, voici les propriétés qui pourraient voir le jour :

• set de templates par défaut (voir #1216)
• introduction de dépendances entre plugins, par exemple
• fichiers d'aide internationalisés
• descriptif du plugin (pour gestion automatique via dotaddict par exemple)
• ...

[bruno]

(j'aime les monologues :)

C'est donc réalisable de manière plus propre.

Futur prototype :

public function registerModule($name,$desc,$author,$version,$properties=array())

si properties n'est pas un tableau, on parse les arguments "comme avant", sinon on récupère$priority et $permissions directement depuis $propertiespriority? et $propertiespermissions?.

[Dsls <dsls@…>]

(In [e6b2db1d228a]) * New way of registering modules/themes, more extensible (backward compatible with previous method)

• small fix on attachments plugin template tags

Closes #1223.