Articles précédents : Logiciel
- [36] Nouveau jeu sous Linux : Tribal Trouble !
- [12] Nouvelle version de Linux PAM
- [7] AnalyseSI, l'analyse Merise en libre
- [8] TheOpenCD 2.0 entièrement traduit en français
- [29] Sortie officielle de Tiny ERP 2.0
- [12] Un outil de conception pour CPLD et FPGA sous Linux.
- [18] Mise à jour Mozilla, Firefox et Thunderbird
- [128] KDE 3.4 officiellement sorti
- [20] PhpWebGallery 1.4.0
- [14] phpMyVisites 1.3 est dans les bacs
Liens connexes
- Annonce de la sortie (3494 hits)
- Procédure de mise à jour (1193 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : SPIP 1.8 est sorti
Posté par Aurélien Bompard (Jabber id, page perso, ). Modéré le 03 avril 2005.
L'objectif de SPIP reste toujours le même : proposer un moyen simple de créer un site web, tout en restant souple et très fonctionnel.
Parmi les principales nouveautés, on retrouve :
- un espace d'administration complètement refondu, sur le plan graphique et ergonomique,
- la prévisualisation d'un article avec les squelettes publics
- la gestion de l'historique des modifications dans un article
- un nouveau gestionnaire de documents attachés à un article ou une rubrique
- l'ajout de fonctionnalités intéressantes en mode client-serveur, par exemple un correcteur orthographique et un générateur LaTeX. Des serveurs d'analyse orthographique et de rendu LaTeX sont fournis par la communauté.
Mais aussi beaucoup de modifications qui seront moins évidentes pour l'utilisateur, comme par exemple le nouveau compilateur de squelettes qui gagne beaucoup en souplesse, des traductions mises à jour, et une meilleure conformité W3C.
La procédure de mise à jour est très simple, et fonctionne bien manifestement.
Un énorme bravo à toute l'équipe de développement de SPIP, qui nous apporte un outil très puissant, très souple mais aussi très simple d'utilisation.
![[fr]](../../../images/fr.png)
Annonce de la sortie (3494 hits)-
Procédure de mise à jour (1193 hits)
> Lire les commentaires (66 commentaires, moyenne: 3,4).
c'est moi ou la procédure de mise à jour est pour le moins cavalière ?
En effet, si je m'en tiens à ce qui est expliqué, je vais perdre toutes les modifications visuelles de mon site (modification du fichier habillage, etc...)
Kil In Linux... somewhere on earth with a PowerMac G5
-
[^]Re: c'est moi ou la procédure de mise à jour est pour le moins cavalière
Posté par Denis (page perso, ) le 03/04/2005 à 15:54. (lien). Évalué à 2.Tu vois çà où ?
Je ne vois rien dans l'annonce qui indique une incompatibilitée avec des squelettes existants ...-
[^]Re: c'est moi ou la procédure de mise à jour est pour le moins cavalière
Posté par Rodolphe Mosca (page perso, ) le 03/04/2005 à 18:17. (lien). Évalué à 2.Mais si on suit la procédure indiquée, on remplace tous nos fichiers par les nouveaux fichiers (puisque l'on écrase tout), puis faut réinstaller nos squelettes, c'est çà ?
fichier habillage par exemple...--
Kil In Linux... somewhere on earth with a PowerMac G5-
[^]Re: c'est moi ou la procédure de mise à jour est pour le moins cavalière
Posté par R4f (page perso, ) le 03/04/2005 à 19:09. (lien). Évalué à 10.Mais si on suit la procédure indiquée, on remplace tous nos fichiers par les nouveaux fichiers (puisque l'on écrase tout), puis faut réinstaller nos squelettes, c'est çà ?
fichier habillage par exemple...
Disons que pour la plupart des fichiers (c'est à dire les squelettes, en ce qui nous concerne), SPIP est vraiment bien fait, car il ne fournit que des fichiers -dist.html, dont le comportement est annulé si on crée un fichier du même nom sans le -dist.
Ex. : un fichier article-dist.html est fourni (comme exemple) ; on peut remplacer l'affichage des articles en créant un fichier article.html. C'est ce fichier article.html qui sera pris en compte pour l'affichage des articles, au lieu de l'ancien article-dist.html.
De ce fait, lorsque SPIP est ré-installé, il écrase article-dist.html mais laisse intact ton article.html, fait maison. Bien joué, non ?
Pour ce qui est de habillage.css, c'est une des rares exceptions. Donc, comme d'hab', il faut faire une sauvegarde avant de ré-installer SPIP... Précaution qu'il est inutile de rappeler, bien sûr ! ;-)
-
[^]Re: c'est moi ou la procédure de mise à jour est pour le moins cavalière
Posté par Denis (page perso, ) le 03/04/2005 à 19:30. (lien). Évalué à 5.Par défaut les squelettes sont maintenant dans un répertoire /dist/ donc aucun soucis qu'ils écrasent les anciens (sauf si tes squellettes sont déjà dans un rep de ce nom, auquel cas tu n'uploades pas ce répertoire lors de la MAJ)
Pour tes fichiers CSS, spip 1.8 en contient 5 à la racine qui seraient effectivement écrasés:
habillage.css, impression.css, spip_admin.css, spip_style.css et typographie.css
Il est donc important de ne pas les écraser si tu as fait des modifs dessus que tu voudrais garder.
-
-
et agora ?
Une question, est-ce que spip-agora a été utile à spip 1.8 ?
Ou bien est-ce qu'on est finalement en présence d'un vrai fork ?
-
[^]Re: et agora ?
Posté par carlo () le 03/04/2005 à 14:39. (lien). Évalué à 4.Je crois savoir que spip-agora avait justement été créé parce que les contacts du SIG (Systeme d'information gouvernemental) avec l'équipe de développement de SPIP n'avait rien donné.
En clair, le SIG voulait un outil avec de vrais procédures de "workflow"/validation de documents, et l'équipe de SPIP ne voulait pas changer le système actuel.
SPIP-Agora est donc bien un fork qui aboutira peut-être au "backports" de fonctionnalités vers SPIP (canal historique ;-) mais certainement pas (sauf gros changement) à une fusion des deux à un moment ou à un autre.
carl0:--
carl0:-
[^]Soyons clair
Posté par Jul (page perso, ) le 03/04/2005 à 17:45. (lien). Évalué à 1.
En clair, le SIG voulait un outil avec de vrais procédures de "workflow"/validation de documents, et l'équipe de SPIP ne voulait pas changer le système actuel.
1) de «vrais procédures» tu peux expliquer ce que cela veut dire ?
2) peux tu nous donner tes source ?
Le SIG a fait un fork non maintenu, réinventer la roue, forker est une démarche hostile et stupide en logiciel libre. On appréciera le comportement de certains soit disant défenseurs du libre dans l'administration ; il semble que les administrations aiment à réinventer la roue (syndrôme NIH) les licences (CECILL), et forker (webCT95, spip-agora, les distros-«édus»). Je me dis que l'administration serait moins dangereuse pour le libre si elle était sous windows.
En plus ça marche moins bien que spip spip-agora, fun non ?
http://www.neokraft.net/blog/2004/06/17/515-comparaison-spip-spip-a(...)-
[^]Re: Soyons clair
Posté par carlo () le 03/04/2005 à 20:38. (lien). Évalué à 4.de «vrais procédures» tu peux expliquer ce que cela veut dire ?
en gros, avec plus de niveaux de droits possibles que les seuls admins ou rédacteurs,
on le voit d'ailleurs sur le wiki http://spip-contrib.net/spikini/Agora2Spip(...) :
Proposition intégrée dans SPIP-AGORA : Plus de niveaux de validation
Avis SPIP : Non, ce n'est pas dans la philosophie de SPIP
J'ai entendu ces explications par un représentant de clever age (la ssii qui a, il me semble, participé au dev de spip-agora) lors d'une présentation sur les LL.
C'est également expliqué sur leur site http://www.agora.gouv.fr/article64.html(...)
Il me semble que c'est cette raison principale (celle du circuit de validation) qui a entrainé le fork. L'équipe de dev de SPIP ne voulant pas changer ce principe de fonctionnement de SPIP (celui d'origine, qu'on peut retrouvé sur le site de uzine : http://www.uzine.net/article1331.html(...) )
Je me dis que l'administration serait moins dangereuse pour le libre si elle était sous windows.
dans ce cas, ne t'inquiète pas l'administration est encore beaucoup (trop) sous windows ! ;-(--
carl0:-
[^]j'ai du mal avec le mot «vraies» dans vraies procédures
Posté par Jul (page perso, ) le 04/04/2005 à 00:30. (lien). Évalué à 6.En ce qui concerne la notion de ****vraies**** procédures, je ne vois pas en quoi rendre plus compliqué (donc potentiellement déroutant) le process de validation donne à spip-agora de ***VRAIES** procédures Des procédures plus compliquées peut être, plus «véritables» sûrement pas. À chaque fois qu'on me parle en organisation d'augmenter la finesse d'un workflow j'entend plier les outils informatique au bordel organisationnel.
La philosophie de SPIP est de faciliter la publication, et je trouve la procédure déjà un tantinnet compliqué à expliquer à des béotiens bien que pertinente. Ainsi, j'ai du mal à voir le bénéfice d'avoir un outil plus compliqué et l'intérêt **réel** organisationnel et non **politique** que cela représente.
Le but est de produire du contenu au plus simple. Si les gens ne peuvent travailler ensemble dans la vraie vie, le patch informatique ne sera de toute façon qu'un cauthère sur une jambe de bois.
On sait qu'un programme est proche d'être abouti non quand on rajoute des fonctionnalités (gadgets) mais quand on en enlève à mon avis ; le véritable progès réside non l'apport d'un plus grand nombre de fonctionnalités mais dans la pertinence de ces dernières. En ceci, je trouve que l'équipe SPIP en refusant un process compliqué a montré sa maturité.-
[^]Re: j'ai du mal avec le mot «vraies» dans vraies procédures
Posté par Nap () le 04/04/2005 à 09:13. (lien). Évalué à 8.dans ma boite on développe des applis avec des utilisateurs et des administrateurs, et tous les clients ont besoin d'un certain nombre de rôles bien distincts, pour partager les tâches. On a gagné un certain nombre de marchés face à des concurrents incapables de proposer autre chose qu'une distinction administrateur/utilisateur, avec laquelle les clients étaient obligés de donner tous les droits sur les données à certaines personnes.
Les profils d'accès sont une notion universellement répandue. Je ne vois vraiment pas ce qui cloche la dedans. Je respecte le choix des devs de spip d'avoir voulu garder un modèle simple, mais je comprends parfaitement les besoins des clients ayant motivé le fork.
Dans ces cas là on peut aussi chercher à rendre le système plus souple, avec des regroupements de profils et de tâches, qui peuvent être affinés si besoin.
En ce qui concerne l'expression "plier les outils informatiques", je trouve que ça fait moins mal que "plier les utilisateurs", à part à un informaticien qui a du mal à imaginer que quelqu'un a pu penser différemment de lui...-
[^]Re: j'ai du mal avec le mot «vraies» dans vraies procédures
Posté par Jul (page perso, ) le 05/04/2005 à 00:44. (lien). Évalué à 3.Gagner des marchés ne vous fait malgré tout pas détenir la **vérité** des procédures. ;-)
Ce projet était parti pour être un fiasco et c'était prévisible. (c'est certes simple de ma part de prédire le passé). Il y avait à la base une incompatibilité évidente entre le projet SPIP (publier simplement) et ce que voulait le client (une complexification du projet) ... le logiciel libre ne peut pas résoudre tous les problèmes, et notamment la mauvaise conduite du chantier informatique. Qu'il s'agisse de libre ou pas, la MOAS et la MOE sont passées à coté du sujet.
Au final, on ne fait pas boire un âne (SPIP) qui n'a pas soif, et certains se condamnent à faire un fork qui se fera éclipser par le projet upstream. C'est quoi l'intérêt ? Est-ce le coeur de métier de l'amdinistration d'être un éditeur de logiciel non pérennes ?
Il faut autre chose que publier du code sous GPL pour faire du logiciel libre : http://www.libroscope.org/Liberer-les-logiciels(...)
Sinon, en ce qui concerne le pliage, je pense que le métier de l'informaticien n'est ni d'aller dans le sens de l'utilisateur ou de la machine, mais d'avoir le sens de la mesure en essayant de proposer des situations où le "pliage" tant au niveau humain qu'informatique est minimal.
Et dans ma boîte on voit a priori :
- que faire simple ça demande plus de réflexion que de faire compliqué ;
- que faire simple apporte bien plus en terme de résultat ;
- que faire compliqué impressionne plus facilement ;
- que faire compliqué permet de facturer plus.
Donc on essaie toujours de faire au plus simple car on fera toujours trop compliqué.-
[^]Re: j'ai du mal avec le mot «vraies» dans vraies procédures
Posté par Nap () le 05/04/2005 à 05:57. (lien). Évalué à 4.chacun voit les choses dans son domaine... le pragmatisme dans ton boulot vous permet de rester simple, tant mieux pour vos développeurs. De mon côté, si on était resté simple, on serait plus là :) De toute manière sur le plan du partage des tâches administratives on a réussi à trouver des modèles pouvant être simple ou complexe, suivant qu'on regroupe les rôles ou pas, et donc s'adapter à tout le monde. Je ne sais pas si SPIP aurait pu faire ça, mais apparemment ils se lancent dans cette direction avec les plugins.
-
-
[^]Re: j'ai du mal avec le mot «vraies» dans vraies procédures
Posté par Croconux () le 05/04/2005 à 12:00. (lien). Évalué à 6.En ce qui concerne l'expression "plier les outils informatiques", je trouve que ça fait moins mal que "plier les utilisateurs", à part à un informaticien qui a du mal à imaginer que quelqu'un a pu penser différemment de lui...
Il ne s'agit pas forcément de faire rentrer les utilisateurs dans un modèle mais en tant que fournisseur, on a un devoir de conseil. Il y a souvent une énorme divergence entre l'acheteur (celui qui choisit le produit) et les utilisateurs. Ces derniers ne sont en général pas des power users et veulent "que ça marche". Le decidor, lui, veut un produit qui fait le café. Il est souvent nécessaire de faire prendre conscience au boss que ce qu'il demande est une usine à gaz qui ne va pas dans le sens des utilisateurs.
Pour ce qui est de faire "plier les outils informatique", en général ça ne pose pas de problème d'adapter les outils si le fonctionnement de la boite est un minimum logique. La où on a de gros problèmes, c'est sur les boites "historiques", des boites munies d'innombrables niveaux hierarchiques, de processus de décisions avec allers retours d'un service à l'autre, etc (pensez aux administations). Là, au lieu de commencer par rationnaliser tout ça, on demande à l'informatique de s'adapter au bordel ambiant et de ne sortout pas changer l'existant. Informatiser ce n'est pas seulement installer des ordinateurs. Si l'activité ne tient pas compte du passage à l'informatique on abouti à des systèmes comme les sites de beaucoup d'administations qui permettent juste de téléchager les PDF à imprimer et à donner au guichet habituel. On a installé des systèmes mais on a pas revu les procédures. Il faut toujours passer par n guichets (n > 2 dans tous les cas) et le formulaire doit toujours être traité par plusieurs personnes.-
[^]Utilisateurs VS Outils Informatiques
Posté par Manuel Da SILVA (page perso, ) le 06/04/2005 à 14:26. (lien). Évalué à 5.En tant qu'Ergonome, je m'amuse souvent à écouter les dev parler de simplicité, de "c'est une question d'habitude...", et en tant que dev. je vois bien que c'est souvent bien difficile de s'élever au dessus de sa copie et temps Jours/homme restant !!!
Mais je ne peux qu'être d'accord sur l'expression "plier les outils informatiques", c'est à l'IHM de s'adapter et en aucun cas l'utilisateur...
Pour revenir sur les différents "niveaux" de validation (au delà du simple admin / contributeur), il est évident que dans un projet un temps soit peu important (c'est à dire, intégrant un nombre important de "contributions"), un classement de "droit" est nécessaire ; par exemple, donner un droit de "validation" sur une UNIQUE rubrique permet de soulager l'interface d'administration et d'apporter de la simplicité à cet utilisateur... et inversement limité les droits d'un contributeur sur une partie / theme / rubrique permet de simplifier sont travaille.
Ne pas confondre simplicité du concept (dualité entre validateur / contributeur) et simplicité d'utilisation !!!
Pour s'en convaincre, il suffit d'observer un utilisateur devant son "panel" de boutons et de ne pas savoir ou cliquer pour écrire sa petite brève dans la rubrique de sa matière !--
Da SILVA Manuel
-
[^]Re: j'ai du mal avec le mot «vraies» dans vraies procédures
Posté par R4f (page perso, ) le 06/04/2005 à 20:22. (lien). Évalué à 4.La où on a de gros problèmes, c'est sur les boites "historiques", des boites munies d'innombrables niveaux hierarchiques, de processus de décisions avec allers retours d'un service à l'autre, etc (pensez aux administations).
On fait quand même tourner SPIP à La Poste (sur le site http://www.laposte.fr(...) ), donc je trouve que tu exagères ! ;-)
Bon, il a fallu ajouter un niveau hiérarchique à SPIP, et permettre d'ajouter des logos en Flash (beurk... ;-), donc un mini-fork, mais c'est passé sans trop en faire une uzine à gaz...
-
-
-
-
-
[^]Re: Soyons clair
Posté par reno () le 03/04/2005 à 22:19. (lien). Évalué à 8.Bah, la force du libre, c'est ça: n'importe qui peut forker si le projet source ne veut pas intégrer les modifications demandées..
Ce qui est prècisement le cas ici, donc je ne vois pas en quoi c'est un problème.-
[^]Re: Soyons clair
Posté par François Becker (page perso, ) le 03/04/2005 à 22:26. (lien). Évalué à 4....la preuve en est la volonté actuelle de permettre des contribs à spip (sous forme de modules si j'ai bien compris)... c'est donc qu'ils se sont rendu compte que ce qu'on leur demandait n'était pas si... "méchant" (j'ai pas trouvé le mot exact... si qqun l'a, merci de compléter...)
--
elle est libre ma musique : http://moala.online.fr/audiosite/-
[^]Re: Soyons clair
-
-
-
[^]Re: Soyons clair
Posté par Mickaël L () le 03/04/2005 à 22:25. (lien). Évalué à 10.> forker est une démarche hostile et stupide en logiciel libre
C'est bizarre, il me semble que l'on parle de forks hostiles et de forls non-hostiles pourtant. Ça doit bien vouloir dire quelque chose.
Pour moi, un fork c'est un peu comme une autre branche de développement. Au début, la plupart des architectures "autres" de Linux pouvaient être considérées comme des forks, jusqu'à ce qu'elles fusionnent (d'ailleurs, certaines sont toujours développées à part je crois).
Des fois c'est plutôt "on n'a pas le temps de le faire, faites de votre côté si vous pouvez, on verra peut-être plus tard si on peut récupérer votre boulot".
Et il y a bien sûr les forks stupides et hostiles. Mias faut pas se focaliser là dessus. D'autant que ça dépend du point de vue. Pour certains, le fork X.org est hostile (pour ceux de Xfree86). Pour la plupart, c'est le seul choix raisonnable. Encore heureux qu'on puisse forker.
>les distros-«édus»
J'appelle pas ça un fork moi. Souvent, ce sont des projets à l'intérieur de distribs (debian-edu), ou le travail de volontaires de l'administration *sans couverture de l'administration*, correspondant à des besoins spécifiques.
Faut pas être trop chatouilleux là dessus-
[^]Re: Soyons clair
Posté par Jul (page perso, ) le 04/04/2005 à 00:15. (lien). Évalué à 5.> forker est une démarche stupide et hostile
Voilà une remarque à l'emporte pièce que j'aurais pas du sortir. Ta réponse est exacte.
Je devrais peut être plutôt dire que le fork est une arme de disuasion qui affaiblit les projets forkant et forker et qui n'es pas à utiliser à la légère. Ce serait bien que ce ne soit pas le premier réflexe des administrations.
Pour les trucs d'édu quand je parcours le web francophone je me dis qu'il faut plutôt dire que la communauté de l'enseignement et assimilée est très active (sympa, ext2, debian-edu). Je le dis avant qu'on me le fasse remarquer :)
J'ai écrit le précédent commentaires en étant de mauvaise humeur. C'est pas une raison pour dire des bêtises en manquant de nuance, mais je demande les circonstances atténuantes.
-
-
-
[^]Re: et agora ?
Posté par R4f (page perso, ) le 03/04/2005 à 19:13. (lien). Évalué à 7.RTFW (Read The Famous Wiki)
Objectif : intégrer sous forme de contrib les apports d’AGORA
http://spip-contrib.net/spikini/Agora2Spip(...)-
[^]Re: et agora ?
-
-
Juste une coquille
"avec les squelettes publiques" => "avec les squelettes publics"
Restriction d'accès à la zone publique
Je me trompe ou il n'y a rien eu de prévu pour restreindre (en entier ou en partie seulement) la zone publique ?
J'ai réussit à le faire tant bien que mal sur un site, mais ça demande des manipulations plutôt inattendues pour Spip qui est, par ailleurs, très simple à mettre en place...
Même si ce n'était pas prévu pour l'utilisateur final, cela serait pratique que le moteur offre cette possibilité...
Mis à part cette petite complainte, je dis un grand merci à toute l'équipe de Spip, pour cet outil merveilleux :)
-
[^]Re: Restriction d'accès à la zone publique
Posté par R4f (page perso, ) le 03/04/2005 à 19:19. (lien). Évalué à 8.Je me trompe ou il n'y a rien eu de prévu pour restreindre (en entier ou en partie seulement) la zone publique ?
Xprotector sera désormais ton ami ! http://xprotector.sourceforge.net/(...)
Xprotector est un programme en PHP pour créer et gérer des rubriques restreintes SPIP . On peut également gérer des utilisateurs qui ont accès à ces rubriques.
Mis à part cette petite complainte, je dis un grand merci à toute l'équipe de Spip, pour cet outil merveilleux :)
Ah, quand même une personne qui fait un commentaire sympa ! ;-)
Conformité W3C
<i>Le moteur de raccourcis fait son possible pour être conforme aux recommandations du W3C</i>
On ne peut qu'en féliciter les mainteneurs de SPIP. Cette déclaration contraste singulièrement avec les déclarations faites par Arno "W3C go home !" sur Uzine en septembre 2003. On ne peut que s'en réjouir car le respect des normes est le début de l'interopérabilité.
-
[^]Re: Conformité W3C
Posté par tuiu pol (Jabber id, ) le 03/04/2005 à 22:16. (lien). Évalué à 2.Oui d'autant qu'il était possible de coller plus près des recommandations W3C au niveau du moteur sans faire beaucoup de modification (et oui je l'avais en partie fait).
La non-conformité des pages générées par SPIP est (était?) le seul point noir de ce logiciel en ce qui me concerne .. a essayer pour ceux qui ne connaissent pas.
-
[^]Re: Conformité W3C
Posté par Jul (page perso, ) le 04/04/2005 à 01:15. (lien). Évalué à 10.On peut aussi dire qu'il faut pas non plus être excessif dans le discours sur la conformité :
http://www.joelonsoftware.com/items/2004/04/22.html(...)
En général, il y a un excès pour certains qui regardent les pages aux W3C validator, au lieu de se poser la question de tester voir si elles sont «accessibles» en utilisant leur cervelle personnelle voir en les testants en condition (logiciel de lecture, brouteur texte, ou braille). Car le web est fait pour être lu et écrit par des humains au final handicapés ou non.
(NB l'orthographe, le respect de la typographie, l'organisation du contenu, le style sont pour moi des critères essentiels «d'accessibilité». Bizarrement, j'ai l'impression que la plupart des geeks s'en foutent, je me trompe ?)
Si les fanas du validator avaient utilisé leur cervelle, ils se seraient rendu compte que la conformité au W3C html stricte pour spip pouvaient être considérées comme du plaquage or sur une démarche de rendre la publication sur le web plus simple. Ce qui était une démarche d'accessibilité globale bien aboutie ; le but même du projet.
Quand spip était vers la fin (spip 1.7) faussement accusé de générer du code non conforme au validator (libroscope servait de démo, et j'ai vu passé les robots), j'ai rarement vu sur les forums linuxfr ou entendu dans diverses réunions en ville écrit : «ooops, je me suis trompé, ça passe le W3C et merci», mais plutôt : «ça pue SPIP, ça passe pas le W3C validator». Non seulement c'était faux, mais en plus ces commentaires passaient à coté de l'essentiel : ils ont réussi à rendre la publication et les contenus factuellement plus accessibles à tous : lecteurs et rédacteurs. Et qui plus et, ils ont encouragés des bonnes pratiques de lisibilité (organisation du contenu autre qu'en mode «en fil à la /.», typo, utilisation des CSS ...)
Moi, je m'en fous je suis pas développeur spip, mais je me dis qu'à leur place je l'aurais eu mauvaise et qu'il manque à certains ce que les grecs appellent le sens de la mesure.-
[^]Re: Conformité W3C
-
[^]Re: Conformité W3C
Posté par Éric (Jabber id, page perso, ) le 04/04/2005 à 12:54. (lien). Évalué à 4.La validité syntaxique n'est pas que un idéal de geek. C'est ce qui peut permettre à tout un chacun d'aller analyser un contenu sans avoir à développer un moteur de la taille de Mozilla ou avoir un contenu qui diffère totalement de ce que veut faire l'auteur.
<b>hello<p><i>world</b> !</i> tu interprêtes ça comment ? où met tu le gras ou met tu l'italique ? un moteur qui analyse ça n'est pas si simple. Si en plus tu veux l'analyser de la même façon que MSIE (c'est à dire pour faire court "comme l'auteur le veut") tu vas galerer pas mal à reproduire la logique d'erreur de MSIE et les bugs ou choix arbitraires non documentés qui vont avec.
Faire un moteur laxiste c'est très loin d'être simple, ne pas faire d'erreur syntaxique c'est déjà permettre d'analyser les pages avec des moteurs génériques SGML/XML. Et là une erreur syntaxique c'est quasi aussi gênant que 150 : la page ne passe pas, point final.
Certes la validité syntaxique n'est pas un aboutissement en soi, certes il y a bien d'autres points (certains aussi importants, certains largement plus), mais non promouvoir une validité complète n'est pas simplement de l'extrémisme.
> Car le web est fait pour être lu et écrit par des humains au final
> handicapés ou non.
Parce que bon ... justement NON :
- sauf quelques geeks le contenu Web n'est pas créé à la main
- et même parmi les geeks, le contenu Web n'est pas lu par les humains.
Le Web c'est lu/écrit/manipulé par des machines, pas par des humains, c'est bien tout le problème. Et les machines elles ont besoin d'une validité suivant une syntaxe connue et définie.-
[^]Re: Conformité W3C
Posté par Cali_Mero () le 04/04/2005 à 13:56. (lien). Évalué à 0.Je m'étonne de ton point de vue :
<i>Parce que bon ... justement NON :
- sauf quelques geeks le contenu Web n'est pas créé à la main
- et même parmi les geeks, le contenu Web n'est pas lu par les humains.</i>
Il faudrait, pour bien comprendre la portée de tes assertions, définir clairement le "contenu web" dont tu parles. Car le circuit de l'information sur le web est très loin de se limiter à machine > machine.
La production de contenu à vocation de publication, en HTML, se fait bien à la main (avec souvent le concours d'un éditeur wysiwyg pour la mise en forme, ou une conversion automatisée en HTML à partir de texte brut).
La consultation de code HTML n'est pas sérieusement envisageable avec autre chose qu'un parseur SGML relativement tolérant aux erreurs dans le but d'une présentation à un être humain par tout moyen.
On a donc bien l'humain en tête et en bout de chaîne non ? Certes, des machines servent d'intermédiaire, une responsabilité plus lourde pesant sur le navigateur du client final.
En revanche, ton point de vue retranscrit la raison d'être de XML et XHTML, et illustre aussi les problématiques d'indexation des pages web dans les moteurs de recherche. Le traitement par une machine est là clairement un objectif voulu dès la création, et la validité syntaxique est alors nécessaire et vérifiable.
Un spider de moteur de recherche pouvant être assimilé grosso-modo à un lecteur aveugle, il est clair qu'il aura plus de facilité à analyser du contenu fortement structuré, obéissant à la grammaire standard définie, qu'une soupe de tags dans l'esprit de ton exemple (<b>hello<p><i>world</b> !</i>).--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */-
[^]Re: Conformité W3C
Posté par Éric (Jabber id, page perso, ) le 04/04/2005 à 16:25. (lien). Évalué à 4.> En revanche, ton point de vue retranscrit la raison d'être de XML et XHTML
Absolument pas. Tout ce dont je parle est autant vrai en HTML/SGML qu'en XHTML/XML. Respecter les règles de syntaxe du format est aussi important dans l'un que dans l'autre.
> On a donc bien l'humain en tête et en bout de chaîne non ? Certes,
> des machines servent d'intermédiaire, une responsabilité plus
> lourde pesant sur le navigateur du client final.
L'humain ne manipule pas le HTML, l'humain manipule ce que la machine a compris et lui renvoie. C'est pour ça qu'il est important que la machine comprenne bien. C'est pour ça aussi qu'il faut avoir une syntaxe correcte.
Si la machine doit faire des acrobaties et se plante, l'humain se plantera aussi. Le HTML et les formats sont destinés à des machines et uniquement à des machines. Et respecter des règles non floues est primordial pour une machine.
Dans tes exemples, un navigateur, un outil WYSIWYG, un outil de conversion à partir de texte brut, ce n'est pas ce que j'appelle un humain, ce sont bien des machines.
> Car le circuit de l'information sur le web est très loin de se limiter à machine > machine
Certes, il faut "humain > machine > HTML/HTTP > machine > humain". Le HTML/HTTP est lu/écrit par des machines et uniquement par des machines. Le fait qu'il y ai des humains en bout de chaine n'y change rien : ça doit être relisible correctement et simplement par une machine, ça doit respecter le format.-
[^]Re: Conformité W3C
Posté par Antoine () le 04/04/2005 à 18:42. (lien). Évalué à 3.L'humain ne manipule pas le HTML
Du point de vue d'un internaute fraîchement arrivé, peut-être.
Mais bon, il y a dix ans, tout le monde écrivait le HTML à la main, sans passer par le moindre éditeur WYSIWYG.-
[^]Re: Conformité W3C
Posté par briaeros007 () le 05/04/2005 à 10:06. (lien). Évalué à 4.tu vas pas me dire que tu t'amuse a lire les pages de dlfp par telnet quand meme; tu utilise bien un browser aussi , non?
Et ton browser il lis bien le html, donc dans usage "normal" (et non pas de debug ou de codage) je pense que l'on peux dire que l'humain ne manipule pas le html.
Je me demande juste comment on peux dire "finalement respecter le protocole c'est pas si grave".
Ce n'est pas parceque le cout de l'erreur est largement moins important dans ce cas la que dans d'autres que ce n'est pas un point a essaye de respecter.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Conformité W3C
Posté par Antoine () le 05/04/2005 à 12:42. (lien). Évalué à 4.tu vas pas me dire que tu t'amuse a lire les pages de dlfp par telnet quand meme; tu utilise bien un browser aussi , non?
Je parlais d'écrire le HTML, pas de le lire.
Je ne répondais pas spécialement sur le respect ou non des normes, mais sur le préconçu totalement foireux que le HTML n'est pas fait pour des humains.
Au contraire, la syntaxe du HTML (et ses diverses tolérances) a été étudiée spécialement pour être pratique à manipuler par des humains. C'est ce qui a permis la floraison du Web bien avant l'apparition des usines à gaz type Dreamweaver & co. Pour quiconque a découvert le Web au milieu des années 90, c'est une évidence. C'est aussi ce que rappelle l'article d'Arno si on fait abstraction de ses égarements rhétoriques.
J'ajoute qu'aujourd'hui encore, il est souvent nécessaire ou commode d'éditer le HTML à la main (par exemple quand on écrit des squelettes SPIP... ou pour d'autres outils de templates ;-)).-
[^]Re: Conformité W3C
Posté par Éric (Jabber id, page perso, ) le 05/04/2005 à 14:30. (lien). Évalué à 4.Oui, et exploiter les tolérances, faire du code non valide, c'est ce qui a amené ces superbes pages qui passent différement partout et qui demandent des moteurs de plusieurs Mo juste pour afficher un "hello world" en vert sur fond bleu. Elle est surtout là l'évidence pour moi.
Le HTML a des règles, des règles pas forcément aussi verbeuses que le XML, mais il n'est pas plus tolérant aux erreurs de syntaxe. Ce qui est tolérant c'est (éventuellement) le lecteur, pas le format.
(note: Le problème de la validité ça impacte celui qui lit le code, pas celui qui l'écrit. Et celui qui lit, c'est bien toujours une machine)-
[^]Re: Conformité W3C
Posté par Antoine () le 05/04/2005 à 14:38. (lien). Évalué à 3.Oui, et exploiter les tolérances, faire du code non valide, c'est ce qui a amené ces superbes pages qui passent différement partout
Les pages valides passent aussi différemment partout, et pour cause : c'est dans la nature du HTML de laisser beaucoup de latitude au navigateur ainsi qu'à l'utilisateur (choix des polices, de la taille de la fenêtre, etc.)
Si tu comprends les standards du Web, tu sais comme moi que l'objectif du HTML n'est absolument pas de parvenir à un rendu identique partout. Seulement que le contenu soit lisible et que son rendu respecte à peu près les intentions de celui qui a composé la page.
et qui demandent des moteurs de plusieurs Mo juste pour afficher un "hello world" en vert sur fond bleu
Argument non-démontré jusqu'à ce jour... Les moteurs font plusieurs Mo parce qu'il y a des choses très complexes à traiter (imbrications de tables avec des tonnes d'attributs différents et parfois incompatibles, etc.). Un "hello world", même écrit dans un HTML laxiste, peut être rendu correctement par un Lynx ou un Dillo.
D'ailleurs j'aimerais bien que quelqu'un compile un jour Gecko en enlevant le support de ces tolérances. Il serait intéressant de voir si cela réduit tant que ça l'empreinte mémoire du navigateur, et si cela améliore significativement les performances. Je n'en suis pas convaincu.
Le problème de la validité ça impacte celui qui lit le code, pas celui qui l'écrit
??? Si tu considères qu'il faut écrire du code valide, il est évident que le problème de la validité impacte aussi celui qui écrit le code.-
[^]Re: Conformité W3C
Posté par Éric (Jabber id, page perso, ) le 05/04/2005 à 16:16. (lien). Évalué à 2.> Si tu comprends les standards du Web, tu sais comme moi que
> l'objectif du HTML n'est absolument pas de parvenir à un rendu
> identique partout.
Et tu sais aussi probablement très bien que je ne parle pas du problème d'avoir un rendu différent, mais plutot des différences de tolérance et d'interprétation des erreurs. Si on se contentais des différences de choix d'affichage, mon boulot serait énormément plus simple.
> Argument non-démontré jusqu'à ce jour...
> Un "hello world", même écrit dans un HTML laxiste, peut être rendu
> correctement par un Lynx ou un Dillo.
Discutes avec quelqu'un qui développe un "vrai" navigateur, tu vas voir. Demandes à ton lynx d'interpréter les pages avec erreur "comme MSIE" (ben oui, parce que le principe de la tolérance c'est bien si tout le monde est tolérant de la même façon), tu vas voir les nuits blanches que tu vas passer.
> Si tu considères qu'il faut écrire du code valide, il est évident que
> le problème de la validité impacte aussi celui qui écrit le code.
Si tu écris du code invalide ça ne te gênera pas toi, ça gênera celui qui essayera de le relire. Et puis non, on parle bien de spip là non ? le concept même de spip c'est que c'est l'outil qui écrit ce HTML. Pour l'auteur que Spip fasse du valide ou pas, ça ne change rien à ses manipulations-
[^]Re: Conformité W3C
Posté par Antoine () le 05/04/2005 à 18:54. (lien). Évalué à 4.le concept même de spip c'est que c'est l'outil qui écrit ce HTML.
Heu non, ça c'est phpNuke & co. Le concept de SPIP, c'est que c'est le webmestre qui confectionne ses squelettes HTML lui-même (bien sûr il y a des squelettes par défaut, qui d'ailleurs sont aux normes !).
-
-
-
-
-
-
[+] [^]Re: Conformité W3C
Posté par Manuel Da SILVA (page perso, ) le 06/04/2005 à 14:41. (lien). Évalué à -1.Je me permet d'intervenir par ces quelques mots :
L'humain ne manipule pas le HTML... peut être pas mais ma synthèse vocale OUI--
Da SILVA Manuel
-
-
-
-
-
-
[^]Re: Conformité W3C
Posté par Noj Han (Jabber id, page perso, ) le 04/04/2005 à 14:12. (lien). Évalué à 4.J'ai lu l'article cité, et je ne trouve pas que cela contraste si « singulièrement » que ça... Dans cet article, si j'ai bien compris, il est question des intégristes du valid(at)eur, qui ne juge « l'accessiblité » que par le passage aux robots du W3C, sans tenir compte de l'utilisation qui est réellement faite du web.
À mon avis, cet article visait surtout les facheux qui pestaient sans savoir, et ne pronait en rien un retour à la balkanisation.-
[^]Re: Conformité W3C
Posté par Éric (Jabber id, page perso, ) le 04/04/2005 à 16:31. (lien). Évalué à 4.Bof, moi l'article en question j'y ai vu beaucoup de FUD, quelques contre-vérités et pas grand chose sur le fond ( http://blog.dreams4net.com/FudTrollEtUzine(...) ). Il a visiblement surtout été écrit sur le coup de l'énervement face aux critiques un peu trop répétées et non constructives, mais il reste que oui, le fameux texte d'Arno contraste pas mal avec ce point de vue bien plus compréhensible.
-
Et le LDAP?
Un truc pourtant utile de SPIP agora, que je ne retrouve toujours pas dans SPIP, c'est la possibilité de se brancher sur un LDAP pour l'authentification. C'est bien pratique, c'est de plus en plkus courant les LDAPs, surtout dans les établissements scolaires par exemple.
J'espère que ça viendra bientôt dans SPIP ça.
Voila, bonne journée, et quand même bravo aux développeurs.
@tchow
-
[^]Re: Et le LDAP?
Posté par Denis (page perso, ) le 04/04/2005 à 08:22. (lien). Évalué à 2.Ben si, apparement depuis la version 1.5
Le support LDAP -> http://www.spip.net/fr_article1910.html(...)-
[^]Re: Et le LDAP?
Posté par Swirly () le 04/04/2005 à 12:12. (lien). Évalué à 3.Je m esuis mal exprimé. Le support LDAP se SPIP permet juste de "récupérer" des listes sur les LDAP qui sotn ensuite intégrées au listes en base de donnée de SPIP.
Ce qui manque, c'est de pouvoir s'authentifier sur le LDAP sans qu'il y ait redondance des informations et que le caractère de rédacteur puisse être associé à un groupe dans le LDAP (un groupe posix ou un groupofnames).
De façon à pourvoir gérer les rédacteurs de la même façon que tout le reste des fonctions dans une société ou un établissement scolaire : par des infos dans le LDAP.
Et ça, pour l'instant, ça n'existe pas encore dans SPIP.
Mais ceci dit, SPIP est une bonne solution .
Tchow
-
Enfin...
Et dire qu'il ya 3 semaines à peine j'étais passé en 1.8rc, tout ça pour pouvoir utiliser la balise #EXPOSER de manières correctes (ie, propagées dasn tous les ancèters de la rubrique/article).
Par contre, il n'y aurais pas moyen de faire des fichiers *-dist.css, un peu comme pour les squelettes, afin de ne pas avoir à sauvegarder les ficheirs *.css et donc de préserver la mise en page?
-
[^]Re: Enfin...
Posté par Noj Han (Jabber id, page perso, ) le 04/04/2005 à 14:08. (lien). Évalué à 4.Je pense que c'est parce qu'en théorie, on ne touche pas aux css fournies. Il suffit de mettre tes trucs à toi dans ta propre css, que tu appelles depuis tes squelettes. Ainsi, tu as ta css à part, avec le nom que tu veux, sans avoir besoin de modifier les css par défaut.
SPIP vs Mambo ?
Bonjour,
J'utilise un peu Mambo, et il me semble très bien fait, surtout parce qu'il autorise l'ajout de fonctionalités via des modules et des composants. Bien sûr, une telle souplesse se paie et Mambo me semble très lourd.
Quelqu'un connait-il suffisament les deux pour nous en donner une comparaison ?
-
[^]Re: SPIP vs Mambo ?
Posté par dawar (page perso, ) le 04/04/2005 à 12:41. (lien). Évalué à 4.J'ai un peu fouillé les CMS ces derniers temps (et SPIP n'est pas vraiment un CMS a mon avis), et je me suis arreté sur xoops qui est vraiment très sympa. Le placement "fin" des blocs, le systeme de template (individuel a chaque bloc, éditable dans l'admin), la poids modéré de la chose, bref, je l'ai trouvé beaucoup plus sympa que Mambo et PHP-Nuke.
On y retrouve la même possibilité que dans SPIP, faire un site qui ne ressemble pas forcément a l'éternel deux/trois-colonnes.-
[^]Re: SPIP vs Mambo ?
Posté par gloups () le 04/04/2005 à 14:55. (lien). Évalué à 5.Si tu veux pouvoir construire un site institutionnel avec quelques briques type article, news, forum, ... les CMS classiques en PHP (mambo, Xoop, copix CMS, EZPublish, typo3, drupal, ...) te fourniront une base ouverte permettant d'étendre à volonté ton site page par page...
C'est un besoin classique mais ce n'est pas forcement le domaine de SPIP.
SPIP est orienté publication éditoriale, il permet donc de traiter la structure globale du site et permet d'intégrer du contenu non lié à une page mais catégorisé. Le site se chargeant de permettre l'accès au contenu. (La première grosse référence SPIP est le monde diplo et cela montre bien l'objectif de SPIP.)
C'est une approche fondamentalement différentes dans la manière de gérer le contenu.
-
-
[^]Re: SPIP vs Mambo ?
Posté par Cyril PIERRE de GEYER (page perso, ) le 04/04/2005 à 19:05. (lien). Évalué à 4.Je connais les deux outils pour les avoir beaucoup pratiqué.
A mon sens Spip est un outil tres facile a prendre en main et il permet de faire vite et bien un site éditorial.
Son système de cache permet d'avoir des performances excellentes.
Par contre des qu'il s'agit de faire des squelettes ca demande un peu de temps.
De plus je me suis trouvé assez vite limité par les extensions existantes.
Pour Mambo je le connais depuis moins longtemps mais j'ai particulièrement apprécié la dernière version (4.51 ?). L'interface est tres agréable et il existe de nombreuses possibilités.
Par contre c'est assez fouilli et pas evident de s'y retrouver. Il m'arrive souvent de chercher qq minutes pour retrouver une rubrique.
Au niveau des utilisateurs je préfère la gestion de SPIP qui est plus simple.
A mon sens Mambo est plus orienté site communautaire/CMS et spip est excellent pour les sites de publications qui n'ont pas besoin de fioritures.
D'autres retours ?
Migration : 5 minutes chrono
J'ai fait la migration d'un site en cinq minutes !
Aucun soucis ...
Chapeau les gars !!!!
Cyril
-
[^]Re: Migration : 5 minutes chrono
-
[^]Re: Migration : 5 minutes chrono
Perso, ça m'a tout pêté
Je remets la 1.7 fissa, car ça m'a perdu tous mes squelettes.
Je n'ai donc qu'un mot à dire : prudence!
-
[^]Re: Perso, ça m'a tout pêté
Posté par Gohar () le 05/04/2005 à 08:09. (lien). Évalué à 1.Evidemment, impossible de réinstaller une version antérieure.
Je sais, je peux ne m'en prendre qu'à moi, mais que mes mésaventures servent aux moins à d'autres: PRUDENCE !!!-
[^]Re: Perso, ça m'a tout pêté
Posté par Gohar () le 05/04/2005 à 08:31. (lien). Évalué à 1.A titre d'info, il faut placer les squelettes dans le répertoire /dist, chose que je n'ai vue indiquée nulle part...
-
[^]Re: Perso, ça m'a tout pêté
Posté par NiCoS (page perso, ) le 05/04/2005 à 09:04. (lien). Évalué à 1.Il n'en est aucunement besoin.
Mes squelettes .html et ma feuille de style.css sont à la racine du site et cela fonctionne très bien pour mes trois sites SPIP...
As-tu vérifié que :
1/ tous les fichiers transférés étaient bien transférés (mode binaire parfois à mettre dans ton client ftp)
2/ que tu n'as pas une variable définie pour dossier_squelettes ou je sais pas quoi dans /ecrire/inc_version.php3 il me semble
le répertoire dist ne sert que à contenir les squelettes *-dist.html fournis par SPIP.
bien sur tu avais fait une sauvegarde de ta base et de tes fichiers 1.7 avant de faire la mise à jour... donc no souci pour repasser en 1.7...
et puis pour les éventuels bugs, il y a les listes spip et spip-dev...-
[^]Re: Perso, ça m'a tout pêté
Posté par Gohar () le 05/04/2005 à 10:43. (lien). Évalué à 1.Il n'en est aucunement besoin.
Mes squelettes .html et ma feuille de style.css sont à la racine du site et cela fonctionne très bien pour mes trois sites SPIP...
Hé ben moi, j'en ai un et j'ai dû placer les squelettes dans /dist pour que ça marche à peu près. Mes squelettes liés à des fichiers.php3 personnalisés (article_xxx.php3) ne fonctionnent toujours pas. Certains liens html ont aussi sauté, va savoir pourquoi…
As-tu vérifié que :
1/ tous les fichiers transférés étaient bien transférés (mode binaire parfois à mettre dans ton client ftp)
2/ que tu n'as pas une variable définie pour dossier_squelettes ou je sais pas quoi dans /ecrire/inc_version.php3 il me semble
1/ Oui
2/ Oui
le répertoire dist ne sert que à contenir les squelettes *-dist.html fournis par SPIP.
Plus chez moi.
bien sur tu avais fait une sauvegarde de ta base et de tes fichiers 1.7 avant de faire la mise à jour... donc no souci pour repasser en 1.7...
Bien sûr. Sauf qu’à part créer une autre base, je vois pas comment restaurer la base sauvegardée. Spip me l’interdit. Big souci.
et puis pour les éventuels bugs, il y a les listes spip et spip-dev...
Yep. Mais c’est pas mal de le dire ici aussi pour que je sois pas le seul à me faire avoir. Et j’estime qu’une version qui contient autant de modifs aurait dû s’appeler 2.0 . Je me serais méfié.-
[^]Re: Perso, ça m'a tout pêté
Posté par NiCoS (page perso, ) le 05/04/2005 à 11:47. (lien). Évalué à 1.Bien sûr. Sauf qu’à part créer une autre base, je vois pas comment restaurer la base sauvegardée. Spip me l’interdit. Big souci.
Moi je passe que via des dumps sql et non pas le système de restatuation/backup de spip ;-)
-
[^]Re: Perso, ça m'a tout pêté
Posté par NiCoS (page perso, ) le 05/04/2005 à 11:52. (lien). Évalué à 2.Hé ben moi, j'en ai un et j'ai dû placer les squelettes dans /dist pour que ça marche à peu près. Mes squelettes liés à des fichiers.php3 personnalisés (article_xxx.php3) ne fonctionnent toujours pas. Certains liens html ont aussi sauté, va savoir pourquoi
Un nouveau paquet (estampillé avec le même nom) a été diffusé
A lire d'abord : http://article.gmane.org/gmane.comp.web.spip.devel/26188(...)-
[^]Re: Perso, ça m'a tout pêté
Posté par Gohar () le 05/04/2005 à 14:30. (lien). Évalué à 1.Une autre version avec le même nom? C'est très clair, tout ça...
-
[^]Re: Perso, ça m'a tout pêté
Posté par NiCoS (page perso, ) le 05/04/2005 à 14:36. (lien). Évalué à 1.Je suis bien d'accord et d'autres ont fait part de la même remarque que toi dans la suite du fil ;-)
-
-
-
-
[^]Re: Perso, ça m'a tout pêté
Posté par Gohar () le 05/04/2005 à 10:49. (lien). Évalué à 0.A propos, d'après ton site perso, à l'heure actuelle tu es toujours en SPIP 1.7.2...
http://www.destination-linux.org/(...)-
[^]Re: Perso, ça m'a tout pêté
Posté par NiCoS (page perso, ) le 05/04/2005 à 11:45. (lien). Évalué à 0.Il est passé en 1.8 dimanche, j'ai oublié de modifier le footer ;-)
-
-
-
-
Cette page a été générée par Templeet en 0.2203s (dont 0.0384 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.