headers
bertrand Gugger | 17 Apr 2007 01:20
Favicon

Re: un purgatoire pour la zone ?

nicolasriq@... wrote:
> Salut
> je jette cette idée au fil de l'eau, telle qu'est venue, avant de 
> l'oublier
> 
> En se baladant sur la zone il est facile de constater que certains 
> projets n'ont pas bougés depuis des lustres (donc sont forcément 
> déconnectés de la réalité de SPIP) voire sont très discutables dans 
> leur principe même (ou dans la pratique du projet) au regard du 
> contexte de SPIP (j'ai par exemple un à priori certain vis à vis de 
> trucs comme fck editor and co, mais peut-être n'ai je rien compris à ce 
> sujet).  En soi cela n'aurait pas beaucoup d'importance, sauf que : 
> cela consomme des ressources communautaires non inépuisables, et cela 
> créé amha un "bruit" préjudiciable à la lisibilité de la Zone, dont la 
> finalité on peut le supposer est bien de produire du code vivant et 
> pertinent pour SPIP dans un contexte de travail collaboratif (et non 
> pas de servir d'espace de stockage aux uns et aux autres).
> 
> D'ou l'idée qui m'est venue d'une sorte de répertoire(s) «purgatoire» 
> (ou des répertoires, un pour chacune des grandes divisions de la Zone) 
> dans laquelle seraient basculés les dits projets. Ensuite de deux 
> choses l'une : soit dans un délai raisonnable ils redressent la barre, 
> soit ils prennent la porte (variante éventuelle : certains pourraient 
> être conservés à titre «historique ?)».
> 
> Evidemment ce travail n'a d'interêt que si cela dégage de la ressource.

Evidemment, ça va encore jaser , on va encore dire que zone et contrib 
c'est main dans la main pour dominer le monde.
(Continue reading)

Permalink | Reply | 0 comments |
headers
spipcarto | 17 Apr 2007 01:43
Picon

tweaks et compatibilité des traitements

hello,
bon, du coup, j'ai regardé ce plugin, et je decouvre que les traitements 
sont réalisés en affectant table_des_traitements.
C'est donc incompatible avec toute utilisation de cette global, dommage....

pour empiler les traitements, il faudrait pouvoir produire dans 
mes_options :
$GLOBALS['table_des_traitements']['TEXTE'][]=$GLOBALS['table_des_traitements']['TEXTE']['']?'decouper_en_pages('.$GLOBALS['table_des_traitements']['TEXTE'][''].')':'decouper_en_pages(propre(%s))';

c'est ligne 181 de tweak_spip :
$temp = "\$GLOBALS['table_des_traitements']['$b'][]='" . join('(', 
$traitements_utilises[$b]).'%s';
$traitements_utilises[$b] = $temp . str_repeat(')', substr_count($temp, 
'(')) . "';";

Mais avec ces histoires de parentheses, je me prend la tete pour generer 
cette expression.

j'ai fait un truc en 2 temps :
        $temp = 
"\$tmp=\$GLOBALS['table_des_traitements']['$b']['']?\$GLOBALS['table_des_traitements']['$b']['']:'%s';";
        $temp .= "\$GLOBALS['table_des_traitements']['$b'][]='" . 
join('(', $traitements_utilises[$b])."'.\$tmp.'";
        $traitements_utilises[$b] = $temp . str_repeat(')', 
substr_count($temp, '(')) . "';";

mais il y a le probleme de propre qu'il ne faudrait pas passer 2 fois ...

du coup, je me dis qu'il vaudrait peut etre mieux en discuter avant de 
se prendre la tete...
(Continue reading)

Permalink | Reply | 4 comments |
headers
Pat | 17 Apr 2007 09:48
Favicon

Re: tweaks et compatibilité des traitements

spipcarto a écrit :
> hello,
> bon, du coup, j'ai regardé ce plugin, et je decouvre que les traitements 
> sont réalisés en affectant table_des_traitements.
> C'est donc incompatible avec toute utilisation de cette global, dommage....
Spip n'a pas dit son dernier mot...

> pour empiler les traitements, il faudrait pouvoir produire dans 
> mes_options :
> $GLOBALS['table_des_traitements']['TEXTE'][]=$GLOBALS['table_des_traitements']['TEXTE']['']?'decouper_en_pages('.$GLOBALS['table_des_traitements']['TEXTE'][''].')':'decouper_en_pages(propre(%s))';
quelle ligne ! d'ailleurs il faut [0] à la place de [''] semble-t-il...
après, bonjour l'ordre de passage pour les plugins...
Si j'ai bien compris, les plugins trifouillent $table_des_traitements 
dans un ordre pseudo-aléatoire, pouvant s'annuler les uns les autres, 
puis seulement après, include('public/interface') complète le reste...

> c'est ligne 181 de tweak_spip.php :
ligne 192 maintenant !

> $temp = "\$GLOBALS['table_des_traitements']['$b'][]='" . join('(', 
> $traitements_utilises[$b]).'%s';
> $traitements_utilises[$b] = $temp . str_repeat(')', substr_count($temp, 
> '(')) . "';";
>      
> Mais avec ces histoires de parentheses, je me prend la tete pour generer 
> cette expression.
> 
> j'ai fait un truc en 2 temps :
>         $temp = 
> "\$tmp=\$GLOBALS['table_des_traitements']['$b']['']?\$GLOBALS['table_des_traitements']['$b']['']:'%s';";
(Continue reading)

Permalink | Reply | 3 comments |
headers
cedric.morin-p6KLG6aqNT9BDgjK7y7TUQ@public.gmane.org | 17 Apr 2007 11:06
Gravatar

Re: r11357 - /_plugins_/_stable_/forms/forms_et_tables_1_9_1/public/forms_boucles.php

le commit est parti trop vite, avant que je corrige le commentaire :
(DONNEES) -> les donnees d'une table
(TABLE_CHAMPS) -> les champs d'une table
(DONNEE_CHAMPS) -> les valeur des champs pour une donnee (donc attention 
DONNEE au singulier, CHAMPS au pluriel)

voila ces nommages vont alleger l'ecriture
Par ailleurs, le formulaire de recherche sur les tables applique un AND 
entre les conditions des champs (il faut que le champ 1 ait telle valeur 
ET le champ 2 telle valeur)
Mais, attention tout de meme, sur les champs de type multiple, cela 
reste un OU entre les valeurs du meme champ (champ 1 ait telle ou telle 
valeur ET champ 2 aie telle valeur)

Pour etendre le formulaire de recherche à tous les types de 
champs(select,multiple, mot par defaut) il suffit de personaliser 
formulaires/forms_recherche dans son dossier squelette)

cedric@... a écrit :
> Author: cedric@...
> Date: Tue Apr 17 11:00:15 2007
> New Revision: 11357
>
> Log:
> "des alias DONNEES (au lieu de FORMS_DONNEES), TABLE_CHAMPS (au lieur de FORMS_CHAMPS) et
DONNEES_CHAMPS au lieu de (FORMS_DONNEES_CHAMPS)
> pour les skelette"
>
> Modified:
>     _plugins_/_stable_/forms/forms_et_tables_1_9_1/public/forms_boucles.php
(Continue reading)

Permalink | Reply | 2 comments |
headers
Philippe Drouot | 17 Apr 2007 11:50

Re: [Spip-zone-commit] r11357 - /_plugins_/_stable_/forms/forms_et_tables_1_9_1/public/forms_boucles.php

cedric.morin@... a écrit :
> ....
> Par ailleurs, le formulaire de recherche sur les tables applique un AND 
> entre les conditions des champs (il faut que le champ 1 ait telle valeur 
> ET le champ 2 telle valeur)
> Mais, attention tout de meme, sur les champs de type multiple, cela 
> reste un OU entre les valeurs du meme champ (champ 1 ait telle ou telle 
> valeur ET champ 2 aie telle valeur)
>
> Pour etendre le formulaire de recherche à tous les types de 
> champs(select,multiple, mot par defaut) il suffit de personaliser 
> formulaires/forms_recherche dans son dossier squelette)
>
>   
>> -					\$filtre .= " OR (dc.champ="._q(\$row['champ'])." AND dc.valeur IN (".implode(',',array_map('_q',\$r))."))";
>> +					\$filtre .= " AND (dc.champ="._q(\$row['champ'])." AND dc.valeur IN (".implode(',',array_map('_q',\$r))."))";
>>     
Bonjour,

Il me semble que transformer la recherche de OU en ET entre les champs 
d'un formulaire de recherche n'est pas si trivial : remplacer le OR par 
un AND entre les conditions ne marche que si on ne fait une recherche 
que sur UN SEUL champ du formulaire !

Dès lors que l'on spécifie plusieurs champs, on se retrouve avec des 
requêtes de type dc.champ='mot_1'  AND dc.champ='mot_2'  ce qui ne peut 
conduire à un résultat.
Il faudrait plutôt envisager de faire une requête sur 
forms_donnees_champs pour chacun des champs renseigné du formulaire  et 
de n'en tirer que l'intersection des résultats (ce qui devient plus
(Continue reading)

Permalink | Reply | 1 comment |
headers
cedric.morin-p6KLG6aqNT9BDgjK7y7TUQ@public.gmane.org | 17 Apr 2007 12:05
Gravatar

Re: [Spip-zone-commit] r11357 - /_plugins_/_stable_/forms/forms_et_tables_1_9_1/public/forms_boucles.php

Philippe Drouot a écrit :
> cedric.morin@... a écrit :
>   
>> ....
>> Par ailleurs, le formulaire de recherche sur les tables applique un AND 
>> entre les conditions des champs (il faut que le champ 1 ait telle valeur 
>> ET le champ 2 telle valeur)
>> Mais, attention tout de meme, sur les champs de type multiple, cela 
>> reste un OU entre les valeurs du meme champ (champ 1 ait telle ou telle 
>> valeur ET champ 2 aie telle valeur)
>>
>> Pour etendre le formulaire de recherche à tous les types de 
>> champs(select,multiple, mot par defaut) il suffit de personaliser 
>> formulaires/forms_recherche dans son dossier squelette)
>>
>>   
>>     
>>> -					\$filtre .= " OR (dc.champ="._q(\$row['champ'])." AND dc.valeur IN (".implode(',',array_map('_q',\$r))."))";
>>> +					\$filtre .= " AND (dc.champ="._q(\$row['champ'])." AND dc.valeur IN (".implode(',',array_map('_q',\$r))."))";
>>>     
>>>       
> Bonjour,
>
> Il me semble que transformer la recherche de OU en ET entre les champs 
> d'un formulaire de recherche n'est pas si trivial : remplacer le OR par 
> un AND entre les conditions ne marche que si on ne fait une recherche 
> que sur UN SEUL champ du formulaire !
>
> Dès lors que l'on spécifie plusieurs champs, on se retrouve avec des 
> requêtes de type dc.champ='mot_1'  AND dc.champ='mot_2'  ce qui ne peut
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Christophe Sekinger | 17 Apr 2007 13:22
Picon
Favicon
Gravatar

[Fwd: [Spip] tweakspip]


-------- Message original --------
Sujet: 	[Spip] tweakspip
Date: 	Tue, 17 Apr 2007 11:44:46 +0200
De: 	Jean-Christophe Sekinger <jc.sekinger@...>
Pour: 	SPIP <spip@...>

super couteau-suisse (comme je l'ai dit je ne sais plus où) mais je 
viens de voir une chose sur une 1.9.2a, firebug détecte deux erreurs 
dans la page article:
missing ) after argument list
helpline('Insérer un E dans l'O',document.getElementById('barre_1'))
spip.php (line 1)
missing ) after argument list
helpline('Insérer un E dans l'O 
majuscule',document.getElementById('barre_1'))

à bon entendeur (moi je n'y connais rien)

--

-- 
Jean-Christophe
Permalink | Reply | 6 comments |
headers
spipcarto | 17 Apr 2007 14:08
Picon

Re: tweaks et compatibilité des traitements

Pat a écrit :
> spipcarto a écrit :
>   
>> hello,
>> bon, du coup, j'ai regardé ce plugin, et je decouvre que les traitements 
>> sont réalisés en affectant table_des_traitements.
>> C'est donc incompatible avec toute utilisation de cette global, dommage....
>>     
> Spip n'a pas dit son dernier mot...
>
>   
>> pour empiler les traitements, il faudrait pouvoir produire dans 
>> mes_options :
>> $GLOBALS['table_des_traitements']['TEXTE'][]=$GLOBALS['table_des_traitements']['TEXTE']['']?'decouper_en_pages('.$GLOBALS['table_des_traitements']['TEXTE'][''].')':'decouper_en_pages(propre(%s))';
>>     
> quelle ligne ! d'ailleurs il faut [0] à la place de [''] semble-t-il...
> après, bonjour l'ordre de passage pour les plugins...
>   
ben non, on empile dans l'ordre de chargement, c'est la meme logique que 
pre_propre/post_propre
Mais il faut que les utilisateurs de table_des_traitements pensent à 
empiler au lieu d'ecraser ce qui est passé avant....

> Si j'ai bien compris, les plugins trifouillent $table_des_traitements 
> dans un ordre pseudo-aléatoire, pouvant s'annuler les uns les autres, 
> puis seulement après, include('public/interface') complète le reste...
>   
si j'ai bien compris, les fichiers options sont chargés en premier puis, 
au recalcul, les fichiers fonctions le tout dans l'ordre du path.
L'ordre en gros, c'est /squelettes puis les plugins dans l'ordre alpha
(Continue reading)

Permalink | Reply | 2 comments |
headers
Fil | 17 Apr 2007 14:36
Favicon
Gravatar

Re: [SPIP Zone] tweaks et compatibilité des traitements

> > D'ailleurs, je viens de m'apercevoir que la bonne syntaxe est plutot :
> > supprimer_numero(typo(%s)), non ?

Ah ben non, parce que |supprimer_numero ça sert à supprimer le numéro
qui permet de trier dans MySQL. Et donc il est au début du champ
texte, avant tout traitement typographique.

Par exemple titre = "1. <multi>x[ar]y</multi>"

> >> Est ce que ca ne devrait pas plutot etre à spip de gerer plusieurs
> >> traitements ?

Oui, je pense aussi qu'il faudra faire une vraie API pour ça ; mais il
faut avoir d'abord une vision claire des besoins, ce n'était pas le
cas lors de l'introduction de avant_propre, puis de
table_des_traitements.

-- Fil
Permalink | Reply | 1 comment |
headers
bruno bergot | 17 Apr 2007 14:40
Picon

Re: [Fwd: [Spip] tweakspip]

Bonjour, je crois que cette erreur a déjà été corrigée ici :

http://trac.rezo.net/trac/spip/changeset/8865

Le 17/04/07, Jean-Christophe Sekinger<jc.sekinger@...> a écrit :
>
>
> -------- Message original --------
> Sujet:  [Spip] tweakspip
> Date:   Tue, 17 Apr 2007 11:44:46 +0200
> De:     Jean-Christophe Sekinger <jc.sekinger@...>
> Pour:   SPIP <spip@...>
>
>
>
> super couteau-suisse (comme je l'ai dit je ne sais plus où) mais je
> viens de voir une chose sur une 1.9.2a, firebug détecte deux erreurs
> dans la page article:
> missing ) after argument list
> helpline('Insérer un E dans l'O',document.getElementById('barre_1'))
> spip.php (line 1)
> missing ) after argument list
> helpline('Insérer un E dans l'O
> majuscule',document.getElementById('barre_1'))
>
> à bon entendeur (moi je n'y connais rien)
>
>
>
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane