RE: [spip-dev] SPIP, l'expertise et la validation

hello,

Dites, l'assoiffé de polémiques que je suis ";-)" sature un peu...
J'ai parfois l'impression d'être retourné à l'école maternelle (ou là ça fait pas loin de 30 ans ça....) : "mon Xhtml il est plus beau que le tien na na na nèreheuuuuuu" - "moi le W3C il m'a dit que j'éatais mieux que toi la la la lère heu" - " le W3C il est nul" etc... Pffff : ça fait super avancer le schmilblik.

Non mais sans rire on pourrait pas élever le débat de quelques centimètres et revenir à des choses sérieuses non ?
Oui j'utilise Spip depuis 3 ou 4 ans, oui j'ai suivi de près Agora (certaines fonctionnalités me semblent essentielles et je suis sûr que spip y viendra : c'est d'ailleur le meilleur moyen de faire converger les deux produits, chose inévitable à moyen terme, ou bien l'un des deux s'effondrera) et oui je continue de fonctionner avec Spip : tant qu'agora n'aura pas viré son Pear à la noix qui fait que l'installation est compliquée et que le produit est lent... Par contre j'aimerai aussi que les dev de spip soit un peu plus ouverts et fasse aussi des concessions, il y a des fonctionnalités qui sont demandées sur les listes depuis des années, et c'est Agora qui les implémente d'emblée : forcément ça en met un coup...

Arrêtons un peu les gamineries et si provocation il y a, peut-être que certaines affirmations sont fausses, eh bien il faut les laisser passer, car de toutes façon on ne berne l'utilisateur que jusqu'aà un certain point, celui-ci une fois qu'il a passé quelques heures à étuider un pdt, se fait très vite une opinion.

A bon entendeur : salut !

Sinon il y a moyen de créer une liste : Tar ta gueule à la récré : ou le combat des titans : Agora - Spip : :wink:

A+

Jean-Luc GRELLIER
Chargé de Mission TIC
Courriel : jl-grellier@cr-limousin.fr
Tél : 05 55 45 18 96
Fax : 05 55 45 17 48
Région Limousin
27 Bd de la Corderie
87031 Limoges cedex

-----Message d'origine-----

Là .. j'm'étais dis que j'arrétais de suivre ce meta-troll-récursif,
mais je craque :

  Une bonne fois pour toute, donnez moi des exemples de trucs
implémentés par agora et réclamés «depuis des années» dans spip.
  Car c'est facile de sortir des phrases comme ça. Aussi facile que de
dire qu'agora est plus *compliant que spip, mais si on parlait de cas
précis, concrets, histoire de voir pourquoi les utilisateurs de spip
en sont outrageusement privés.

  On pourra alors voir si ces fonctinnalités si révolutionnaires :
- sont vraiment réclamées (si oui, les archives doivent y faire des
  références à la pelle)
- sont pas implémentables par une contrib
- seront utilisables par un minimum de cas différents (histoire
  d'éviter d'arriver à autant de fonctionnalités que d'utilisateurs)
- sont faisables sans arriver à un produit 700 fois plus lent (je ne
  cite pas de noms)
- sont réalisables sans rendre nécessaire un produit dispo sur moins
  d'un hébergeur sur 10 (genre pear ...)
- et surtout si un jour quelqu'un à essayé de se palucher le code !

  Car il faudrait essayer de ce souvenir un coup de temps en temps du
statut de spip ! contrairement à agora, les auteurs de spip n'ont
aucune obligation, aucun contrat. Et contrairement à agora qui
débarque en vrac une fois qu'il est bouclé, chacun à droit de se pointer
avec un bout de code et de dire aux core-dev «j'ai codé ça, si ça vous
plait, intégrez le, sinon, dites moi pourquoi, que je jette tout ou que
j'en fasse une contrib».

  Ça c'est passé comme ça pour les champs extra. Il y a eu beaucoup de
discussions (contructives celles là), et à l'arrivée, le code ne
ressemble plus du tout à celui que j'avais écrit, mais au moins la
fonctionnalité est là.
  J'espère pouvoir en faire autant d'ici peu avec les mots clés sur
auteurs, quelques modifs de "xhtml compliance" sont en train d'arriver
de la même façon, et j'espère qu'un jour le compilateur de squelettes
d'ESJ prendra la même voie.

À+, Pif.

Christian Lefebvre a écrit :

- sont pas implémentables par une contrib

Je réagis juste sur ce point : pourquoi passer forcément par des contrib alors que des fonctionnalités pourraient être intégrées nativement par SPIP ? Je pense notamment et surtout aux liens typographiques ou à la gallerie des documents par ex.

Ce sont des dev qui apporte un réel plus fonctionnel à SPIP alors pourquoi se limiter à l'avoir en contrib alors que cela peut être intégré par défaut ?

Je parle des dev de SPIP-Agora mais ce serait valable pour tout autre dev autour de SPIP apportant un réel plus fonctionnel :wink:

Nicolas

>- sont pas implémentables par une contrib

Je réagis juste sur ce point : pourquoi passer forcément par des contrib
alors que des fonctionnalités pourraient être intégrées nativement par
SPIP ?

Tout dépend de ce que tu appelles une "contrib" : pour moi ce mot recouvre
aussi bien un patch à appliquer au "noyau" (correctif ou amélioration du
code) qu'un filtre "externe" qui a vocation à le rester (le filtre smileys,
par exemple).

Je pense notamment et surtout aux liens typographiques

Qu'entends-tu par là ?

ou à la gallerie des documents par ex.

La galerie des documents est un vieux serpent de mer ; oui ça pourrait être
une fonctionnalité appréciable, et non ce qui a été proposé jusqu'ici n'est
pas du tout au niveau de ce qu'on attend en matière de présentation et
d'interface.

Ce sont des dev qui apporte un réel plus fonctionnel à SPIP alors
pourquoi se limiter à l'avoir en contrib alors que cela peut être
intégré par défaut ?

Absolument.

-- Fil

Christian Lefebvre a écrit :

Car il faudrait essayer de ce souvenir un coup de temps en temps du
statut de spip ! contrairement à agora, les auteurs de spip n'ont
aucune obligation, aucun contrat. Et contrairement à agora qui
débarque en vrac une fois qu'il est bouclé, chacun à droit de se pointer
avec un bout de code et de dire aux core-dev «j'ai codé ça, si ça vous
plait, intégrez le, sinon, dites moi pourquoi, que je jette tout ou que
j'en fasse une contrib».

C'est comme ça aussi pour le projet AGORA (ou alors je serais déçu)

reste justement à savoir ce que vous attendez précisement au niveau de
l'interface
et de la présentation

reste justement à savoir ce que vous attendez précisement au niveau de
l'interface et de la présentation

Si tu compares le portfolio de la version CVS avec la présentation en liste
moche de la galerie, tu vois un peu dans quelle direction on peut aller sur
le plan graphique.

Par ailleurs la galerie implique de résoudre la question des documents
inclus dans plusieurs articles, avec les implications suivantes : qui peut
éditer les commentaires, comment s'assurer qu'on n'efface pas par mégarde un
document utilisé dans un autre article, etc.

-- Fil

Je réagis juste sur ce point : pourquoi passer forcément par des contrib
alors que des fonctionnalités pourraient être intégrées nativement par
SPIP ?

Pour moi, il y a 2 raisons à ça :
- éviter d'avoir 50 fonctionnalités dans le code, qui ne peuvent
  qu'allourdir le tout à terme, alors que chaque utilisateur n'en
  utilisera qu'une ou deux.
- permettre de déléguer : dès qu'une fonctionnalité est dans spip,
  tous les dev futurs devront s'arranger pour la garder et éviter
  les regréssions. Et ce boulot tombera principalement à la charge
  des core-dev (c'est en tous cas sur eux qu'on gueulera si un machin
  dégage par erreur)

Une contrib permet :
- de n'être installée que si on en a besoin, sans arriver à un foutoir
  phénomémal au noveau de la gestion des options
- laisser la responsabilité de l'évolution à ses mainteneurs,
  indépendament du coeur de spip.

  Maintenant, effectivement, les contrib sont pas toujours évidentes
à installer. Là dessus, je relance le serpent de mer des mods :
bas de la page http://lab.spip.net/spikini/?wiki=FonctionnalitesExperimentales
et dernière ligne de http://lab.spip.net/spikini/?wiki=AutresChantiers.

À+, Pif.

Je pense notamment et surtout aux liens typographiques ou à la
gallerie des documents par ex.

Ce sont des dev qui apporte un réel plus fonctionnel à SPIP alors
pourquoi se limiter à l'avoir en contrib alors que cela peut être
intégré par défaut ?

Je parle des dev de SPIP-Agora mais ce serait valable pour tout autre
dev autour de SPIP apportant un réel plus fonctionnel :wink:

Nicolas

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
cvs: http://www.spip.net/spip-dev/devel/
irc://irc.freenode.net/spip

Christian Lefebvre Phone : +33 3 20 60 82 27
christian.lefebvre@atosorigin.com Fax : +33 3 20 60 83 02
Atos Worldline / Unit TelCo Utilities Media / Business Development
Atos Worldline is an Atos Origin company: http://www.atosorigin.com

This e-mail is privileged and may contain confidential information
intended only for the person(s) named above. If you receive this mail in
error, please notify the sender immediately by telephone or return mail.
Although the sender endeavours to maintain a computer virus free
network, the sender does not warrant that this transmission is
virus-free and will not be liable for any damages resulting from any
virus transmitted.

Fil a écrit :

Tout dépend de ce que tu appelles une "contrib" : pour moi ce mot recouvre
aussi bien un patch à appliquer au "noyau" (correctif ou amélioration du
code) qu'un filtre "externe" qui a vocation à le rester (le filtre smileys,
par exemple).

Bien sur, toutes les contrib n'ont pas pour vocation à être intégrées nativement. Pour les contrib que j'ai cité, dans la mesure où elle facilite davantage la saisie des contenus d'un site, ce serait dommage de s'en priver ou de l'avoir en contrib externe. Tous les Spipeurs n'ont pas forcément le souhait d'ajouter des contrib...

Je pense notamment et surtout aux liens typographiques

Qu'entends-tu par là ?

C'est plutôt raccourcis typographiques qu'il fallait lire (pas réveillé moi ce matin...)

L'utilisation :
- du | pour renseigner un terme ou un lien en renseignant le champ title,
- le système des ancres,
- la gallerie de documents,
- la légende des tableaux,

(j'ose même pas parler du ->> qui est l'équivalent d'un targer="_blank" proscrit en XHTML d'ailleurs :wink: )

La galerie des documents est un vieux serpent de mer ; oui ça pourrait être
une fonctionnalité appréciable, et non ce qui a été proposé jusqu'ici n'est
pas du tout au niveau de ce qu'on attend en matière de présentation et
d'interface.

Là tout de suite, c'est sur que si cela vous plait pas, c'est une autre histoire ! :wink:

Mais c'est quand même vachement fonctionnel et apprécié :slight_smile:

La même chose pour les liens internes au site serait un plus aussi qui éviterait que l'on se sollicite le neurone pour se rappeler que le numéro de la rubrique bidule est 7 :wink:

Nicolas

Nicolas Steinmetz wrote:

La même chose pour les liens internes au site serait un plus aussi qui éviterait que l'on se sollicite le neurone pour se rappeler que le numéro de la rubrique bidule est 7 :wink:

C'est une fonctionnalité qui me trotte :

[par ici si vous voulez -> baleine]
créerait un lien vers la rubrique ou à l'article
qui aurait le motclé de titre "baleine".

Si ya pas de motclé "baleine",
ça chercherait la Rubrique dont le titre contiendrait le mot "Baleine",
et si yen a pas de rubrique adhoc, ça chercherait parmis les articles.

C'est de ça ou autre chose que tu causes ?
JLuc

JLuc a écrit :

Nicolas Steinmetz wrote:

La même chose pour les liens internes au site serait un plus aussi qui éviterait que l'on se sollicite le neurone pour se rappeler que le numéro de la rubrique bidule est 7 :wink:

C'est une fonctionnalité qui me trotte :

[par ici si vous voulez -> baleine]
créerait un lien vers la rubrique ou à l'article
qui aurait le motclé de titre "baleine".

Pour un gros site, ça reste super fastidieux non ?

Si ya pas de motclé "baleine",
ça chercherait la Rubrique dont le titre contiendrait le mot "Baleine",
et si yen a pas de rubrique adhoc, ça chercherait parmis les articles.

C'est de ça ou autre chose que tu causes ?

Oui potentiellment mais en plus simple et en moins gourmand en ressources. Ta solution d'approximation est intéressante mais je crains qu'elle soit un peu longue à exécuter :-/

Je voyais bien une interface proche de la gallerie de documents d'Agora présentant l'arbo du site et en cliquant sur l'article bidule alors on a un beau [->artxx] qui s'insère :slight_smile:

Nicolas

Nicolas Steinmetz wrote:

JLuc a écrit :

[par ici si vous voulez -> "baleine"]
créerait un lien vers la rubrique ou à l'article
qui aurait le motclé de titre "baleine".

Pour un gros site, ça reste super fastidieux non ?

Pour les les pages les plus souvent référencées en interne
cela serait un gain d'autant appréciable.

Exemple : [ainsi qu'il est indiqué dans la revue n°15->"N15"]

Si ya pas de motclé "baleine",
ça chercherait la Rubrique dont le titre contiendrait le mot "Baleine",
et si yen a pas de rubrique adhoc, ça chercherait parmis les articles.

Ta solution d'approximation est intéressante mais je crains qu'elle soit un peu longue à exécuter :-/

Pas beaucoup plus qu'une requête ou une boucle avec une expression régulière sur le TITRE comme critère.
De même qu'une boucle, ça s'exécute seulement lors de la mise en cache initiale.

JLuc