[SPIP Zone] [Spip-zone-commit] r84174 - in _plugins_/pages/trunk détraque le NoiZetier

Archives Zone
1

Bonjour,

Rahhh... Pas bon cette création de
_plugins_/pages/trunk/prive/squelettes/contenu/pages.html
pour l'espace privé !

Ca surcharge la page du Noizetier qui a la même url...
Donc impossible d'éditer les noisettes !

Déjà "Pages uniques" n'était pas très explicite (j'ai mis longtemps avant de le découvrir), mais si l'on réduit encore à "Pages", ça va semer la pagaille...

Articles_orphelins ou Articles_libres serait plus explicite...

Donc que fait-on donc avec ces conflits de plugins ?

Le 12/08/2014 19:25, eric@smellup.net a écrit :

Author: eric@smellup.net
Date: 2014-08-12 19:25:38 +0200 (Tue, 12 Aug 2014)
New Revision: 84174

Added:
    _plugins_/pages/trunk/pages_autorisations.php
    _plugins_/pages/trunk/prive/squelettes/contenu/pages.html
Removed:
    _plugins_/pages/trunk/prive/squelettes/contenu/pages_tous.html
    _plugins_/pages/trunk/prive/squelettes/navigation/
Modified:
    _plugins_/pages/trunk/pages_administrations.php
    _plugins_/pages/trunk/pages_pipelines.php
    _plugins_/pages/trunk/paquet.xml
Log:
Evolutions du plugin dont certaines peuvent être considérées comme des corrections:
- la page pages_tous devient pages ce qui est plus cohérent avec les autres objets.
- ajout et utilisation des autorisations classiques pour un obet 'page' : creer, modifier et voir. Ces autorisations et les suivantes sont par défaut positionnées à admin complet. Une fonction surchargeable permet de toutes les modifier d'un coup.
- ajout de l'autorisation pages_voir pour afficher la liste des pages uniques (exec=pages)
- ajout des autorisations d'affichage des menus pages et pagecreer. Ces autorisations font appel respectivement à pages_voir et page_creer.
- utilisation du pipeline pre_boucle sur la boucle ARTICLES afin de clairement séparer les listes de pages uniques et celles d'articles éditoriaux. Par exemple, les listes d'articles de la page d'acceuil et de la page articles sont exemptes de pages uniques.

Tout n'est pas parfait en particulier pour les autorisations car il est toujours possible d'accéder à une page unique en saisissant l'url même si on est pas autorisé. C'est en effet l'autorisation de l'article qui se déroule. Pour combler ce manque il faudrait surcharger l'autorisation de l'article en testant l'id de rubrique mais cela produirait des effets de bords avec d'autres plugins comme accès restreint.
En fait, spécialiser un objet pour en créer un autre n'est pas une opération prévue dans l'api SPIP actuelle.

Autre remarque : lors de la désinstallation du plugin on supprime la colonne 'page' de la table spip_articles. On se retrouve avec des articles possédant un id_rubrique à -1. Est-ce bien de laisser cela ainsi ? Ne faudrait-il pas soit les supprimer soit les transférer dans une rubrique existante ?

Details: Connexion · GitLab

_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net

2

Bonjour,

Pourquoi ça ne serait pas au Noizetier de changer "?exec=pages" en "?exec=configurer_pages" ? ou "?exec=noisettes_pages" ? ou "?exec=noizetier_pages" ? ou "?exec=noizetier_liste_pages" ? cf. Connexion · GitLab

:slight_smile:

Le 25 août 2014 à 20:09, Stéphane Santon <m.spiprezo@team-santonum.com> a écrit :

Bonjour,

Rahhh... Pas bon cette création de
_plugins_/pages/trunk/prive/squelettes/contenu/pages.html
pour l'espace privé !

Ca surcharge la page du Noizetier qui a la même url...
Donc impossible d'éditer les noisettes !

Déjà "Pages uniques" n'était pas très explicite (j'ai mis longtemps avant de le découvrir), mais si l'on réduit encore à "Pages", ça va semer la pagaille...

Articles_orphelins ou Articles_libres serait plus explicite...

Donc que fait-on donc avec ces conflits de plugins ?

Le 12/08/2014 19:25, eric@smellup.net a écrit :

Author: eric@smellup.net
Date: 2014-08-12 19:25:38 +0200 (Tue, 12 Aug 2014)
New Revision: 84174

Added:
   _plugins_/pages/trunk/pages_autorisations.php
   _plugins_/pages/trunk/prive/squelettes/contenu/pages.html
Removed:
   _plugins_/pages/trunk/prive/squelettes/contenu/pages_tous.html
   _plugins_/pages/trunk/prive/squelettes/navigation/
Modified:
   _plugins_/pages/trunk/pages_administrations.php
   _plugins_/pages/trunk/pages_pipelines.php
   _plugins_/pages/trunk/paquet.xml
Log:
Evolutions du plugin dont certaines peuvent être considérées comme des corrections:
- la page pages_tous devient pages ce qui est plus cohérent avec les autres objets.
- ajout et utilisation des autorisations classiques pour un obet 'page' : creer, modifier et voir. Ces autorisations et les suivantes sont par défaut positionnées à admin complet. Une fonction surchargeable permet de toutes les modifier d'un coup.
- ajout de l'autorisation pages_voir pour afficher la liste des pages uniques (exec=pages)
- ajout des autorisations d'affichage des menus pages et pagecreer. Ces autorisations font appel respectivement à pages_voir et page_creer.
- utilisation du pipeline pre_boucle sur la boucle ARTICLES afin de clairement séparer les listes de pages uniques et celles d'articles éditoriaux. Par exemple, les listes d'articles de la page d'acceuil et de la page articles sont exemptes de pages uniques.

Tout n'est pas parfait en particulier pour les autorisations car il est toujours possible d'accéder à une page unique en saisissant l'url même si on est pas autorisé. C'est en effet l'autorisation de l'article qui se déroule. Pour combler ce manque il faudrait surcharger l'autorisation de l'article en testant l'id de rubrique mais cela produirait des effets de bords avec d'autres plugins comme accès restreint.
En fait, spécialiser un objet pour en créer un autre n'est pas une opération prévue dans l'api SPIP actuelle.

Autre remarque : lors de la désinstallation du plugin on supprime la colonne 'page' de la table spip_articles. On se retrouve avec des articles possédant un id_rubrique à -1. Est-ce bien de laisser cela ainsi ? Ne faudrait-il pas soit les supprimer soit les transférer dans une rubrique existante ?

Details: Connexion · GitLab

_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net
_______________________________________________
Spip-zone-commit@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone-commit

3

Le 25/08/2014 20:19, Ybbet SPIP a écrit :

Bonjour,

Pourquoi ça ne serait pas au Noizetier de changer "?exec=pages" en "?exec=configurer_pages" ? ou "?exec=noisettes_pages" ? ou "?exec=noizetier_pages" ? ou "?exec=noizetier_liste_pages" ? cf. Connexion · GitLab

:slight_smile:

Pourquoi pas, je ne maîtrise pas assez les conventions de nommages autour des objets et plugins Spip3 pour définir qui "doit" changer.

Peut-être les deux devraient-ils clarifier et uniformiser ??

Le 25 août 2014 à 20:09, Stéphane Santon <m.spiprezo@team-santonum.com> a écrit :

Bonjour,

Rahhh... Pas bon cette création de
_plugins_/pages/trunk/prive/squelettes/contenu/pages.html
pour l'espace privé !

Ca surcharge la page du Noizetier qui a la même url...
Donc impossible d'éditer les noisettes !

Déjà "Pages uniques" n'était pas très explicite (j'ai mis longtemps avant de le découvrir), mais si l'on réduit encore à "Pages", ça va semer la pagaille...

Articles_orphelins ou Articles_libres serait plus explicite...

Donc que fait-on donc avec ces conflits de plugins ?

Le 12/08/2014 19:25, eric@smellup.net a écrit :

Author: eric@smellup.net
Date: 2014-08-12 19:25:38 +0200 (Tue, 12 Aug 2014)
New Revision: 84174

Added:
    _plugins_/pages/trunk/pages_autorisations.php
    _plugins_/pages/trunk/prive/squelettes/contenu/pages.html
Removed:
    _plugins_/pages/trunk/prive/squelettes/contenu/pages_tous.html
    _plugins_/pages/trunk/prive/squelettes/navigation/
Modified:
    _plugins_/pages/trunk/pages_administrations.php
    _plugins_/pages/trunk/pages_pipelines.php
    _plugins_/pages/trunk/paquet.xml
Log:
Evolutions du plugin dont certaines peuvent être considérées comme des corrections:
- la page pages_tous devient pages ce qui est plus cohérent avec les autres objets.
- ajout et utilisation des autorisations classiques pour un obet 'page' : creer, modifier et voir. Ces autorisations et les suivantes sont par défaut positionnées à admin complet. Une fonction surchargeable permet de toutes les modifier d'un coup.
- ajout de l'autorisation pages_voir pour afficher la liste des pages uniques (exec=pages)
- ajout des autorisations d'affichage des menus pages et pagecreer. Ces autorisations font appel respectivement à pages_voir et page_creer.
- utilisation du pipeline pre_boucle sur la boucle ARTICLES afin de clairement séparer les listes de pages uniques et celles d'articles éditoriaux. Par exemple, les listes d'articles de la page d'acceuil et de la page articles sont exemptes de pages uniques.

Tout n'est pas parfait en particulier pour les autorisations car il est toujours possible d'accéder à une page unique en saisissant l'url même si on est pas autorisé. C'est en effet l'autorisation de l'article qui se déroule. Pour combler ce manque il faudrait surcharger l'autorisation de l'article en testant l'id de rubrique mais cela produirait des effets de bords avec d'autres plugins comme accès restreint.
En fait, spécialiser un objet pour en créer un autre n'est pas une opération prévue dans l'api SPIP actuelle.

Autre remarque : lors de la désinstallation du plugin on supprime la colonne 'page' de la table spip_articles. On se retrouve avec des articles possédant un id_rubrique à -1. Est-ce bien de laisser cela ainsi ? Ne faudrait-il pas soit les supprimer soit les transférer dans une rubrique existante ?

Details: Connexion · GitLab

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net

4

Bonjour,

Dans le coup, sur ma mutu, j'ai supprimé Pages 1.2, il reste Pages 1.1 mais qui est marqué obsolète, pas de bouton "Activer".
Comment forcer cette activation ?

Le 25/08/2014 20:09, Stéphane Santon a écrit :

Rahhh... Pas bon cette création de
_plugins_/pages/trunk/prive/squelettes/contenu/pages.html
pour l'espace privé !

Ca surcharge la page du Noizetier qui a la même url...
Donc impossible d'éditer les noisettes !

Déjà "Pages uniques" n'était pas très explicite (j'ai mis longtemps
avant de le découvrir), mais si l'on réduit encore à "Pages", ça va
semer la pagaille...

Articles_orphelins ou Articles_libres serait plus explicite...

Donc que fait-on donc avec ces conflits de plugins ?

Le 12/08/2014 19:25, eric@smellup.net a écrit :

Author: eric@smellup.net
Date: 2014-08-12 19:25:38 +0200 (Tue, 12 Aug 2014)
New Revision: 84174

Added:
    _plugins_/pages/trunk/pages_autorisations.php
    _plugins_/pages/trunk/prive/squelettes/contenu/pages.html

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net

5

Hello,

Un objet du nom « objet » a une page liste des objets qui s’appelle « objets ». Donc l’objet s’appelant « page » (c’est pas moi qui ait choisi ce nom) la liste des pages est donc sur l’url ?page=pages.

Donc je pense que c’est plutôt le NoiZetier qui devrait éviter d’utiliser des url aussi génériques et qui ne représentent pas vraiment les actions qui y sont réalisables.
.

Je pense que ce n’est pas un gros changement pour Joseph.

Après pour le nommage Pges et Pages uniques je pense que tu confonds l’url, l’objet et le nom du plugin.

6

C’est une option dans la configuration de SVP.

7

Ah super, c'est bon à savoir... Merci :slight_smile:

Entre temps j'avais réussi à l'activer en copiant le code html du bouton [Activer] dans firebug...

Le 25/08/2014 21:01, Eric a écrit :

C'est une option dans la configuration de SVP.

Le 25 août 2014 20:51, Stéphane Santon <m.spiprezo@team-santonum.com
<mailto:m.spiprezo@team-santonum.com>> a écrit :

    Bonjour,

    Dans le coup, sur ma mutu, j'ai supprimé Pages 1.2, il reste Pages
    1.1 mais qui est marqué obsolète, pas de bouton "Activer".
    Comment forcer cette activation ?

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net

8

Le 25/08/2014 20:57, Eric a écrit :

Hello,

Un objet du nom "objet" a une page liste des objets qui s'appelle
"objets". Donc l'objet s'appelant "page" (c'est pas moi qui ait choisi
ce nom) la liste des pages est donc sur l'url ?page=pages.

OK.
Mais en l’occurrence, dans le plugin "Pages", aucun objet éditorial n'est créé en base : les "Pages" sont simplement des *articles* sans rubrique (avec un id_rubrique à -1) ; juste un champ texte "Page" supplémentaire dans la table spip_articles pour les identifier.

Donc je pense que c'est plutôt le NoiZetier qui devrait éviter
d'utiliser des url aussi génériques et qui ne représentent pas vraiment
les actions qui y sont réalisables.
.
Je pense que ce n'est pas un gros changement pour Joseph.

Je crois que les deux sont à modifier :

- ?exec=pages n'est pas assez explicite pour le NoiZetier, ?exec=noizetier_pages ne paraît plus approprié (mais on peut trouver mieux);

- ?exec=articles_libres serait plus explicite sur un plugin "Pages" qui pourrait s'appeler "Articles libres"

a++

Après pour le nommage Pges et Pages uniques je pense que tu confonds
l'url, l'objet et le nom du plugin.

++
Eric

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net

9

Je ne suis pas convaincu.

L’objet page se base sur des articles pour éviter de créer un nouvel objet qui ressemblerait à un article. Donc on réutilise l’objet article mais pour moi ce n’est en rien un article éditorial. Retrouver le terme article ne me parait pas plus clair, bien au contraire.

10

Le 25 août 2014 22:02, Charles Razack <tcharlss@hotmail.fr> a écrit :

Hello, je rajoute mes 2 centimes :

A strictement parler, l'URL ?exec=pages devrait amener sur une page qui
affiche la liste des objets éditoriaux « page », mais ce n'est le cas pour
aucun des 2 plugins. Et à ma connaissance, aucun plugin de la zone ne
fournit d'objet éditorial « page ».

Ben si c'est bien l'objet du plugin Pages Uniques justement, c'est ce que
je viens de dire dans mon mail précédent.

Techniquement, ce que le plugin appelle une page, c'est un article : ça
utilise le même formulaire, c'est enregistré dans la même table. Bref, je
ne vois pas le problème avec ?exec=articles_libres

Ce n'est pas un article que l'on veut obtenir. On ne fait qu'utiliser les
articles comme réceptacles pour ne pas redévelopper un objet similaire. On
voit d'ailleurs que ce n'est pas à la longue forcément une bonne idée. Mais
à ce propos ce n'est pas le nom le problème principal.

++
Eric

11

PS : Je me permets d’insister car justement, ce terme de «page» est employé avec plusieurs sens différents entre la documentation de SPIP et les 2 plugins cités. Ça porte à confusion à la fois pour les utilisateurs et pour les développeurs. C’est peut-être l’occasion d’accorder les violons, et d’utiliser ce terme de «page» de façon plus rigoureuse, en accord avec la doc officielle de SPIP. Et donc partant de là, il faudrait réserver ?exec=pages à un plugin qui listerait les pages, telles qu’on les entend dans la doc.

Ou alors, on peut se dire aussi qu’on réserve des mots (namespace) pour SPIP et qu’on ne les utilise pas dans un quelconque plugin.
« Page » serait réservé à l’usage propre de SPIP.

12

Le 25 août 2014 23:39, Charles Razack <tcharlss@hotmail.fr> a écrit :

Le 25/08/2014 22:44, Eric a écrit :

Je comprends bien les intentions des pages uniques, qu'une "page" n'est
pas censée être un article éditorial tout ça, mais au final le plugin
n'ajoute pas de nouvel objet éditorial. Il s'agit bien d'articles en bonne
et dûe forme *présentés* comme autre chose, ça ne me semble pas suffisant
pour les qualifier de nouveaux objets.

Ben si, c'est pas le "comment on fait" qui détermine l'objectif, le "quoi".
Ce que l'on veut créer c'est un nouvel objet, peu importe comment il est
implémenté.
Donc oui on est en présence d'un nouvel objet.
Après a-t-il un nom adapté c'est une autre histoire dont je ne suis pas
l'auteur.

De plus, le plugin utilise le terme «page» avec un sens différent de celui
utilisé dans la documentation de SPIP, ce qui porte à confusion.
J'utilise le plugin sans souci, mais maintenant que Stéphane a soulevé la
question, après réflexion effectivement je trouve que ces choix peuvent
poser problème

Si je voulais créer un objet livre contenant des objets pages il faudrait
que je l'appelle différemment parce que les pages web portent déjà ce nom ?
Je ne pense pas surtout qu'on ne parle pas de choses comparables : d'un
coté c'est un objet de l'autre un élément d'un site web.
Donc ce n'est pas pour moi un argument pour dire que ce terme page n'est
pas utilisable.

Maintenant tout cela ce sont des considérations intellectuelles, on peut
remettre un nom de page différent si besoin (mais ça serait bien aussi de
le faire dans le noisetier).
Je le répète, l'utilisation des articles pour implémenter un nouveau type
d'objet pose d'autres soucis plus épineux que le nom (le préfixe du plugin
se nomme "pages" à propos).
Ca prouve aussi que comme souvent utiliser un terme générique pour un
plugin ou autre est parfois périlleux et contre-productif.

++
Eric

13

Le 26/08/2014 15:34, Eric a écrit :

Ca prouve aussi que comme souvent utiliser un terme générique pour un
plugin ou autre est parfois périlleux et contre-productif.

Le nom du plugin et le nom des boutons dans l'interface c'est encore autre chose.

À la limite le nom du plugin, tu peux inventer un nom bidon, mais dans l'interface tu es bien obligé de mettre des termes génériques et compréhensibles par tout le monde. Si ton plugin fait des menus, dans l'interface tu auras "Créer un menu" et l'objet s'appellera assez logiquement "menu" aussi. Du coup, si on part du principe que l'on doit au maximum éviter les doublons, je ne vois pas l'intérêt à ce que le nom du plugin (qui lui peut être n'importe quoi) soit autre chose que le même nom compréhensible, au lieu d'un truc inventé. Sinon c'est la stratégie de l'échec : "Rangez les comptes courants dans le dossier Antilope"…

Par ailleurs, le nom "pages" n'est pas choisi au hasard, il est calqué peu ou prou à ce qui existe dans Wordpress : des pages quelconques, indépendantes des autres articles du site. C'est donc un terme relativement connu pour ce genre d'usage (oui, WP est connu).

J'ajoute enfin que le but principal du plugin est d'avoir une gestion éditoriale (titre, texte, etc) pour des *pages* du site qui n'ont aucun rapport avec le système de classement rubrique/article. Or, avec les utilisateurs finaux, c'est très exactement ce terme de "page" que l'on a toujours utilisé pour communiquer et en parler : la PAGE de contact, la PAGE de mentions légales, etc. En ce qui me concerne, le terme est donc assez bien choisi et les admins à qui j'ai dû l'expliquer ont bien compris de quoi il s'agissait.

--
RastaPopoulos

14

Ben oui mais je pige pas pourquoi tu me réponds ça car je suis tout à fait d’accord avec le terme Page et Pages Uniques pour le plugin. C’est ce que je défends depuis le début du thread.

Ma remarque dans ce cas précis s’adressait au plugin Noizetier plutôt.

15

Le 26/08/2014 15:57, RastaPopoulos a écrit :

Le nom du plugin et le nom des boutons dans l'interface c'est encore autre chose.

À la limite le nom du plugin, tu peux inventer un nom bidon, mais dans l'interface tu es bien obligé de mettre des termes génériques et compréhensibles par tout le monde. Si ton plugin fait des menus, dans l'interface tu auras "Créer un menu" et l'objet s'appellera assez logiquement "menu" aussi. Du coup, si on part du principe que l'on doit au maximum éviter les doublons, je ne vois pas l'intérêt à ce que le nom du plugin (qui lui peut être n'importe quoi) soit autre chose que le même nom compréhensible, au lieu d'un truc inventé. Sinon c'est la stratégie de l'échec : "Rangez les comptes courants dans le dossier Antilope"…

Par ailleurs, le nom "pages" n'est pas choisi au hasard, il est calqué peu ou prou à ce qui existe dans Wordpress : des pages quelconques, indépendantes des autres articles du site. C'est donc un terme relativement connu pour ce genre d'usage (oui, WP est connu).

J'ajoute enfin que le but principal du plugin est d'avoir une gestion éditoriale (titre, texte, etc) pour des *pages* du site qui n'ont aucun rapport avec le système de classement rubrique/article. Or, avec les utilisateurs finaux, c'est très exactement ce terme de "page" que l'on a toujours utilisé pour communiquer et en parler : la PAGE de contact, la PAGE de mentions légales, etc. En ce qui me concerne, le terme est donc assez bien choisi et les admins à qui j'ai dû l'expliquer ont bien compris de quoi il s'agissait.

Si on présuppose que ces «articles libres» sont destinés à être utilisés dans des pages uniques du site, appeler ces articles «pages uniques» a du sens.
Mais dès qu'on sort de cet usage, le terme porte question.

Qu'est-ce qui m'empêche de placer plusieurs articles libres dans une même page unique ? On sort déjà du cadre 1 article libre = 1 page unique.
Qu'est-ce qui m'empêche de plus d'utiliser ces articles libres en dehors de pages uniques, dans les squelettes des pages "normales" ?
Ces cas d'utilisation me semblent tout à fait légitimes. Je peux avoir par exemple besoin d'afficher des C.G.U et/ou des mentions légales en plusieurs endroits du site, au milieu de pages "normales" et pas forcément dans une page à part.
Il me semble moins restrictif d'appeler ces objets pour ce qu'ils sont : des articles libres (par exemple), plutôt que pour leur usage supposé : des pages uniques.

Bon, j'argumente pour le sport et pour procrastiner, je n'appelle pas à changer le nom du plugin ni rien. Je pose mes questions au gouvernement.

Sinon pour revenir au sujet de départ, une solution qui me semble appropriée serait que les 2 plugins suffixent ?exec=pages en fonction de ce que qu'ils entendent par «page» :
- ?exec=pages_uniques
- ?exec=pages_noizetier

16

Bonjour à tous,

désolé de répondre tardivement. Je viens seulement de voir ce fil de discussion.

En premier lieu, je n’ai pas d’objection à ce qu’il y ait un changement de nom dans le noizetier. Le terme de « pages » avait été choisi en référence au modèle conceptuel de Zpip où on a des types de pages (articles, rubriques, …), le terme squelette s’avérant inadapté car les pages sont construites à partir d’une multitude de squelettes.

Par ailleurs, pour répondre à une des questions posées plus haut, le noizetier permet de créer des « pages », on a bien deux squelettes dans le privé : un squelette pages.html et un squelette page.html.

Ceci étant posé, il est vrai que le terme de page est très générique d’où des problèmes de conflit. Si j’ai bien compris, dans la dic, le terme de page fait référence à la page web terminale. Autrement dit, la page de l’article 12 est différentes de la page de l’article 14. Or au sens du noizetier c’est la « même page » au sens où le noizetier gère des « types de page » (une page de type article, ou article-agenda, ou rubriques, etc.). Un « type » de page peut très bien ne concerner qu’une seule page web (il est possible de faire une page contact ou une page d’accueil, ou une page mentions légales…). Sur ce dernier point, on peut en effet, tout comme avec pages uniques, créer des pages web directement, même si c’est une fonctionalité secondaire du noizetier.

Il me semble qu’une porte de sortie pour les deux plugins et de qualifier le terme de page, le rendant ainsi moins générique.

Pour le noizetier, je peux proposer de parler de « types de pages » ou de « pages types » ou de « modèles de page ». Quelle expression vous semble la plus explicite ?

Pour « pages uniques », il me semble qu’il ne faut pas chercher midi à 14h et juste utiliser systématiquement l’adjectif « uniques » en conjonction avec le terme de « pages ». C’est le nom du plugin et toutes les entrées de menu font bien référence à « pages uniques ».

Est-ce qu’une telle solution semble convenable à tous ?

17

Le 25 août 2014 à 20:09, Stéphane Santon <m.spiprezo@team-santonum.com> a écrit :

Bonjour,

Rahhh... Pas bon cette création de
_plugins_/pages/trunk/prive/squelettes/contenu/pages.html
pour l'espace privé !

Ca surcharge la page du Noizetier qui a la même url...
Donc impossible d'éditer les noisettes !

Déjà "Pages uniques" n'était pas très explicite (j'ai mis longtemps avant de le découvrir), mais si l'on réduit encore à "Pages", ça va semer la pagaille...

Articles_orphelins ou Articles_libres serait plus explicite...

Je plussoie, vue les confusions côté utilisateur.

Le libellé « pages uniques » n'est pas explicite :

- d'une part c'est pléonasmique, une page, dans un livre par exemple, étant toujours unique
- de plus ça ne correspond pas à la réalité désignée : le qualificatif « orphelines » serait plus adéquat

-- tetue

18

Le 25 août 2014 à 23:58, Charles Razack <tcharlss@hotmail.fr> a écrit :

Le 25/08/2014 23:39, Charles Razack a écrit :

Je me permets d'insister car justement, ce terme de «page» est employé avec plusieurs sens différents entre la documentation de SPIP et les 2 plugins cités. Ça porte à confusion à la fois pour les utilisateurs et pour les développeurs.
C'est peut-être l'occasion d'accorder les violons, et d'utiliser ce terme de «page» de façon plus rigoureuse, en accord avec la doc officielle de SPIP.
Et donc partant de là, il faudrait réserver ?exec=pages à un plugin qui listerait les pages, telles qu'on les entend dans la doc.

Sur le Web, le terme « page » peut désigner des réalités différentes. C'est fonction du contexte dans lequel le terme « page » est employé :

1) d'une façon générale, la « page » web = le document web, unique (comme la page d'un livre), identifiée par son URL (comme les pages d'un livre par leur numéro).

Rapporté à SPIP : un squelette est le gabarit servant à fabriquer N pages. On peut dire qu'il y a correspondance entre page et article (mais pas entre page et squelette) parce qu'en général, à chaque article SPIP correspond une page du site (sans que la réciproque soit vraie).

2) dans un contexte graphique, « page » désigne, non plus le document web unique, mais son affichage, dans ses limites spatiales (comme la page arrachée d'un livre), par opposition à l'écran, la fenêtre et aux éléments qui la composent : entête, blocs, éléments, etc. Il est ici question de « mise en page », de composition.

Rapporté à SPIP : c'est en ce sens qu'il y a parfois confusion, à tort, entre page et squelette ?
Exemple : dans le dossier squelettes, un répertoire « /pages » contiendra (non pas les N pages du site public), mais les squelettes servant à fabriquer les pages complètes, par opposition aux répertoires « /inclure », etc. qui en contiennent des morceaux.

Les notions de « squelette » et de « page » (de même : d'« inclure », de « modèles » et de « bloc »), doivent rester distinctes car il n'y a pas toujours, voire rarement, coïncidence entre elles en pratique. C'est là qu'intervient la notion de « type de page », qui ne désigne pas une réalité technique (≠ squelette) mais un ensemble de « mises en page qui se ressemblent » (à l'appréciation du designer et/ou du commanditaire et/ou…). Si bien que :
- un squelette peut générer plusieurs types de page différents
- un type de page peut être généré par des squelettes différents
Et c'est la vie :slight_smile:

Pour vulgariser et aider à la compréhension globale, on peut parfois dire que c'est équivalent.
Mais dans une doc technique, dans la nomenclature logicielle, la rigueur prévaut.

-- tetue

19

Bonjour,

Le 27/08/2014 16:45, Joseph a écrit :

En premier lieu, je n'ai pas d'objection à ce qu'il y ait un changement
de nom dans le noizetier. Le terme de "pages" avait été choisi en
référence au modèle conceptuel de Zpip où on a des types de pages
(articles, rubriques, ...), le terme squelette s'avérant inadapté car
les pages sont construites à partir d'une multitude de squelettes.

Par ailleurs, pour répondre à une des questions posées plus haut, le
noizetier permet de créer des "pages", on a bien deux squelettes dans
le privé : un squelette pages.html et un squelette page.html.

Ceci étant posé, il est vrai que le terme de page est très générique
d'où des problèmes de conflit. Si j'ai bien compris, dans la dic, le
terme de page fait référence à la page web terminale. Autrement dit, la
page de l'article 12 est différentes de la page de l'article 14. Or au
sens du noizetier c'est la "même page" au sens où le noizetier gère des
"types de page" (une page de type article, ou article-agenda, ou
rubriques, etc.). Un "type" de page peut très bien ne concerner qu'une
seule page web (il est possible de faire une page contact ou une page
d'accueil, ou une page mentions légales...). Sur ce dernier point, on
peut en effet, tout comme avec pages uniques, créer des pages web
directement, même si c'est une fonctionalité secondaire du noizetier.

Il me semble qu'une porte de sortie pour les deux plugins et de
qualifier le terme de page, le rendant ainsi moins générique.

Pour le noizetier, je peux proposer de parler de "types de pages" ou de
"pages types" ou de "modèles de page". Quelle expression vous semble la
plus explicite ?

Les "Pages" (article, rubrique, sommaire, ...) définies dans le noizetier, définissant les /structures/ des différentes pages distinctes (article1, article2, rubrique3, ...), et étant constituées de différents squelettes, ne pourrait-on utiliser dans NoiZetier le terme de *"Gabarit"* (que je n'ai jamais entendu chez Spip) sur lesquels sont générées les différentes pages ?

Gabarit des articles
Gabarit des rubriques
Gabarit de la page sommaire
...

Juste un terme qui me trottait dans la tête...

--
Stéphane

Les Voisins Spipeurs : http://www.voisins-spipeurs.net

20

Gabarits est déjà utilisé : http://contrib.spip.net/Gabarits