[spip-dev] Quelques remarques...

Bonjour,

Tout d'abord bravo pour tout le boulot SPIP, c'est assez génial et ça
fonctionne plutôt très bien.
Normalement j'aime pas les content-manager car trop figés dans leur
structure, mais là je dois avouer qu'on peut faire ce qu'on veut.

Je suis en train de faire un squelette et j'ai noté un truc ou deux,
ayant eu à aller trifouiller le code.

Les caractères comme le é, à, è etc.. sont remplacés par des
caractères étranges (vu dans inc.formulaires).
Certains fichiers sont également en double interlignage (typique de
certains éditeurs sur win qui enregistrent pas au format unix).

Ma principale critique porte sur le code HTML. Dans les squelettes,
c'est pas gênant puisqu'on a la main dessus. Par contre j'ai vu dans
le code (inc.formulaires) que vous passiez des classes du type
truc_truc. Juste pour info, le '_' ne passe pas avec Netscape, et est
d'ailleur interdit dans tout attribut HTML (normalement).

Si vous le souhaitez je peux vous envoyer la page avec les modifs, ou
si vous avez un CVS...

Concernant le backoffice, je trouve ça très beau mais un peu lourd et
lent. Alors c'est vrai qu'on ne peut rien aux bases de données d'un
serveur mais par contre, toutes ces images sont elles vraiment
nécessaires ? :wink:

Voilà pour mes quelques remarques qui ne doivent pas occulter que je
suis comblé par la gestion des articles, des brèves et la syndication
de sites (c'est vraiment génial ça!).

Encore bravo pour ce boulot qui doit être assez monstrueux :slight_smile:

PS: j'espère que j'envoie ça à la bonne adresse, j'ai pas trouvé de
mail direct vers un développeur de SPIP.

à bientôt et bon courage.

Salut,

Les caractères comme le é, à, è etc.. sont remplacés par des
caractères étranges (vu dans inc.formulaires).

Ton client FTP a mal fait son boulot.... Change le réglage
binaire / ascii :wink:

Certains fichiers sont également en double interlignage (typique de
certains éditeurs sur win qui enregistrent pas au format unix).

Ou typique de certains éditeurs Unix qui ne gèrent pas correctement
les fichiers issus de Windows :slight_smile: Personnellement je suis sous Windows,
et les deux autres développeurs sous Mac. Avec de bons éditeurs, on
arrive à se débrouiller....

Ma principale critique porte sur le code HTML. Dans les squelettes,
c'est pas gênant puisqu'on a la main dessus. Par contre j'ai vu dans
le code (inc.formulaires) que vous passiez des classes du type
truc_truc. Juste pour info, le '_' ne passe pas avec Netscape, et est
d'ailleur interdit dans tout attribut HTML (normalement).

??? C'est bizarre, tu veux dire que <p class="spip_texte"> ne serait
pas conforme HTML ??

Alors c'est vrai qu'on ne peut rien aux bases de données d'un
serveur mais par contre, toutes ces images sont elles vraiment
nécessaires ? :wink:

Pas forcément, c'est vrai... :wink:

http://www.apinc.org <- pas en SPIP (!)

SPIP marche chez vous ?

Amicalement

Antoine.

Salut,

Quelques modifs dans l'espace public pour permettre l'inclusion
de squelettes comme on l'avait prévue (fonctionnement de cache
découplé, etc).

Pour l'instant la seule façon de faire est d'écrire l'include
PHP en passant le contexte à la main, par exemple :

<?php $contexte['id_rubrique'] = $id_rubrique; include("machin.php3"); ?>

Où machin.php3 est une page SPIP standard avec la définition de
$fond et $delais, et l'appel de inc-public.

Il faudra donc ajouter une nouvelle balise pour l'inclusion (quand
j'aurai suffisamment de courage...). Je penche pour un truc du genre :

<INCLURE(machin.php3) {id_rubrique}>

La mention explicite des paramètres à passer au squelette est obligatoire,
sinon il va y avoir des tas d'instances différentes dans le cache.
Par exemple si je fais un squelette séparé pour l'affichage de la hiérarchie
en haut, et que je l'appelle depuis chaque squelette article, il ne faut
pas que deux articles de la même rubrique créent deux fichiers différents
dans le cache sous prétexte que l'id_article est différent.

Alors que si le webmestre spécifie quels paramètres transmettre, ça
contrôle aussi le nommage du fichier cache.

J'ai pas testé plus loin, mais l'inclusion récursive, du même ou de
plusieurs squelettes, ne devrait poser aucun problème.

a+

Antoine.

>Les caractères comme le é, à, è etc.. sont remplacés par des
>caractères étranges (vu dans inc.formulaires).

Ton client FTP a mal fait son boulot.... Change le réglage
binaire / ascii :wink:

Euh, normalement on avait décidé de ne pas laisser traîner d'accents dans
les fichiers, par le recours aux &eacute; quand c'est possible, et aux
chr(xx) sinon.

Pour mémoire, j'en trouve là :

inc-formulaires.php3
ecrire/document_edit.php3
ecrire/inc_mail.php3
ecrire/mots_type.php3

-- Fil

Salut,

> Certains fichiers sont également en double interlignage (typique de
> certains éditeurs sur win qui enregistrent pas au format unix).
Ou typique de certains éditeurs Unix qui ne gèrent pas correctement
les fichiers issus de Windows :slight_smile: Personnellement je suis sous Windows,
et les deux autres développeurs sous Mac. Avec de bons éditeurs, on
arrive à se débrouiller....

Yop. Dans tous les cas, sous unix, un coup d'expression régulière pour
remplacer les fins de ligne comme il faut, ou un cou pde emacs règle le
problème.
En fait, ça apparaît quand un fichier d'une plateforme est éditée sur
une autre, et modifiée. Le truc qui va le lire va rencontrer deux
méthodes pour marque la fin de ligne (entre CR, LF, CR+LF) et se
planter.

> truc_truc. Juste pour info, le '_' ne passe pas avec Netscape, et est
> d'ailleur interdit dans tout attribut HTML (normalement).

??? C'est bizarre, tu veux dire que <p class="spip_texte"> ne serait
pas conforme HTML ??

Tiens ça expliquerait des choses avec netscape 4.X...

http://www.blooberry.com/indexdot/css/syntax/selectors/spechtml.htm

- Netscape 4.x does not allow CLASS or ID attributes to contain
  underscore characters ("_".) Underscores are legal in HTML atributes
  according to the HTML standards but not according to the CSS standard.

grmbl...

Je ne suis pas d'accord avec toi, dans la mesure où un simple changement
de nom dans les styles permettrait de résoudre le pb...

Hum hum ...

J'ai écrit un modeste article sur le sujet.
[http://perline.org/article.php3?id_article=44] (et puis allez voir
ma page d'accueil d'aujourd'hui...)

Voici ta page d'accueil en 1024x768 avec Mozilla 1.0 RC1 avec la
taille de police par défaut :
http://www.gasteroprod.com/perline.png

Est-ce bien sérieux ... :stuck_out_tongue:

-Nicolas

J'ai écrit un modeste article sur le sujet.
[http://perline.org/article.php3?id_article=44] (et puis allez voir

Voici ta page d'accueil en 1024x768 avec Mozilla 1.0 RC1 avec la
taille de police par défaut :
http://www.gasteroprod.com/perline.png

Passe très bien chez moi: même navigateur même version (MacOS X)

Guillaume

Passe très bien chez moi: même navigateur même version (MacOS X)

Je suis sur Win2k

-Nicolas

Non, vraiment pas...

Euh, ça va mieux là ou pas ?

Tu me passes le lien de ton navigateur que je teste avec dorénavant ?

Hello,

[inclusion de squelettes]
Pour l'instant la seule façon de faire est d'écrire l'include PHP en
passant le contexte à la main, par exemple :
<?php
$contexte['id_rubrique'] = $id_rubrique;
include("machin.php3");
?>

Quand j'essaie de faire ça, je me retrouve avec la valeur de $fond
affichée au niveau de chaque include, en plus de l'include qui
fonctionne pourtant bien.

Je suis sur la dernière version CVS, sur un site qui n'est
malheureusement pas accessible en ligne ...

-Nicolas

[je reposte car bizarrement le message précédent a l'air vide.
on dirait un (autre) bug de Mozilla...]

Salut,

> Quand j'essaie de faire ça, je me retrouve avec la valeur de $fond
> affichée au niveau de chaque include, en plus de l'include qui
> fonctionne pourtant bien.

Normal, c'est une indication de debug (hum).
Tu peux la virer au début de inc-public.php3, ligne 10.

> Mêmes symptomes chez moi, avec Mozilla 1.0RC1 sur Windows 2000 ...

Forcément, c'est la même version :slight_smile:

a+

Antoine.

Une instruction de debug dans un code destiné à des sites en
production ?

Euh ... je blague, hein, je sais que ce n'est qu'une beta... :wink:

-Nicolas