[spip-dev] Fonction spip_apres_typo()

Bonjour tout le monde,

A la ligne 157 de ecrire/inc_texte.php3, dans la fonction
spip_apres_typo(), si la fonction apres_typo() existe, on retourne le
résultat tout de suite :

return apres_typo ($letexte);

ce qui a pour conséquence de ne pas exécuter les 5 lignes suivantes
(dont la fonction "revision_nbsp").

Ne serait-il pas préférable de remplacer cette ligne par

$letexte = apres_typo ($letexte);

François

A la ligne 157 de ecrire/inc_texte.php3, dans la fonction
spip_apres_typo(), si la fonction apres_typo() existe, on retourne le
résultat tout de suite :

return apres_typo ($letexte);

ce qui a pour conséquence de ne pas exécuter les 5 lignes suivantes
(dont la fonction "revision_nbsp").

Oui, ça te permet de faire ta propre fonction de revision_nbsp :slight_smile:

-- Fil

> A la ligne 157 de ecrire/inc_texte.php3, dans la fonction
> spip_apres_typo(), si la fonction apres_typo() existe, on
retourne le
> résultat tout de suite :
>
> return apres_typo ($letexte);
>
> ce qui a pour conséquence de ne pas exécuter les 5 lignes suivantes
> (dont la fonction "revision_nbsp").

Oui, ça te permet de faire ta propre fonction de revision_nbsp :slight_smile:

Ah, ok (même si je vois pas trop l'utilité).

Ca vaudrait la peine de le documenter alors. Parce que sans cela, quand
on a créé un fonction apres_typo() pour autre chose, on met un peu de
temps à comprendre la raison pour laquelle "revision_nbsp" ne fonctionne
pas.

François

> > ce qui a pour conséquence de ne pas exécuter les 5 lignes suivantes
> > (dont la fonction "revision_nbsp").
>
> Oui, ça te permet de faire ta propre fonction de revision_nbsp :slight_smile:

Ah, ok (même si je vois pas trop l'utilité).

Ca vaudrait la peine de le documenter alors. Parce que sans cela, quand
on a créé un fonction apres_typo() pour autre chose, on met un peu de
temps à comprendre la raison pour laquelle "revision_nbsp" ne fonctionne
pas.

On peut changer de logique, hein, ça n'a pas grand importance à ce stade.
Le seul truc éventuellement problématique c'est la conversion des ' en
’, qu'on peut vouloir éviter.

A ce compte-là, il faudrait inverser l'ordre :

        // caracteres speciaux
        $letexte = corriger_caracteres($letexte);
        $letexte = str_replace("'", "’", $letexte);

        // relecture des  
        if ($GLOBALS['flag_ecrire'] AND $GLOBALS['revision_nbsp'])
                $letexte = ereg_replace('&nbsp;', '<span class="spip-nbsp">&nbsp;</span>', $letexte);

        if (@function_exists('apres_typo'))
                return apres_typo ($letexte);
        
-- Fil

Oui, ça te permet de faire ta propre fonction de revision_nbsp :slight_smile:

S'il faut conserver une personnalisation possible de la révision des
insécables, on peut faire en plus un truc du genre :

  if (!@function_exists('revision_nbsp') AND
$GLOBALS['flag_ecrire'] AND $GLOBALS['revision_nbsp'])
    $letexte = ereg_replace('&nbsp;', '<span
class="spip-nbsp">&nbsp;</span>', $letexte);
  else
    $letexte = revision_nbsp($letexte);

En séparant la révision (à mettre dans une fonction optionelle
revision_nbsp() dans mes_options.php3) de apres_type(), ce qui est plus
propre.

François

S'il faut conserver une personnalisation possible de la révision des
insécables, on peut faire en plus un truc du genre :

Euh, non, non, je plaisantais, pas la peine de charger encore le code ; la
fonction apres_typo() fait ce qu'elle veut, y compris nettoyer le résultat
de la révision nbsp (??) ; dans l'autre sens c'était impossible.

-- Fil

Bon aucun des dev n'est intéressé pour donner son avis par rapport à modifie
que j'ai faite?

pour infos:
Pour etre conforme avec les normes wai j'ai dut rajouter des balises
fieldset sur lequel j'applique un class=spip_encadrer pour être compatible
avec la version d'avant mais ne vaut il pas mieux definir un style pour la
balise fieldset tout court ou fieldset.spip comme il est fait pour les
autres balise html stylé spip.

Autre point j'ai également rajouter des <legend>texte </legend> pour titer
les formulaires il faudrait voir à discuter leur nécessité, leur intitulé et
les mettre dans le mécanisme d'internationalisation.

Sur les champ input et textaera j'ai pour l'instant des attributs id et name
(est ce conforme xhtml strict?), id me sert pour les lier au balise <label>,
est ce que je peux virer name et mettre la valeur de cette attribt sur id
qui pour l'instant est codé en dur

J'ai viré les balises strong car c'est de la présentation est peu maintenant
etre fait dans le css

j'ai toujours le zip au cas ou sa interesse finalement qqun

aurelien levy wrote:

Bon aucun des dev n'est intéressé pour donner son avis par rapport à
modifie que j'ai faite?
j'ai toujours le zip au cas ou sa interesse finalement qqun

Moi, ça m'intéresse !
Fieldset et legend, j'aime !
Jacques - www.pyrat.net

Je suis aussi très interessé.
Ca a l'air nickel et le code est propre, alors ...

Sur les champ input et textaera j'ai pour l'instant des attributs id et

name

(est ce conforme xhtml strict?), id me sert pour les lier au balise

<label>,

est ce que je peux virer name et mettre la valeur de cette attribt sur id
qui pour l'instant est codé en dur

je ne sais pas pour la conformité, mais pour la compatibilité, c'est mieux.
Il y a encore pas mal de script qui utilisent le getElementById

J'ai viré les balises strong car c'est de la présentation est peu

maintenant

etre fait dans le css

Entierement d'accord

j'ai toujours le zip au cas ou sa interesse finalement qqun

j'ai celui que tu as fait passer sur la liste le 16, pas d'évolutions depuis
?
Je teste ca dès que possible.
Merci à toi pour ce boulot.

PS : Pour etre vraiment integrable, il faut internationnaliser les libellés,
non ?