[fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

davidm · 2005-09-23 13:36:12

Pas vraiment, c’est un des défaut de textpattern depuis le départ : on ne sait pas vraiment où on va en fait, Dean & alias semblent plutôt prudents et évitent de s’engager sur des fonctionnalités. Ils ont une idée en tête, ça je n’en doute pas mais en fait on a pas une visibilité claire.

C’est ce qui avait fait monter un peu la pression d’ailleurs avec RC1, RC3 et une 1.0 qui se faisait attendre sans aucune date prévisionnelle. D’où la 4.0. Mais bon quand j’ai découvert txp il était en Gamma 1.18 mais cette gamma était moins buggée que bcp de Release Candidate chez d’autres :-p

Je pense qu’il manque un “go-to-guy” en ce qui concerne la communication du projet. Mais pour ça il faudrait que ce soit une des priorité ce qui ne semble pas le cas même si Zem est très présent dans ce domaine, sur les aspects techniques. Mais ça reste à un certain niveau difficile d’accès à l’utilisateur quidam… de ce point de vue, txp a un petit côté élitiste il faut l’admettre…

Je pense que contrairement à ce que je lis parfois, txp est déjà assez mature en tant que tel (en fait, ce qui fait dire qu’il ne l’est pas c’est le potentiel qu’il reste, énorme !). Ce qui l’est moins, c’est la doc… il faut vraiment qu’on booste là dessus.

Last edited by davidm (2005-09-23 13:38:20)

Melliw · 2005-09-23 14:13:48

>>C’est ce qui avait fait monter un peu la pression d’ailleurs avec RC1, RC3 et une 1.0 qui se faisait attendre >>sans aucune date prévisionnelle. D’où la 4.0.

Euh… moi je débarque directement pour Textpattern 4.0.1. Même en fouillant les annonces, je n’ai rien compris à la numérotation des version. RC3, RC4, RC5 puis Textpattern 4… Il a été décidé d’arrêter de présenter les versions comme RC et de les considérer comme “véritables” releases ?

>>Je pense que contrairement à ce que je lis parfois, txp est déjà assez mature en tant que tel (en fait, ce qui >>fait dire qu’il ne l’est pas c’est le potentiel qu’il reste, énorme !).

Pour ce que j’en ai vu, je suis assez d’accord.

Une chose m’a frappée dans les réponse de Zem :

“All of the comment database fields, including IP addresses, are available in the $thiscomment global. There’s no tag, but there’s no need for a SQL query either:
<txp:php>echo $GLOBALS['thiscomment']['ip'];</txp:php>
There’s no tag for precisely the reason you suggest: we make the data available so plugins can use it.”

Cela semble confirmer le sentiment que j’ai en voyant les plugins : un grand nombre de variables et de données sont accessibles et peuvent être exploitées dans les plugins (ou simplement récupérées en php). Mais pour l’utilisateur final qui n’est pas capable de mettre ses mains sous le capot, il reste bloqué tant que quelqu’un n’a pas développé un plugin lui convenant (donc rencontré un besoin similaire).

Bref, deux solutions pour contribuer à l’évolution :
- ressortir mes bouquins et tenter de mettre les mains sous le capot
- aider à la doc pour attirer du monde (peut-être capables de mettre les mains sous le capot)

Je crois que je vais choisir la seconde :D

davidm · 2005-09-23 14:21:06

Pour la petite histoire Dean a pris en compte les remarques de la communauté sur le fait que txp était largement “sous-numéroté” par rapport à sa maturité c’était déjà bien plus qu’une RC. Dean est un perfectionniste, il cherchait la 1.0 parfaite mais il a fini par “céder” et nous donner une numérotation “finale”, et au lieu de la nommer 1.0 comme il a un solide sens de l’humour et qu’il va avoir 40 ans, il a nommé la 1.0 finale : TXP 4.0 :-)

CQFD, mais c’est déroutant je te l’accorde. Sur la contrib à txp, je suis d’accord avec toi et moi aussi il me manque les compétences pour écrire des plugins ou faire du php, donc je contribue autrement. J’aurai bien appris php, mais je pense qu’il vaut mieux investir du temps à apprendre Ruby On Rails car c’est l’avenir :-)

D’ailleurs TextDrive est pionnier de l’hébergement ROR, c’est un signe…
Quand on voit Instiki, et surtout Basecamp, on comprend pourquoi c’est l’avenir. Et apparemment c’est plus facile à apprendre que php (ça reste à voir, j’ai commandé le bouquin je vous dirai ça…)

Last edited by davidm (2005-09-23 14:23:05)

Jeremie · 2005-09-23 16:11:21

Pour beaucoup, pas besoin de PHP. Les plugins sont un plus, mais pour la plupart des sites les besoins sont déjà remplis. A quelques exceptions près – mes vieilles rengaines et chevaux de bataille depuis des mois ;) .

Melliw · 2005-09-23 16:54:11

> Pour la petite histoire Dean a pris en compte les remarques de la communauté […]

Merci, je comprends mieux :)

> Les plugins sont un plus, mais pour la plupart des sites les besoins sont
> déjà remplis. A quelques exceptions près – mes vieilles rengaines et chevaux de bataille depuis des mois ;).

Je me permets d’avoir un doute en ce qui concerne les plugins. C’est quand même bien plus qu’un simple “plus” dans de nombreux cas. Et je ne cherche pas des fonctionnalités supplémentaires comme un calendrier ou autre.

Si on prend l’exemple des catégories :

<txp:category_list /> une fois qu’on lui retire ses attributs de mise en forme de la liste (wraptag, break, label et class) on n’a que deux attributs : type et parent.

Bref, pour afficher certaines catégories d’article de mon site, je n’ai qu’un attribut sur lequel jouer : “parent” qui ne m’offre pas énormément de choix.

Jeremie · 2005-09-23 16:58:11

Ca fait partie de mes “vieilles rengaines”, dont je parlais. Je tanne Dean, Zem et Pedro avec depuis pas mal de temps déjà ;)

En gros… une meilleur navigation frontend (ce dont tu parles), une gestion frontend des arborescences (parents/enfants) de catégories, les tags (au sens mots-clefs à la SPIP), et un couple worklflow+forums dans le backend (idem, à la SPIP), la transformation des URL en URI et la disparition des URL/URI “moches”, etc.

Last edited by Jeremie (2005-09-23 16:59:05)

davidm · 2005-09-23 17:03:29

<blockquote>Je me permets d’avoir un doute en ce qui concerne les plugins. C’est quand même bien plus qu’un simple “plus” dans de nombreux cas. Et je ne cherche pas des fonctionnalités supplémentaires comme un calendrier ou autre.</blockquote>

Je pense que là tu es donc d’accord avec Jérémie qui n’a à mon sens pas dit le contraire…

<blockquote>Si on prend l’exemple des catégories :

<txp:category_list /> une fois qu’on lui retire ses attributs de mise en forme de la liste (wraptag, break, label et class) on n’a que deux attributs : type et parent.

Bref, pour afficher certaines catégories d’article de mon site, je n’ai qu’un attribut sur lequel jouer : “parent” qui ne m’offre pas énormément de choix.</blockquote>

C’est vrai mais tu as plusieurs plugins comme

stw_category_tree étant sans aucun doute un des plus indipensable du lot…

Mais effectivement tous les besoins ne sont pas couverts par les plugins… le mieux étant de poster une plugin request sur le forum Plugins, dans le cas où tu as un besoin particulier..

Melliw · 2005-09-23 21:48:38

Au temps pour moi. Je n’avais pas pris la phrase de Jeremie tout à fait dans le bon sens :)

Avec les plugins existants on a en effet ce qu’il faut pour la majorité des sites.

transformation des URL en URI et la disparition des URL/URI “moches”

Qu’est-ce que tu entends par là ? (tout le reste j’ai compris :p)

Jeremie · 2005-09-23 23:02:47

Pour la disparition des URL “moches”: plus aucun ?truc=ploum&machin=carambar dans le frontend (dans un premier temps), sauf éventuellement pour les vraies url dynamiques (la recherche quoi) qui ne doivent de toutes façons pas être indexées. Ca concerne les flux XML (bien que récemment les ?atom= se sont transformés en /atom/ c’est déjà un mieux), les feuilles de styles, les catégories et sections (même si ca a partiellement disparu aussi), etc.

Pour la transformation des URL en URI, c’est plus complexe déjà. En gros a consiste à toujours fournir une URL unique pour une ressource donnée (la définition d’une URI quoi, cf le W3C), sauf rares cas purement dynamiques (encore une fois, la recherche). Exemple concret : ne plus générés d’URL /?pg=2 quand on remonte une liste d’article, mais par exemple générer une URI du type /page1/ puis incrémenter de page en page. Comme ça l’article n°78 sera par exemple systématiquement dans monsite.fr/masection/parcourir-page-3/ , même dans 1 mois, dans 1 an, dans 10 ans.

Je sais pas si je suis clair.

Ceci dit, le second point est secondaire, je m’étais un peu laissé emporté. Il y a nettement plus urgent à faire avant, comme les tags, ou la navigation propre facile et contextuelle.

Last edited by Jeremie (2005-09-23 23:05:08)

davidm · 2005-09-25 14:59:53

Je ne sais pas qui utilise encore les url moches, en dehors ce ceux qui sont sur des hébergements gratuits et qui n’ont pas accès à mod_rewrite (d’ailleurs, abandonner les url moches ne posera t-il pas un pb pour eux ?).

Pour ce qui est des URI, je ne suis pas aussi puriste même si c’est vrai il s’agit d’un véritable souci à intégrer. Pour ceux que ça intéresse ma page de référence sur le sujet est celle de websemantique.org sur les URI : http://websemantique.org/URI

Ca explique simplement ce concept complexe, je cite :

<blockquote>Dans la perspective d’un web sémantique, les choses doivent être clairement identifiées, sans quoi il n’est pas possible de partager l’information.
La notion de personne fournit un bon exemple : il existe par exemple des dizaines de François Martin en France ; comment décrire l’un d’eux sur le web, sans risquer de le confondre avec d’autres. La solution proposée par le web sémantique est d’associer un identifiant unique à chaque chose : il s’agit de l’URI (Uniform Resource Identifiers).</blockquote>

C’est la plus claire définition que j’ai trouvé du concept. L’exemple est lui aussi intéressant :

<blockquote>dans le web sémantique il faut donc écrire, par exemple (il existe d’autres solutions) :
http://example.org/Hommes/CharlesDeGaulle est un homme
et http://example.org/Bateaux/CharlesDeGaulle est un porte avion</blockquote>

Ca veut aussi dire que si on veut bien faire les choses, il faudra structurer les données intelligemment. Et aussi, que par rapport à textpattern le seul schéma d’url propre qui peut être considérée aujourd’hui comme une URI c’est une URI qui comporte forcémment l’ID de l’article (par définition unique). Ca veut dire soit section/id/titre soit id/titre Sachant que la première est la plus “signifiante” et proche de la sémantique.

Personnellement, je n’aime pas trop les urls avec des ID dedans, mais bon…

Last edited by davidm (2005-09-25 15:01:20)

Jeremie · 2005-09-25 22:20:40

Pour les URI, je n’irais pas aussi loin que d’appliquer du contenu sémantique à l’intérieur de l’URI. Pour moi, et pour le moment, c’est le boulot du contenu de la page, et de ses métadonnées. Je parlais plutôt de la disparition des urls du types /?pg=2 qui ne renvoient pas vers le même contenu au cours du temps.

Pour les urls “moches”, je parlais avec mod_rewrite bien sur. Je reformule : quand mod_rewrite est utilisé, en mode durl “propre”, l’on ne devrait plus avoir d’urls dites “moches”.

davidm · 2005-09-26 08:21:45

<blockquote>Jeremie wrote: Pour les URI, je n’irais pas aussi loin que d’appliquer du contenu sémantique à l’intérieur de l’URI. Pour moi, et pour le moment, c’est le boulot du contenu de la page, et de ses métadonnées. </blockquote>

Oui bien sûr là on tombe dans une forme de perfectionnisme, mais à vrai dire j’aime les url “signifiantes”.

Ceci dit, il y a probablement plus de boulot à faire sur les CMS en général et txp en particulier sur le balisage sémantique des contenus et les métadonnées. Je ne vais pas lancer un débat abstrait sur la sémantique ici, on pourrait presque lancer un autre fil pour ça, mais voici un article déjà ancien (2002) qui résume bien la problématique Sémantique <=> CMS : Smarter Content Publishing

<blockquote>Je parlais plutôt de la disparition des urls du types /?pg=2 qui ne renvoient pas vers le même contenu au cours du temps. Pour les urls “moches”, je parlais avec mod_rewrite bien sur. Je reformule : quand mod_rewrite est utilisé, en mode durl “propre”, l’on ne devrait plus avoir d’urls dites “moches”. </blockquote>

OK merci pour la précision j’avais compris de travers…

Textpattern CMS

Textpattern CMS support forum

#25 2005-09-23 13:36:12

Re: [fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

#26 2005-09-23 14:13:48

Re: [fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

#27 2005-09-23 14:21:06

Re: [fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

#28 2005-09-23 16:11:21

Re: [fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

#29 2005-09-23 16:54:11

Re: [fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

#30 2005-09-23 16:58:11

Re: [fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

#31 2005-09-23 17:03:29

Re: [fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

#32 2005-09-23 21:48:38

Re: [fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

#33 2005-09-23 23:02:47

Re: [fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

#34 2005-09-25 14:59:53

Re: [fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

#35 2005-09-25 22:20:40

Re: [fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

#36 2005-09-26 08:21:45

Re: [fr-fr] Annoncé la sortie de TXP 4.0 sur webmaster-hub

Board footer