SPIP-Contrib

SPIP-Contrib

عربي | Deutsch | English | Español | français | italiano | Nederlands

290 Plugins, 198 contribs sur SPIP-Zone, 70 visiteurs en ce moment

Accueil > Outils pour plugins > Tutoriaux pour Plugins > Convention de nommage pour le code des plugins

Convention de nommage pour le code des plugins

30 mai 2007 (Date de rédaction antérieure : 27 mai 2007). – par NicolasR, support, toggg – commentaire

1 vote

Une proposition pour éviter les conflits de noms entre les actions de différents plugins.

ceci fait suite à une discussion sur irc le dimanche 27 mai 2007 à propos d’une recommandation manquante pour les plugins.

Constat : un espace de nommage unique

Un plugin peut fournir des execs et des actions. Peu de différences si ce n’est que l’un est privé et le second public (grosso modo). Ils partagent en tout cas une chose, c’est qu’ils sont basés sur une recherche d’un fichier exec/xxx.php ou action/xxx.php

Tout cela pour dire que ces « xxx » ne sont pas infinis (on appelle ça un espace de nommage unique). Donc, pitié ! Lorsque vous adoptez un nom pour une action ou un exec de votre plugin, veuillez assurer qu’il est assez particulier pour votre plugin.

Un exemple célèbre est « spip-listes » qui utilise ou utilisait exec=config. On peut croire que c’est la config générale de spip ? et bien non c’est juste celle de « spip-listes » ... Cette appropriation est une des raisons pour laquelle cfg s’appelle cfg et pas config.

Proposition de convention

La seule solution pratique est de préfixer le nom, par exemple, nous parlions avec BoOz de renommer ce spip-listes/exec/config.phpen
spip-listes/exec/sl_config.php ou spip-listes/exec/listes_config.php (en préfixant le nom de fichier donc). Ce qui donnerait ecrire/?exec=sl_config... etc.

Je donnerais aussi l’exemple de « spixplorer » dont toutes les actions sont des
spx_machin.

Idéalement, il faudrait meme utiliser le « prefix » du plugin, dont l’unicité est assurée, comme prefixage de tous les noms de fichiers de chaque plugin ainsi que le suggère Cédric. Evidemment, cela fait des noms à rallonge, mais ils faut savoir que ça n’est qu’interne, en général, ça correspond à un bouton à cliquer.

Ma proposition était même de réserver les noms très génériques au core de SPIP . Car je ne pense pas qu’une solution compliquée coté core fasse l’affaire. C’est très, très bien que les noms d’actions ou execs se limitent à un nom pour celui ci.

La suite

Débat sur le forum ci-dessous

P.-S.

Merci à Nicolasr d’avoir transformé cette discussion en convention.

Dernière modification de cette page le 30 mai 2007

Retour en haut de la page

Vos commentaires

  • Le 31 mai 2007 à 20:04, par cam.lafit En réponse à : Convention de nommage pour le code des plugins

    Bonjour

    Je serais assez d’accord pour donner en prefixe le nom complet du plugin.
    Cela donne peut etre un truc à rallonge mais c’est deja le cas pour les fonctions interne aux plugins.

    De plus pas de surprises à la lecture du exec/xxx.php . Car spx, ou bien sl ou listes c’est pas necessairement évident à deviner.

    Répondre à ce message

Répondre à cet article

Qui êtes-vous ?
  • [Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici Les choses à faire avant de poser une question (Prolégomènes aux rapports de bugs. )
Ajouter un document

Retour en haut de la page

Ça discute par ici

  • ScolaSPIP 4

    19 janvier 2016 – 361 commentaires

    ScolaSPIP est plugin-squelette responsive personnalisable pour sites Web d’établissements scolaires basé sur SPIPr Présentation de ScolaSPIP Ce plugin pour SPIP 3 est développé par la Dane de l’académie de Versailles pour les webmestres de cette (...)

  • Convertir un site SPIP 3 en utf-8 avec le plugin Grenier

    8 janvier 2014 – 23 commentaires

    SPIP 3 fonctionne nativement avec l’encodage universel unicode utf-8. Sur certains sites (par exemple sur une mise à jour), on peut avoir un site qui est resté en iso-latin ce qui n’est pas conseillé (source de bugs, d’incompatibilité, ...) . (...)

  • SPIP 3.2, Agenda et FullCalendar

    6 juin – 10 commentaires

    Nous avions publié un article sur la manière d’utiliser FullCalendar avec SPIP 3.0 afin d’afficher des évènements sous forme d’Agenda. La version de FullCalendar a changé avec SPIP 3.2. Le présent article est donc un tutoriel adapté à SPIP 3.2. Pour (...)

  • Mailsubscribers

    16 janvier 2013 – 408 commentaires

    Ce plugin permet de gérer les inscriptions (ou abonnements) à la diffusion de contenu par email. Mailsubscribers permet de gérer les inscriptions par Opt-in simple ou double et la désinscription par URL. Ce plugin gère également plusieurs listes de (...)

  • Nouvelle version - Modération de modifications

    29 janvier 2012 – 49 commentaires

    Suite à une migration depuis SPIP-Agora, j’ai développé ce plugin permettant de reprendre la fonctionnalité « Nouvelle version » inexistente sur SPIP2 ni sur SPIP3 Ce plugin permet d’étendre le work-flow de -rédaction-publication d’un article au cas d’un (...)