Recherche avancée

Sur d’autres sites (4277)

• Révision 22075 : Intégration dans SPIP de la possibilité de gérer des liens entre objets

  8 mai 2015, par marcimat ☺☮☯♫

  avec des rôles.

  On intègre l’API présente actuellement dans le plugin Rôles, en modifiant
  un peu les fonctions d’édition de liens.

  Celles-ci permettent maintenant d’éditer des liens ayant donc des rôles.
  Ces différents rôles et le nom de la colonne SQL qui les reçoit,
  s’ils sont utilisés, doivent être déclarés avec la déclaration
  de l’objet éditorial correspondant.

  Un exemple est donné avec le plugin « Roles auteurs » qui définit
  quelques rôles. Les champs décrivant les rôles : `roles_colonne`, `roles_titres` et `roles_objets`
  doivent être déclarés (via le pipeline declarer_tables_objets_sql).

  ```
  "roles_colonne" => "role",
  "roles_titres" => array(
  ’redacteur’ => ’info_statut_redacteur’,
  ’traducteur’ => ’roles_auteurs:traducteur’,
  ’correcteur’ => ’roles_auteurs:correcteur’,
  ’relecteur’ => ’roles_auteurs:relecteur’,
  ),
  "roles_objets" => array(
  ’articles’ => array(
  ’choix’ => array(’redacteur’, ’traducteur’, ’correcteur’, ’relecteur’),
  ’defaut’ => ’redacteur’
  )
  #’*’ => array()
  )
  ```

  Une fois déclaré, on peut appeler les fonctions d’édition de lien
  en transmettant des valeurs de rôles, tel que :

  ```
  objet_associer(
  array(’auteur’ => 3),
  array(’article’ => 11),
  array(’role’ => ’correcteur’)
  ) ;

  // utilisera le rôle par défaut
  objet_associer(
  array(’auteur’ => 3),
  array(’article’ => 11)
  ) ;
  ```

  Si aucun rôle n’est indiqué, le rôle par défaut est appliqué.

  Dans le cas d’une dissociation également, si aucun rôle n’est indiqué,
  seuls les liaisons avec le rôle par défaut seront supprimés ; pour
  supprimer tous les rôles, il faut à ce moment là indiquer ’*’ :

  ```
  objet_dissocier(
  array(’auteur’ => 3),
  array(’article’ => 11),
  array(’role’ => ’correcteur’)
  ) ;

  // utilisera le rôle par défaut
  objet_dissocier(
  array(’auteur’ => 3),
  array(’article’ => 11)
  ) ;

  // enlèvera tous les rôles
  objet_dissocier(
  array(’auteur’ => 3),
  array(’article’ => 11),
  array(’role’ => ’*’)
  ) ;
  ```

  Le formulaire d’édition de liens n’utilisera pas les mêmes squelettes
  de liaison lorsqu’une colonne de rôle est déclarée.

  Ainsi dans cet exemple, au lieu de `prive/objets/liste/auteurs_lies.html`
  et `auteurs_associer.html`, cela utiliserait `prive/objets/liste/auteurs_roles_lies.html`
  et `auteurs_roles_associer.html`. Il faut donc créer ces squelettes.

  Ces squelettes peuvent poster les valeurs au formulaire pour insérer
  de nouveaux liens, de la forme `qualifier_lien[auteur-3-article-11][role]`
  en postant `redacteur` par exemple.

  Il est possible au passage de poster en plus d’autres valeurs, qui seront
  intégrées dans l’enregistrement du lien.
  Ainsi, poster en même temps `qualifier_lien[auteur-3-article-11][valeur]` = `50`
  enregistrera la valeur 50 dans la colonne `valeur` de la table de lien (qui doit
  exister !).

  D’autres informations sont présentes dans http://contrib.spip.net/Des-roles-sur-des-liens,
  http://zone.spip.org/trac/spip-zone/browser/_plugins_/roles_auteurs ou encore
  http://zone.spip.org/trac/spip-zone/browser/_plugins_/roles

• nomenclature #3469 (Nouveau) : Étendre la balise #URL_PAGE à tout objet éditorial

  6 juin 2015, par tetue tetue

  La balise #URL_PAGE affiche actuellement la page fabriquée par le squelette passé en paramètre : http://www.spip.net/fr_article4630.html

  Cette balise pourrait être étendue aux objets éditoriaux de SPIP, de façon à être utilisée facilement, sans paramètre, pour lier explicitement la page SPIP, ce qui est utile pour les objets possédant par ailleurs une URL qui leur est propre, tel que les sites.

  #URL_PAGE afficherait l’url de la page dédiée à l’objet, c’est-à-dire la page générée via le squelette homonyme (sans nécessiter de le passer en paramètre), si ce skel existe, sinon rien.

  Par exemple :

  - dans une boucle SITES, #URL_PAGE afficherait l’url de la page fabriquée par le skel « site » — au lieu de l’actuel [(#ID_SYNDIC|generer_url_entitesite)] anciennement (#ID_SYNDIC, trop barbare — tandis que #URL_FORUM affiche l’url de la page où est affiché le message
  - dans une boucle DOCUMENTS, #URL_PAGE afficherait l’url de la page fabriquée par le skel « document », s’il existe, tandis que #URL_DOCUMENT affiche l’url du fichier multimédia
  - idem avec les FORUMS
  - dans une boucle SYNDIC_ARTICLES, #URL_PAGE n’afficherait rien, car le squelette « article_syndic » n’existe pas
  - dans une boucle ARTICLES, #URL_PAGE afficherait l’url de la page fabriquée par le skel « article », comme #URL_ARTICLE
  - etc.

  Il ne s’agit pas tant qu’une évolution, puisque l’affichage de toutes ces URLs est déjà possible, que d’une homogénéisation et simplification de la nomenclature. Mieux vaut écrire #URL_PAGE que [(#ID_SYNDIC|generer_url_entitesite)], n’est-ce pas ;)

• Revision 91480 : Suite de r90254 : les explications dans le constructeurs de formulaire ...

  26 août 2015, par marcimat@… — Log

  Suite de r90254 : les explications dans le constructeurs de formulaire avaient leurs boutons d’action mal affichés, de même que les onglets à l’intérieur.
  Devrait être plus fonctionnel maintenant. (Beno : ​http://contrib.spip.net/Champs-Extras-3#forum483400)