2) ça se code (de manièresécurisée) en 30 minutes avec 1 seule table (voire deux si on veut
avoir un accès avec login/pass).
Je maintiens. Le codage c'est du PHP. Y'en a pour 30 minutes pour un
Bien sûr ! Avec la bonne convivialité des machins atroces que l'on
voyait il y a 10 ans.
L'ergonomie et la convivialité sont ce qui a permis à internet de se
démocratiser.
2) ça se code (de manière
sécurisée) en 30 minutes avec 1 seule table (voire deux si on veut
avoir un accès avec login/pass).
Je maintiens. Le codage c'est du PHP. Y'en a pour 30 minutes pour un
Bien sûr ! Avec la bonne convivialité des machins atroces que l'on
voyait il y a 10 ans.
L'ergonomie et la convivialité sont ce qui a permis à internet de se
démocratiser.
2) ça se code (de manièresécurisée) en 30 minutes avec 1 seule table (voire deux si on veut
avoir un accès avec login/pass).
Je maintiens. Le codage c'est du PHP. Y'en a pour 30 minutes pour un
Bien sûr ! Avec la bonne convivialité des machins atroces que l'on
voyait il y a 10 ans.
L'ergonomie et la convivialité sont ce qui a permis à internet de se
démocratiser.
Au passage je te rappelle que ma demande concernait avant tout la
qualité du HTML produit (HTML 4.01 strict étant le graal),
Quel rapport avec PHP ? Je parle de programmation, pas de rendu
(séparation code/présentation, tout ça...)plus complète séparation possible entre structure et présentation
(avec CSS).
Donc PHP N'a rien à voir dans cette partie là.
Au passage je te rappelle que ma demande concernait avant tout la
qualité du HTML produit (HTML 4.01 strict étant le graal),
Quel rapport avec PHP ? Je parle de programmation, pas de rendu
(séparation code/présentation, tout ça...)
plus complète séparation possible entre structure et présentation
(avec CSS).
Donc PHP N'a rien à voir dans cette partie là.
Au passage je te rappelle que ma demande concernait avant tout la
qualité du HTML produit (HTML 4.01 strict étant le graal),
Quel rapport avec PHP ? Je parle de programmation, pas de rendu
(séparation code/présentation, tout ça...)plus complète séparation possible entre structure et présentation
(avec CSS).
Donc PHP N'a rien à voir dans cette partie là.
J'utilise en validation d'input la fonction que je donne en exemple dans
les docs que je diffuse sur www.saphirtech.com, en interdisant sans
réfléchir tout tag HTML avec strip tags, ou en traduisant toutes lse
entitées html.On peut ici utiliser les sessions natives PHP pour ne pas
se trimballer le login/pass dans toutes les requêtes.
Il est 14h18, soit 8 minutes pour écrire ça.
Un peu de PHP autour
J'utilise en validation d'input la fonction que je donne en exemple dans
les docs que je diffuse sur www.saphirtech.com, en interdisant sans
réfléchir tout tag HTML avec strip tags, ou en traduisant toutes lse
entitées html.On peut ici utiliser les sessions natives PHP pour ne pas
se trimballer le login/pass dans toutes les requêtes.
Il est 14h18, soit 8 minutes pour écrire ça.
Un peu de PHP autour
J'utilise en validation d'input la fonction que je donne en exemple dans
les docs que je diffuse sur www.saphirtech.com, en interdisant sans
réfléchir tout tag HTML avec strip tags, ou en traduisant toutes lse
entitées html.On peut ici utiliser les sessions natives PHP pour ne pas
se trimballer le login/pass dans toutes les requêtes.
Il est 14h18, soit 8 minutes pour écrire ça.
Un peu de PHP autour
Oui ici c'est un forum PHP et pas un forum dédié à HTML et CSS.
On est bien d'accord.
Mais PHP sert à produire du HTML.
Non.
HTML est sensé être utilisé pour définir la structure des données et la
présentation est sensée être laissée à CSS.
Ne jouons pas avec les mots : HTML ou CSS je m'en fous, on définit des
Donc je cherchais un forum codé en PHP mais avec certaines exigences
côté HTML.
Libre à toi. Ce que j'en ai dit, c'est que la partie PHP se code en deux
Et ça a tout à voir avec PHP, parce que produit du HTML.
Non.
Quant à ton exemple de BB, je ne peux pas l'utiliser car il manque...
tout.
J'ai juste décortiqué un problème basique en donnant une solution
Dans ton script il manque HTML et CSS,
Cette phrase est une horreur. Non seulement je n'ai pas écrit de
une des composantes du problème, indissociable de PHP.
Une des composantes hors charte de ton problèe, qui n'a rien à voir avec
Nous ne sommes pas non plus sur un forum MySQL.
PHP ne fera que de l'interaction bête avec un SGBD. Si je ne te donne
Oui ici c'est un forum PHP et pas un forum dédié à HTML et CSS.
On est bien d'accord.
Mais PHP sert à produire du HTML.
Non.
HTML est sensé être utilisé pour définir la structure des données et la
présentation est sensée être laissée à CSS.
Ne jouons pas avec les mots : HTML ou CSS je m'en fous, on définit des
Donc je cherchais un forum codé en PHP mais avec certaines exigences
côté HTML.
Libre à toi. Ce que j'en ai dit, c'est que la partie PHP se code en deux
Et ça a tout à voir avec PHP, parce que produit du HTML.
Non.
Quant à ton exemple de BB, je ne peux pas l'utiliser car il manque...
tout.
J'ai juste décortiqué un problème basique en donnant une solution
Dans ton script il manque HTML et CSS,
Cette phrase est une horreur. Non seulement je n'ai pas écrit de
une des composantes du problème, indissociable de PHP.
Une des composantes hors charte de ton problèe, qui n'a rien à voir avec
Nous ne sommes pas non plus sur un forum MySQL.
PHP ne fera que de l'interaction bête avec un SGBD. Si je ne te donne
Oui ici c'est un forum PHP et pas un forum dédié à HTML et CSS.
On est bien d'accord.
Mais PHP sert à produire du HTML.
Non.
HTML est sensé être utilisé pour définir la structure des données et la
présentation est sensée être laissée à CSS.
Ne jouons pas avec les mots : HTML ou CSS je m'en fous, on définit des
Donc je cherchais un forum codé en PHP mais avec certaines exigences
côté HTML.
Libre à toi. Ce que j'en ai dit, c'est que la partie PHP se code en deux
Et ça a tout à voir avec PHP, parce que produit du HTML.
Non.
Quant à ton exemple de BB, je ne peux pas l'utiliser car il manque...
tout.
J'ai juste décortiqué un problème basique en donnant une solution
Dans ton script il manque HTML et CSS,
Cette phrase est une horreur. Non seulement je n'ai pas écrit de
une des composantes du problème, indissociable de PHP.
Une des composantes hors charte de ton problèe, qui n'a rien à voir avec
Nous ne sommes pas non plus sur un forum MySQL.
PHP ne fera que de l'interaction bête avec un SGBD. Si je ne te donne
Réaction typique à des concepts de base :
Sécurité à outrance pour corriger des failles qui n'en sont pas.
Le meilleur moyen de faire cela
Un moyen de faire cela. Je crois d'ailleurs que j'ai oublié d'en causer,
On insère les données dans un document HTML => on transforme les données
en noeud texte HTML,
Bah voyons. Et puis on fait aussi appel à trois couches dom-xml et 2
Apparemment, au moment de récupérer les données extérieures, tu
conseilles de leur ajouter des slashes,
Non. D'échapper les caractères dangereux pour le SGBDR, qui, comme tu le
encoder leurs caractères spéciaux HTML
Oui.
et tout un tas d'autres caractères, enlever les caractères
dits "dangereux"
T'as lu ça où ? Tu n'as toujours rien compris à un principe de base : si
(non seulement ils ne le sont pas, mais ils pourraient
avoir été saisis simplement pour être affichés comme corps du
message)...
Tu parles, comme d'habitude, dans le vide. Ou ces caractères n'ont RIEN
cela ne fait que corrompre les données et les rendre
encodées en un format difficilement manipulable.
On s'en branle, on va ***pas*** les manipuler.
Bref, impossible d'utiliser correctement les fonctions de traitement de
chaînes que ce soit en PHP ou SQL.
Deuxième édition : on s'en branle.
Ah oui, autre chose : à ma connaissance, le spoofing d'IP n'est pas
possible avec TCP. Aurais-tu plus d'informations à ce sujet ?
Oui enfin, soyons honnêtes, c'est pas la fête.
Ça fait plus livre d'or du site à neuneu.
Déjà les tables, il faudrait, selon moi :
users : définition des utilisateurs
Et la table access_bb elle sent le pâté ? Quant à appeler une table
groups : définition des différents groupes, et de leur droits
(facultatif, on peut faire ça en dur, mais ça limite en fonctionnalité)
forums : arbre des forums et sous-forums
messages : arbre des messages et de leurs réponses
Personnellement j'aime l'idée de lier les messages aux forums via une
table supplémentaire, ce qui permet de lier les messages à plusieurs
forums en même temps en divers points (pratique pour le cross-post et le
fu2, car on manipule le même message et pas une copie).
Autre chose : les arbres sous forme de listes adjacentes, en SQL, c'est
pas terrible.
Pas terrible du tout même pour cette utilisation je dirais.
Mieux vaut utiliser un bon format d'arbre comme les Nested Sets sur
lequel on pourra faire des modifications avec des classes adaptées
Pour la modération, je préfère donner à chaque utilisateur et à chaque
groupe des droits.
Oui c'est en effet possible.
Un truc un peu comme les droits UNIX me semble sympa.
Là je confirme, il n'y a pas mieux.
Rien qu'avant de commencer à écrire la moindre ligne, il faut créer le
framework de l'application.
On voit tout de suite pas mal de composants nécessaires :
On voit surtout que tu es très fort pour compliquer à outrance un truc
Il faut aussi créer un design pas trop moche via CSS pour que le forum
soit agréable à utiliser.
Non. Ca c'est pas du développement, c'est du graphisme. Et c'est pas
À moins de réutiliser du bon code déjà développé
Crois-tu que je recommence à zéro à chaque nouveau projet ? J'ajouterais
(et le bon code php est rare),
En effet. Même que m'est idée que nous n'avons aps tous les deux la même
fiable, évolutif, maintenable et utilisé par de nombreuses personnes.
Ca se code en 30 minutes, je maintiens, pour la partie PHP, par un
Réaction typique à des concepts de base :
Sécurité à outrance pour corriger des failles qui n'en sont pas.
Le meilleur moyen de faire cela
Un moyen de faire cela. Je crois d'ailleurs que j'ai oublié d'en causer,
On insère les données dans un document HTML => on transforme les données
en noeud texte HTML,
Bah voyons. Et puis on fait aussi appel à trois couches dom-xml et 2
Apparemment, au moment de récupérer les données extérieures, tu
conseilles de leur ajouter des slashes,
Non. D'échapper les caractères dangereux pour le SGBDR, qui, comme tu le
encoder leurs caractères spéciaux HTML
Oui.
et tout un tas d'autres caractères, enlever les caractères
dits "dangereux"
T'as lu ça où ? Tu n'as toujours rien compris à un principe de base : si
(non seulement ils ne le sont pas, mais ils pourraient
avoir été saisis simplement pour être affichés comme corps du
message)...
Tu parles, comme d'habitude, dans le vide. Ou ces caractères n'ont RIEN
cela ne fait que corrompre les données et les rendre
encodées en un format difficilement manipulable.
On s'en branle, on va ***pas*** les manipuler.
Bref, impossible d'utiliser correctement les fonctions de traitement de
chaînes que ce soit en PHP ou SQL.
Deuxième édition : on s'en branle.
Ah oui, autre chose : à ma connaissance, le spoofing d'IP n'est pas
possible avec TCP. Aurais-tu plus d'informations à ce sujet ?
Oui enfin, soyons honnêtes, c'est pas la fête.
Ça fait plus livre d'or du site à neuneu.
Déjà les tables, il faudrait, selon moi :
users : définition des utilisateurs
Et la table access_bb elle sent le pâté ? Quant à appeler une table
groups : définition des différents groupes, et de leur droits
(facultatif, on peut faire ça en dur, mais ça limite en fonctionnalité)
forums : arbre des forums et sous-forums
messages : arbre des messages et de leurs réponses
Personnellement j'aime l'idée de lier les messages aux forums via une
table supplémentaire, ce qui permet de lier les messages à plusieurs
forums en même temps en divers points (pratique pour le cross-post et le
fu2, car on manipule le même message et pas une copie).
Autre chose : les arbres sous forme de listes adjacentes, en SQL, c'est
pas terrible.
Pas terrible du tout même pour cette utilisation je dirais.
Mieux vaut utiliser un bon format d'arbre comme les Nested Sets sur
lequel on pourra faire des modifications avec des classes adaptées
Pour la modération, je préfère donner à chaque utilisateur et à chaque
groupe des droits.
Oui c'est en effet possible.
Un truc un peu comme les droits UNIX me semble sympa.
Là je confirme, il n'y a pas mieux.
Rien qu'avant de commencer à écrire la moindre ligne, il faut créer le
framework de l'application.
On voit tout de suite pas mal de composants nécessaires :
On voit surtout que tu es très fort pour compliquer à outrance un truc
Il faut aussi créer un design pas trop moche via CSS pour que le forum
soit agréable à utiliser.
Non. Ca c'est pas du développement, c'est du graphisme. Et c'est pas
À moins de réutiliser du bon code déjà développé
Crois-tu que je recommence à zéro à chaque nouveau projet ? J'ajouterais
(et le bon code php est rare),
En effet. Même que m'est idée que nous n'avons aps tous les deux la même
fiable, évolutif, maintenable et utilisé par de nombreuses personnes.
Ca se code en 30 minutes, je maintiens, pour la partie PHP, par un
Réaction typique à des concepts de base :
Sécurité à outrance pour corriger des failles qui n'en sont pas.
Le meilleur moyen de faire cela
Un moyen de faire cela. Je crois d'ailleurs que j'ai oublié d'en causer,
On insère les données dans un document HTML => on transforme les données
en noeud texte HTML,
Bah voyons. Et puis on fait aussi appel à trois couches dom-xml et 2
Apparemment, au moment de récupérer les données extérieures, tu
conseilles de leur ajouter des slashes,
Non. D'échapper les caractères dangereux pour le SGBDR, qui, comme tu le
encoder leurs caractères spéciaux HTML
Oui.
et tout un tas d'autres caractères, enlever les caractères
dits "dangereux"
T'as lu ça où ? Tu n'as toujours rien compris à un principe de base : si
(non seulement ils ne le sont pas, mais ils pourraient
avoir été saisis simplement pour être affichés comme corps du
message)...
Tu parles, comme d'habitude, dans le vide. Ou ces caractères n'ont RIEN
cela ne fait que corrompre les données et les rendre
encodées en un format difficilement manipulable.
On s'en branle, on va ***pas*** les manipuler.
Bref, impossible d'utiliser correctement les fonctions de traitement de
chaînes que ce soit en PHP ou SQL.
Deuxième édition : on s'en branle.
Ah oui, autre chose : à ma connaissance, le spoofing d'IP n'est pas
possible avec TCP. Aurais-tu plus d'informations à ce sujet ?
Oui enfin, soyons honnêtes, c'est pas la fête.
Ça fait plus livre d'or du site à neuneu.
Déjà les tables, il faudrait, selon moi :
users : définition des utilisateurs
Et la table access_bb elle sent le pâté ? Quant à appeler une table
groups : définition des différents groupes, et de leur droits
(facultatif, on peut faire ça en dur, mais ça limite en fonctionnalité)
forums : arbre des forums et sous-forums
messages : arbre des messages et de leurs réponses
Personnellement j'aime l'idée de lier les messages aux forums via une
table supplémentaire, ce qui permet de lier les messages à plusieurs
forums en même temps en divers points (pratique pour le cross-post et le
fu2, car on manipule le même message et pas une copie).
Autre chose : les arbres sous forme de listes adjacentes, en SQL, c'est
pas terrible.
Pas terrible du tout même pour cette utilisation je dirais.
Mieux vaut utiliser un bon format d'arbre comme les Nested Sets sur
lequel on pourra faire des modifications avec des classes adaptées
Pour la modération, je préfère donner à chaque utilisateur et à chaque
groupe des droits.
Oui c'est en effet possible.
Un truc un peu comme les droits UNIX me semble sympa.
Là je confirme, il n'y a pas mieux.
Rien qu'avant de commencer à écrire la moindre ligne, il faut créer le
framework de l'application.
On voit tout de suite pas mal de composants nécessaires :
On voit surtout que tu es très fort pour compliquer à outrance un truc
Il faut aussi créer un design pas trop moche via CSS pour que le forum
soit agréable à utiliser.
Non. Ca c'est pas du développement, c'est du graphisme. Et c'est pas
À moins de réutiliser du bon code déjà développé
Crois-tu que je recommence à zéro à chaque nouveau projet ? J'ajouterais
(et le bon code php est rare),
En effet. Même que m'est idée que nous n'avons aps tous les deux la même
fiable, évolutif, maintenable et utilisé par de nombreuses personnes.
Ca se code en 30 minutes, je maintiens, pour la partie PHP, par un
On insère les données dans un document HTML => on transforme les
données en noeud texte HTML,
Bah voyons. Et puis on fait aussi appel à trois couches dom-xml et 2
validations de DTD pour faire un printf("<B>coucou</B>n");
Apparemment, au moment de récupérer les données extérieures, tu
conseilles de leur ajouter des slashes,
Non. D'échapper les caractères dangereux pour le SGBDR, qui, comme tu le
sais car tu le rappelles régulièrement, ne s'échappent pas de la même
manière. Ton problème est très simple : ou tu ne sais pas lire ou tu lis
ce qui t'arrange.
encoder leurs caractères spéciaux HTML
Oui.
et tout un tas d'autres caractères, enlever les caractères dits
"dangereux"
T'as lu ça où ?
Tu n'as toujours rien compris à un principe de base : si
la donnée que je reçois est censée être un ENTIER, elle n'a pas de
raisons de contenir autre chose que des chiffres, POINT BARRE.
Généralisable à tout type fonctionnel de données.
Tu parles, comme d'habitude, dans le vide.
Ou ces caractères n'ont RIEN
A FOUTRE dans le type focntionnel de données où ils sont et on les vire,
ou alors de toutes façons, ils seront bien *affichés* (quelle que soit
leur forme de stockage).
cela ne fait que corrompre les données et les rendre encodées en un
format difficilement manipulable.
On s'en branle, on va ***pas*** les manipuler.
Bref, impossible d'utiliser correctement les fonctions de traitement
de chaînes que ce soit en PHP ou SQL.
Deuxième édition : on s'en branle.
Ah oui, autre chose : à ma connaissance, le spoofing d'IP n'est pas
possible avec TCP. Aurais-tu plus d'informations à ce sujet ?
Plaît-il ? Quel rapport avec une quelconque choucroute ?
Oui enfin, soyons honnêtes, c'est pas la fête.
Ça fait plus livre d'or du site à neuneu.
Parce que les BB ça sert à autre chose ? Non, c'est pas un troll, c'est
mon avis et je le partage. Même si personnellement je préfère
l'expression "fête du slip chez les Barbe-à-Papa" mais il ne doit plus y
avoir beaucoup de contributeurs restant ici se souvenant de qui en est
l'auteur.
Déjà les tables, il faudrait, selon moi :
users : définition des utilisateurs
Et la table access_bb elle sent le pâté ? Quant à appeler une table
users, c'est bien un nom à éviter, idem pour groups.
[NB: j'ai oublié d'indiquer que si je prends un login de 60 chars, c'est
pour utiliser une adresse email directement, sinon pas besoin d'autant,
et prévoir un attribut email, probablement UNIQUE).
Personnellement j'aime l'idée de lier les messages aux forums via une
table supplémentaire, ce qui permet de lier les messages à plusieurs
forums en même temps en divers points (pratique pour le cross-post et
le fu2, car on manipule le même message et pas une copie).
Excellente idée, contacte vite le Komité de fufa, on va refondre Usenet.
Autre chose : les arbres sous forme de listes adjacentes, en SQL,
c'est pas terrible.
Le monsieur a écrit, mais tu ne sais pas lire comme d'habitude, "une
fonction récursive ira très bien vu le nombre de fils qu'on aura". Pour
un forum même actif de type web-based, le stockage en arbre bête suffit
amplement. merci, je n'ai pas besoin de cours sur les structures de
données et les arbres, je peux en donner.
Pas terrible du tout même pour cette utilisation je dirais.
Mieux vaut utiliser un bon format d'arbre comme les Nested Sets sur
lequel on pourra faire des modifications avec des classes adaptées
Ouais, et puis un peu de MVC/Struts/Xtreme-Programming parce que là je
trouve ça pauvret.
On voit tout de suite pas mal de composants nécessaires :
On voit surtout que tu es très fort pour compliquer à outrance un truc
super simple.
Il faut aussi créer un design pas trop moche via CSS pour que le forum
soit agréable à utiliser.
Non. Ca c'est pas du développement, c'est du graphisme. Et c'est pas
inclus dans le temps annoncé. Il est de notoriété publique que je n'ai
jamais émis la moindre opinion sur la qualité du HTML (1) car j'en suis
totalement incapable. Faire du HTML strict 4.1 comme demandé, juste pour
faire une page de présentation, si je dois le faire totalement à la main
sans éditeur, il me faudra bien 3 jours rien que pour ça. C'est pas mon
métier.
(et le bon code php est rare),
En effet. Même que m'est idée que nous n'avons aps tous les deux la même
conception de "bon" code d'ailleurs.
S'il part from scratch, oui, il lui faudra le temps d'aller à
la pêche ) divers endroits s'enquérir d'un "framework" (ah, le joli mot)
On insère les données dans un document HTML => on transforme les
données en noeud texte HTML,
Bah voyons. Et puis on fait aussi appel à trois couches dom-xml et 2
validations de DTD pour faire un printf("<B>coucou</B>n");
Apparemment, au moment de récupérer les données extérieures, tu
conseilles de leur ajouter des slashes,
Non. D'échapper les caractères dangereux pour le SGBDR, qui, comme tu le
sais car tu le rappelles régulièrement, ne s'échappent pas de la même
manière. Ton problème est très simple : ou tu ne sais pas lire ou tu lis
ce qui t'arrange.
encoder leurs caractères spéciaux HTML
Oui.
et tout un tas d'autres caractères, enlever les caractères dits
"dangereux"
T'as lu ça où ?
Tu n'as toujours rien compris à un principe de base : si
la donnée que je reçois est censée être un ENTIER, elle n'a pas de
raisons de contenir autre chose que des chiffres, POINT BARRE.
Généralisable à tout type fonctionnel de données.
Tu parles, comme d'habitude, dans le vide.
Ou ces caractères n'ont RIEN
A FOUTRE dans le type focntionnel de données où ils sont et on les vire,
ou alors de toutes façons, ils seront bien *affichés* (quelle que soit
leur forme de stockage).
cela ne fait que corrompre les données et les rendre encodées en un
format difficilement manipulable.
On s'en branle, on va ***pas*** les manipuler.
Bref, impossible d'utiliser correctement les fonctions de traitement
de chaînes que ce soit en PHP ou SQL.
Deuxième édition : on s'en branle.
Ah oui, autre chose : à ma connaissance, le spoofing d'IP n'est pas
possible avec TCP. Aurais-tu plus d'informations à ce sujet ?
Plaît-il ? Quel rapport avec une quelconque choucroute ?
Oui enfin, soyons honnêtes, c'est pas la fête.
Ça fait plus livre d'or du site à neuneu.
Parce que les BB ça sert à autre chose ? Non, c'est pas un troll, c'est
mon avis et je le partage. Même si personnellement je préfère
l'expression "fête du slip chez les Barbe-à-Papa" mais il ne doit plus y
avoir beaucoup de contributeurs restant ici se souvenant de qui en est
l'auteur.
Déjà les tables, il faudrait, selon moi :
users : définition des utilisateurs
Et la table access_bb elle sent le pâté ? Quant à appeler une table
users, c'est bien un nom à éviter, idem pour groups.
[NB: j'ai oublié d'indiquer que si je prends un login de 60 chars, c'est
pour utiliser une adresse email directement, sinon pas besoin d'autant,
et prévoir un attribut email, probablement UNIQUE).
Personnellement j'aime l'idée de lier les messages aux forums via une
table supplémentaire, ce qui permet de lier les messages à plusieurs
forums en même temps en divers points (pratique pour le cross-post et
le fu2, car on manipule le même message et pas une copie).
Excellente idée, contacte vite le Komité de fufa, on va refondre Usenet.
Autre chose : les arbres sous forme de listes adjacentes, en SQL,
c'est pas terrible.
Le monsieur a écrit, mais tu ne sais pas lire comme d'habitude, "une
fonction récursive ira très bien vu le nombre de fils qu'on aura". Pour
un forum même actif de type web-based, le stockage en arbre bête suffit
amplement. merci, je n'ai pas besoin de cours sur les structures de
données et les arbres, je peux en donner.
Pas terrible du tout même pour cette utilisation je dirais.
Mieux vaut utiliser un bon format d'arbre comme les Nested Sets sur
lequel on pourra faire des modifications avec des classes adaptées
Ouais, et puis un peu de MVC/Struts/Xtreme-Programming parce que là je
trouve ça pauvret.
On voit tout de suite pas mal de composants nécessaires :
On voit surtout que tu es très fort pour compliquer à outrance un truc
super simple.
Il faut aussi créer un design pas trop moche via CSS pour que le forum
soit agréable à utiliser.
Non. Ca c'est pas du développement, c'est du graphisme. Et c'est pas
inclus dans le temps annoncé. Il est de notoriété publique que je n'ai
jamais émis la moindre opinion sur la qualité du HTML (1) car j'en suis
totalement incapable. Faire du HTML strict 4.1 comme demandé, juste pour
faire une page de présentation, si je dois le faire totalement à la main
sans éditeur, il me faudra bien 3 jours rien que pour ça. C'est pas mon
métier.
(et le bon code php est rare),
En effet. Même que m'est idée que nous n'avons aps tous les deux la même
conception de "bon" code d'ailleurs.
S'il part from scratch, oui, il lui faudra le temps d'aller à
la pêche ) divers endroits s'enquérir d'un "framework" (ah, le joli mot)
On insère les données dans un document HTML => on transforme les
données en noeud texte HTML,
Bah voyons. Et puis on fait aussi appel à trois couches dom-xml et 2
validations de DTD pour faire un printf("<B>coucou</B>n");
Apparemment, au moment de récupérer les données extérieures, tu
conseilles de leur ajouter des slashes,
Non. D'échapper les caractères dangereux pour le SGBDR, qui, comme tu le
sais car tu le rappelles régulièrement, ne s'échappent pas de la même
manière. Ton problème est très simple : ou tu ne sais pas lire ou tu lis
ce qui t'arrange.
encoder leurs caractères spéciaux HTML
Oui.
et tout un tas d'autres caractères, enlever les caractères dits
"dangereux"
T'as lu ça où ?
Tu n'as toujours rien compris à un principe de base : si
la donnée que je reçois est censée être un ENTIER, elle n'a pas de
raisons de contenir autre chose que des chiffres, POINT BARRE.
Généralisable à tout type fonctionnel de données.
Tu parles, comme d'habitude, dans le vide.
Ou ces caractères n'ont RIEN
A FOUTRE dans le type focntionnel de données où ils sont et on les vire,
ou alors de toutes façons, ils seront bien *affichés* (quelle que soit
leur forme de stockage).
cela ne fait que corrompre les données et les rendre encodées en un
format difficilement manipulable.
On s'en branle, on va ***pas*** les manipuler.
Bref, impossible d'utiliser correctement les fonctions de traitement
de chaînes que ce soit en PHP ou SQL.
Deuxième édition : on s'en branle.
Ah oui, autre chose : à ma connaissance, le spoofing d'IP n'est pas
possible avec TCP. Aurais-tu plus d'informations à ce sujet ?
Plaît-il ? Quel rapport avec une quelconque choucroute ?
Oui enfin, soyons honnêtes, c'est pas la fête.
Ça fait plus livre d'or du site à neuneu.
Parce que les BB ça sert à autre chose ? Non, c'est pas un troll, c'est
mon avis et je le partage. Même si personnellement je préfère
l'expression "fête du slip chez les Barbe-à-Papa" mais il ne doit plus y
avoir beaucoup de contributeurs restant ici se souvenant de qui en est
l'auteur.
Déjà les tables, il faudrait, selon moi :
users : définition des utilisateurs
Et la table access_bb elle sent le pâté ? Quant à appeler une table
users, c'est bien un nom à éviter, idem pour groups.
[NB: j'ai oublié d'indiquer que si je prends un login de 60 chars, c'est
pour utiliser une adresse email directement, sinon pas besoin d'autant,
et prévoir un attribut email, probablement UNIQUE).
Personnellement j'aime l'idée de lier les messages aux forums via une
table supplémentaire, ce qui permet de lier les messages à plusieurs
forums en même temps en divers points (pratique pour le cross-post et
le fu2, car on manipule le même message et pas une copie).
Excellente idée, contacte vite le Komité de fufa, on va refondre Usenet.
Autre chose : les arbres sous forme de listes adjacentes, en SQL,
c'est pas terrible.
Le monsieur a écrit, mais tu ne sais pas lire comme d'habitude, "une
fonction récursive ira très bien vu le nombre de fils qu'on aura". Pour
un forum même actif de type web-based, le stockage en arbre bête suffit
amplement. merci, je n'ai pas besoin de cours sur les structures de
données et les arbres, je peux en donner.
Pas terrible du tout même pour cette utilisation je dirais.
Mieux vaut utiliser un bon format d'arbre comme les Nested Sets sur
lequel on pourra faire des modifications avec des classes adaptées
Ouais, et puis un peu de MVC/Struts/Xtreme-Programming parce que là je
trouve ça pauvret.
On voit tout de suite pas mal de composants nécessaires :
On voit surtout que tu es très fort pour compliquer à outrance un truc
super simple.
Il faut aussi créer un design pas trop moche via CSS pour que le forum
soit agréable à utiliser.
Non. Ca c'est pas du développement, c'est du graphisme. Et c'est pas
inclus dans le temps annoncé. Il est de notoriété publique que je n'ai
jamais émis la moindre opinion sur la qualité du HTML (1) car j'en suis
totalement incapable. Faire du HTML strict 4.1 comme demandé, juste pour
faire une page de présentation, si je dois le faire totalement à la main
sans éditeur, il me faudra bien 3 jours rien que pour ça. C'est pas mon
métier.
(et le bon code php est rare),
En effet. Même que m'est idée que nous n'avons aps tous les deux la même
conception de "bon" code d'ailleurs.
S'il part from scratch, oui, il lui faudra le temps d'aller à
la pêche ) divers endroits s'enquérir d'un "framework" (ah, le joli mot)
La transformation en noeud texte se fait en remplaçant les caractères
réservées selon le contexte par leur séquence d'échappement appropriée.
Ce ne sont pas des caractères dangereux, simplement réservés par la
syntaxe du langage SQL et qui disposent de mécanismes d'échappement afin
de pouvoir quand même être saisis.
Une fois de plus, cette vision est beaucoup trop "happy people in a
Ensuite ces chaînes ne devraient être échappées qu'au moment de leur
insertion dans la requête SQL à créer.
Le meilleur moyen pour réaliser
cela de façon propre, je l'ai dit et tu l'as toi aussi cité dans ton
document, ce sont les 'placeholders'.
Tu sembles encourager le fait qu'on doit passer par ta moulinette toute
donnée extérieure, alors que toute donnée extérieure ne sera pas
nécessairement utilisée pour être insérée dans une requête SQL ou au
final dans un document HTML.
J'ai bien indiqué que je me place dans le cas précis des webapp où, par
Ce qui devrait être fait à l'affichage.
Ce qui *peut* être fait à l'affichage. Si tu as un seul programme qui
Le SGBD sert à stocker des données,
Oui.
pas des bouts de documents HTML
pré-construits.
Tu as dit toi-même faire usage de strip_tags.
J'interdits le html dans les saisies, donc oui.
Le cas auquel je faisais référence était quand on voulait une chaîne et
qui tu lui appliquais strip_tags.
De toutes façons, tu lui appliqueras aussi strip_tags, mais tu le feras
Tu parles, comme d'habitude, dans le vide.
Manifestement je parle dans le vide car je parle d'approches théoriques
réfléchies à un technicien bidouilleur.
On ne parle pas de types de données variés, simplement des traitements
sur les chaînes arbitraires (qui peuvent contenir n'importe quoi), qui
sont, ici (le cas du forum), les principales entrées de l'application.
Si mon texte contient "Ici on a 2<5 donc a>b" strip_tags produira "Ici
on a 2b"
Ouf, c'est bon, c'est "secure". Après tout, le plus important c'est que
ce soit sécurisé, pas que ça marche correctement. (exagération de ton
raisonnement)
C'est vrai, les chaînes de caractères on les manipule pas, on fait que
les prendre à un endroit et les balancer dans un autre. C'est le
copier/coller et le rechercher/remplacer moderne.
Une chaîne de caractères est un objet fait pour contenir des caractères
auxquels on peut accéder un à un, les compter, les comparer, etc. Pas
pour mettre des trucs en vrac.
Ton SGBD ne pourra même plus trier, comparer ou rechercher correctement
des chaînes.
Dès lors que les données à comparer subissent toutes les mêmes
Toutes ses fonctionnalités d'encodages de caractères et de
collations seront inutilisables.
C'est surtout le cas pour le remplacement de é par é avant
l'insertion.
Je ne vois pas le problème. Je n'ai pas dit qu'il n'y en a pas, je ne le
Tu as fait référence à un article à toi, je suis donc allé le lire en
diagonale, et je te pose des questions tant que je t'ai sous la main.
Oui,la diagonale j'avais remarqué. Et tu m'avais sous la main autant que
Un BB sert à organiser des discussions, du support etc. et il s'y créé
presque une communauté, en fonction de sa popularité.
Rien que le mot "communauté" m'amuse. Je rappelle que selon le sens
Et la table access_bb elle sent le pâté ? Quant à appeler une table
users, c'est bien un nom à éviter, idem pour groups.
Pour quelle raison ?
Trop proche de mots clefs. Par exemple sous mysql, c'est justement le
De toutes façons on groupe généralement toutes les tables d'une même
application avec un préfixe particulier, donc pas de collisions.
Oui.
J'aurais plutôt dit un identifiant, un login, un mot de passe, une date
d'inscription, une adresse email, le groupe d'appartenance/rang, les
préférences utilisateurs...
On peut.
Enfin ce sont des détails.
Oui.
On peut effectivement fusionner identifiant, login et email.
Vu le nombre de fils qu'on aura ? Tu peux prévoir l'utilisation du truc
?
Je rappelle qu'on ne fait pas le forum des merguez party de
Chaunes-sur-Marne mais quelque chose de "scalable".
Pour un BB, chez moi ça s'arrête à la première solution. Mais c'est un
Ouais, et puis un peu de MVC/Struts/Xtreme-Programming parce que là je
trouve ça pauvret.
Les Nested Sets n'ont rien à voir avec le genre de choses que tu cites.
Normal je parlais des classes.
Tu disais pourtant connaître parfaitement les structures possibles pour
les arbres dans un SGBD.
Entre autres dans un SGBD. Toutes je n'en sais rien, il doit bien y
On voit tout de suite pas mal de composants nécessaires :
On voit surtout que tu es très fort pour compliquer à outrance un truc
super simple.
C'est une compétence qui n'est pas donnée à tout le monde ;).
Absolument :-)
Non. Ca c'est pas du développement, c'est du graphisme. Et c'est pas
inclus dans le temps annoncé. Il est de notoriété publique que je n'ai
jamais émis la moindre opinion sur la qualité du HTML (1) car j'en
suis totalement incapable. Faire du HTML strict 4.1 comme demandé,
juste pour faire une page de présentation, si je dois le faire
totalement à la main sans éditeur, il me faudra bien 3 jours rien que
pour ça. C'est pas mon métier.
Même le travail sur l'ergonomie, l'interface ?
On peut préférer élégant ou simplement fonctionnel.
Oui, mais le problème c'est que l'élégant termine souvent dans le "code
S'il part from scratch, oui, il lui faudra le temps d'aller à la pêche
) divers endroits s'enquérir d'un "framework" (ah, le joli mot)
"L'environnement de travail" ça fait plus penser à EDI.
J'ai pas trouvé de bonne traduction.
Je n'en connais pas, à mon sens c'est "librairie" mais ça ne fait pas
La transformation en noeud texte se fait en remplaçant les caractères
réservées selon le contexte par leur séquence d'échappement appropriée.
Ce ne sont pas des caractères dangereux, simplement réservés par la
syntaxe du langage SQL et qui disposent de mécanismes d'échappement afin
de pouvoir quand même être saisis.
Une fois de plus, cette vision est beaucoup trop "happy people in a
Ensuite ces chaînes ne devraient être échappées qu'au moment de leur
insertion dans la requête SQL à créer.
Le meilleur moyen pour réaliser
cela de façon propre, je l'ai dit et tu l'as toi aussi cité dans ton
document, ce sont les 'placeholders'.
Tu sembles encourager le fait qu'on doit passer par ta moulinette toute
donnée extérieure, alors que toute donnée extérieure ne sera pas
nécessairement utilisée pour être insérée dans une requête SQL ou au
final dans un document HTML.
J'ai bien indiqué que je me place dans le cas précis des webapp où, par
Ce qui devrait être fait à l'affichage.
Ce qui *peut* être fait à l'affichage. Si tu as un seul programme qui
Le SGBD sert à stocker des données,
Oui.
pas des bouts de documents HTML
pré-construits.
Tu as dit toi-même faire usage de strip_tags.
J'interdits le html dans les saisies, donc oui.
Le cas auquel je faisais référence était quand on voulait une chaîne et
qui tu lui appliquais strip_tags.
De toutes façons, tu lui appliqueras aussi strip_tags, mais tu le feras
Tu parles, comme d'habitude, dans le vide.
Manifestement je parle dans le vide car je parle d'approches théoriques
réfléchies à un technicien bidouilleur.
On ne parle pas de types de données variés, simplement des traitements
sur les chaînes arbitraires (qui peuvent contenir n'importe quoi), qui
sont, ici (le cas du forum), les principales entrées de l'application.
Si mon texte contient "Ici on a 2<5 donc a>b" strip_tags produira "Ici
on a 2b"
Ouf, c'est bon, c'est "secure". Après tout, le plus important c'est que
ce soit sécurisé, pas que ça marche correctement. (exagération de ton
raisonnement)
C'est vrai, les chaînes de caractères on les manipule pas, on fait que
les prendre à un endroit et les balancer dans un autre. C'est le
copier/coller et le rechercher/remplacer moderne.
Une chaîne de caractères est un objet fait pour contenir des caractères
auxquels on peut accéder un à un, les compter, les comparer, etc. Pas
pour mettre des trucs en vrac.
Ton SGBD ne pourra même plus trier, comparer ou rechercher correctement
des chaînes.
Dès lors que les données à comparer subissent toutes les mêmes
Toutes ses fonctionnalités d'encodages de caractères et de
collations seront inutilisables.
C'est surtout le cas pour le remplacement de é par é avant
l'insertion.
Je ne vois pas le problème. Je n'ai pas dit qu'il n'y en a pas, je ne le
Tu as fait référence à un article à toi, je suis donc allé le lire en
diagonale, et je te pose des questions tant que je t'ai sous la main.
Oui,la diagonale j'avais remarqué. Et tu m'avais sous la main autant que
Un BB sert à organiser des discussions, du support etc. et il s'y créé
presque une communauté, en fonction de sa popularité.
Rien que le mot "communauté" m'amuse. Je rappelle que selon le sens
Et la table access_bb elle sent le pâté ? Quant à appeler une table
users, c'est bien un nom à éviter, idem pour groups.
Pour quelle raison ?
Trop proche de mots clefs. Par exemple sous mysql, c'est justement le
De toutes façons on groupe généralement toutes les tables d'une même
application avec un préfixe particulier, donc pas de collisions.
Oui.
J'aurais plutôt dit un identifiant, un login, un mot de passe, une date
d'inscription, une adresse email, le groupe d'appartenance/rang, les
préférences utilisateurs...
On peut.
Enfin ce sont des détails.
Oui.
On peut effectivement fusionner identifiant, login et email.
Vu le nombre de fils qu'on aura ? Tu peux prévoir l'utilisation du truc
?
Je rappelle qu'on ne fait pas le forum des merguez party de
Chaunes-sur-Marne mais quelque chose de "scalable".
Pour un BB, chez moi ça s'arrête à la première solution. Mais c'est un
Ouais, et puis un peu de MVC/Struts/Xtreme-Programming parce que là je
trouve ça pauvret.
Les Nested Sets n'ont rien à voir avec le genre de choses que tu cites.
Normal je parlais des classes.
Tu disais pourtant connaître parfaitement les structures possibles pour
les arbres dans un SGBD.
Entre autres dans un SGBD. Toutes je n'en sais rien, il doit bien y
On voit tout de suite pas mal de composants nécessaires :
On voit surtout que tu es très fort pour compliquer à outrance un truc
super simple.
C'est une compétence qui n'est pas donnée à tout le monde ;).
Absolument :-)
Non. Ca c'est pas du développement, c'est du graphisme. Et c'est pas
inclus dans le temps annoncé. Il est de notoriété publique que je n'ai
jamais émis la moindre opinion sur la qualité du HTML (1) car j'en
suis totalement incapable. Faire du HTML strict 4.1 comme demandé,
juste pour faire une page de présentation, si je dois le faire
totalement à la main sans éditeur, il me faudra bien 3 jours rien que
pour ça. C'est pas mon métier.
Même le travail sur l'ergonomie, l'interface ?
On peut préférer élégant ou simplement fonctionnel.
Oui, mais le problème c'est que l'élégant termine souvent dans le "code
S'il part from scratch, oui, il lui faudra le temps d'aller à la pêche
) divers endroits s'enquérir d'un "framework" (ah, le joli mot)
"L'environnement de travail" ça fait plus penser à EDI.
J'ai pas trouvé de bonne traduction.
Je n'en connais pas, à mon sens c'est "librairie" mais ça ne fait pas
La transformation en noeud texte se fait en remplaçant les caractères
réservées selon le contexte par leur séquence d'échappement appropriée.
Ce ne sont pas des caractères dangereux, simplement réservés par la
syntaxe du langage SQL et qui disposent de mécanismes d'échappement afin
de pouvoir quand même être saisis.
Une fois de plus, cette vision est beaucoup trop "happy people in a
Ensuite ces chaînes ne devraient être échappées qu'au moment de leur
insertion dans la requête SQL à créer.
Le meilleur moyen pour réaliser
cela de façon propre, je l'ai dit et tu l'as toi aussi cité dans ton
document, ce sont les 'placeholders'.
Tu sembles encourager le fait qu'on doit passer par ta moulinette toute
donnée extérieure, alors que toute donnée extérieure ne sera pas
nécessairement utilisée pour être insérée dans une requête SQL ou au
final dans un document HTML.
J'ai bien indiqué que je me place dans le cas précis des webapp où, par
Ce qui devrait être fait à l'affichage.
Ce qui *peut* être fait à l'affichage. Si tu as un seul programme qui
Le SGBD sert à stocker des données,
Oui.
pas des bouts de documents HTML
pré-construits.
Tu as dit toi-même faire usage de strip_tags.
J'interdits le html dans les saisies, donc oui.
Le cas auquel je faisais référence était quand on voulait une chaîne et
qui tu lui appliquais strip_tags.
De toutes façons, tu lui appliqueras aussi strip_tags, mais tu le feras
Tu parles, comme d'habitude, dans le vide.
Manifestement je parle dans le vide car je parle d'approches théoriques
réfléchies à un technicien bidouilleur.
On ne parle pas de types de données variés, simplement des traitements
sur les chaînes arbitraires (qui peuvent contenir n'importe quoi), qui
sont, ici (le cas du forum), les principales entrées de l'application.
Si mon texte contient "Ici on a 2<5 donc a>b" strip_tags produira "Ici
on a 2b"
Ouf, c'est bon, c'est "secure". Après tout, le plus important c'est que
ce soit sécurisé, pas que ça marche correctement. (exagération de ton
raisonnement)
C'est vrai, les chaînes de caractères on les manipule pas, on fait que
les prendre à un endroit et les balancer dans un autre. C'est le
copier/coller et le rechercher/remplacer moderne.
Une chaîne de caractères est un objet fait pour contenir des caractères
auxquels on peut accéder un à un, les compter, les comparer, etc. Pas
pour mettre des trucs en vrac.
Ton SGBD ne pourra même plus trier, comparer ou rechercher correctement
des chaînes.
Dès lors que les données à comparer subissent toutes les mêmes
Toutes ses fonctionnalités d'encodages de caractères et de
collations seront inutilisables.
C'est surtout le cas pour le remplacement de é par é avant
l'insertion.
Je ne vois pas le problème. Je n'ai pas dit qu'il n'y en a pas, je ne le
Tu as fait référence à un article à toi, je suis donc allé le lire en
diagonale, et je te pose des questions tant que je t'ai sous la main.
Oui,la diagonale j'avais remarqué. Et tu m'avais sous la main autant que
Un BB sert à organiser des discussions, du support etc. et il s'y créé
presque une communauté, en fonction de sa popularité.
Rien que le mot "communauté" m'amuse. Je rappelle que selon le sens
Et la table access_bb elle sent le pâté ? Quant à appeler une table
users, c'est bien un nom à éviter, idem pour groups.
Pour quelle raison ?
Trop proche de mots clefs. Par exemple sous mysql, c'est justement le
De toutes façons on groupe généralement toutes les tables d'une même
application avec un préfixe particulier, donc pas de collisions.
Oui.
J'aurais plutôt dit un identifiant, un login, un mot de passe, une date
d'inscription, une adresse email, le groupe d'appartenance/rang, les
préférences utilisateurs...
On peut.
Enfin ce sont des détails.
Oui.
On peut effectivement fusionner identifiant, login et email.
Vu le nombre de fils qu'on aura ? Tu peux prévoir l'utilisation du truc
?
Je rappelle qu'on ne fait pas le forum des merguez party de
Chaunes-sur-Marne mais quelque chose de "scalable".
Pour un BB, chez moi ça s'arrête à la première solution. Mais c'est un
Ouais, et puis un peu de MVC/Struts/Xtreme-Programming parce que là je
trouve ça pauvret.
Les Nested Sets n'ont rien à voir avec le genre de choses que tu cites.
Normal je parlais des classes.
Tu disais pourtant connaître parfaitement les structures possibles pour
les arbres dans un SGBD.
Entre autres dans un SGBD. Toutes je n'en sais rien, il doit bien y
On voit tout de suite pas mal de composants nécessaires :
On voit surtout que tu es très fort pour compliquer à outrance un truc
super simple.
C'est une compétence qui n'est pas donnée à tout le monde ;).
Absolument :-)
Non. Ca c'est pas du développement, c'est du graphisme. Et c'est pas
inclus dans le temps annoncé. Il est de notoriété publique que je n'ai
jamais émis la moindre opinion sur la qualité du HTML (1) car j'en
suis totalement incapable. Faire du HTML strict 4.1 comme demandé,
juste pour faire une page de présentation, si je dois le faire
totalement à la main sans éditeur, il me faudra bien 3 jours rien que
pour ça. C'est pas mon métier.
Même le travail sur l'ergonomie, l'interface ?
On peut préférer élégant ou simplement fonctionnel.
Oui, mais le problème c'est que l'élégant termine souvent dans le "code
S'il part from scratch, oui, il lui faudra le temps d'aller à la pêche
) divers endroits s'enquérir d'un "framework" (ah, le joli mot)
"L'environnement de travail" ça fait plus penser à EDI.
J'ai pas trouvé de bonne traduction.
Je n'en connais pas, à mon sens c'est "librairie" mais ça ne fait pas
Bonjour,
Le meilleur moyen *à ton avis* et j'ajouterais *quand le SGBD le
permet*.
J'ai bien indiqué que je me place dans le cas précis des webapp où, par
définition, on stocke des trucs (en général en sgbd) et on a *au moins*
comme canal de sortie le HTML, et j'ai bien précisé que je préfère faire
du sanitizing bourrin en entrée quitte à refaire l'opératin inverse si
un canal de sortie (ex. PDF) le nécessite, car dans le cas des webapps,
le canal principal de sortie est le HTML.
Tu as dit toi-même faire usage de strip_tags.
J'interdits le html dans les saisies, donc oui.
Alleluia Gloria (Régilait). Tu vois quand tu te donnes la peine
d'argumenter correctement on peut discuter correctement. Je n'ai pas vu
le problème, pour la raison simple que dans les applications sur
lesquelles je travaille, on n'a pas besoin de signes mathématiques dans
les saisies textuelles. Mais il est exact que sur fcs on avait parlé de
ce cas, j'ai oublié de l'intégrer.
Le fait qu'on puisse le faire ne veut pas dire qu'on va le faire.
Je ne vois pas le problème. Je n'ai pas dit qu'il n'y en a pas, je ne le
vois pas. Exemple concret SVP.
Rien que le mot "communauté" m'amuse. Je rappelle que selon le sens
d'origine du dictionnaire, il s'agit "d'un ensemble de personnes suivant
les mêmes règles de vie religieuses" (petit Larousse 1927).
Trop proche de mots clefs. Par exemple sous mysql, c'est justement le
nom de la table des users. **De mémoire** il y a une table group ou
groups dans postgresql. Même si informatiquement parlant le risque de
confusion est faible, pour le développeur fatigué qui cherche un bug à
2h du matin et qui lit le code, lui aussi, en diagonale parce qu'il est
à la bourre, la confusion est possible voire probable.
Statistiquement, je te pifométrise que 80% des threads auront une
profondeur inférieur à 6 niveaux de questions/réponses, y'a qu'à
regarder n'importe quel forum Usenet. Sauf sur fufe ou fsp évidemment,
mais là c'est un sport national.
Normal je parlais des classes.
A mon sens oui. C'est le boulot d'un infographiste. On doit le
restreindre dans ses élans et le guider pour lui rappeler, par exemple,
que tel choix c'est du radio button parce que mutuellement exclusif et
non pas du cumulatif, ou que telle zone de type TEXT est en fait un drop
down, mais ce genre de choses doit être faite en accord avec les
utilisateurs du produit (quand on les a sous la main). Ce n'est pas du
codage de la logique de l'application, ça doit rester du haut niveau.
Charge au développeur derrière de se démmerder pour que ça marche (pas
toujours évident).
Oui, mais le problème c'est que l'élégant termine souvent dans le "code
d'esthète" tellement élégant que totalement imbittable et impossible à
maintenir, le tout avec des tétrachiées de couches et de surcouches.
Je n'en connais pas, à mon sens c'est "librairie"
Bonjour,
Le meilleur moyen *à ton avis* et j'ajouterais *quand le SGBD le
permet*.
J'ai bien indiqué que je me place dans le cas précis des webapp où, par
définition, on stocke des trucs (en général en sgbd) et on a *au moins*
comme canal de sortie le HTML, et j'ai bien précisé que je préfère faire
du sanitizing bourrin en entrée quitte à refaire l'opératin inverse si
un canal de sortie (ex. PDF) le nécessite, car dans le cas des webapps,
le canal principal de sortie est le HTML.
Tu as dit toi-même faire usage de strip_tags.
J'interdits le html dans les saisies, donc oui.
Alleluia Gloria (Régilait). Tu vois quand tu te donnes la peine
d'argumenter correctement on peut discuter correctement. Je n'ai pas vu
le problème, pour la raison simple que dans les applications sur
lesquelles je travaille, on n'a pas besoin de signes mathématiques dans
les saisies textuelles. Mais il est exact que sur fcs on avait parlé de
ce cas, j'ai oublié de l'intégrer.
Le fait qu'on puisse le faire ne veut pas dire qu'on va le faire.
Je ne vois pas le problème. Je n'ai pas dit qu'il n'y en a pas, je ne le
vois pas. Exemple concret SVP.
Rien que le mot "communauté" m'amuse. Je rappelle que selon le sens
d'origine du dictionnaire, il s'agit "d'un ensemble de personnes suivant
les mêmes règles de vie religieuses" (petit Larousse 1927).
Trop proche de mots clefs. Par exemple sous mysql, c'est justement le
nom de la table des users. **De mémoire** il y a une table group ou
groups dans postgresql. Même si informatiquement parlant le risque de
confusion est faible, pour le développeur fatigué qui cherche un bug à
2h du matin et qui lit le code, lui aussi, en diagonale parce qu'il est
à la bourre, la confusion est possible voire probable.
Statistiquement, je te pifométrise que 80% des threads auront une
profondeur inférieur à 6 niveaux de questions/réponses, y'a qu'à
regarder n'importe quel forum Usenet. Sauf sur fufe ou fsp évidemment,
mais là c'est un sport national.
Normal je parlais des classes.
A mon sens oui. C'est le boulot d'un infographiste. On doit le
restreindre dans ses élans et le guider pour lui rappeler, par exemple,
que tel choix c'est du radio button parce que mutuellement exclusif et
non pas du cumulatif, ou que telle zone de type TEXT est en fait un drop
down, mais ce genre de choses doit être faite en accord avec les
utilisateurs du produit (quand on les a sous la main). Ce n'est pas du
codage de la logique de l'application, ça doit rester du haut niveau.
Charge au développeur derrière de se démmerder pour que ça marche (pas
toujours évident).
Oui, mais le problème c'est que l'élégant termine souvent dans le "code
d'esthète" tellement élégant que totalement imbittable et impossible à
maintenir, le tout avec des tétrachiées de couches et de surcouches.
Je n'en connais pas, à mon sens c'est "librairie"
Bonjour,
Le meilleur moyen *à ton avis* et j'ajouterais *quand le SGBD le
permet*.
J'ai bien indiqué que je me place dans le cas précis des webapp où, par
définition, on stocke des trucs (en général en sgbd) et on a *au moins*
comme canal de sortie le HTML, et j'ai bien précisé que je préfère faire
du sanitizing bourrin en entrée quitte à refaire l'opératin inverse si
un canal de sortie (ex. PDF) le nécessite, car dans le cas des webapps,
le canal principal de sortie est le HTML.
Tu as dit toi-même faire usage de strip_tags.
J'interdits le html dans les saisies, donc oui.
Alleluia Gloria (Régilait). Tu vois quand tu te donnes la peine
d'argumenter correctement on peut discuter correctement. Je n'ai pas vu
le problème, pour la raison simple que dans les applications sur
lesquelles je travaille, on n'a pas besoin de signes mathématiques dans
les saisies textuelles. Mais il est exact que sur fcs on avait parlé de
ce cas, j'ai oublié de l'intégrer.
Le fait qu'on puisse le faire ne veut pas dire qu'on va le faire.
Je ne vois pas le problème. Je n'ai pas dit qu'il n'y en a pas, je ne le
vois pas. Exemple concret SVP.
Rien que le mot "communauté" m'amuse. Je rappelle que selon le sens
d'origine du dictionnaire, il s'agit "d'un ensemble de personnes suivant
les mêmes règles de vie religieuses" (petit Larousse 1927).
Trop proche de mots clefs. Par exemple sous mysql, c'est justement le
nom de la table des users. **De mémoire** il y a une table group ou
groups dans postgresql. Même si informatiquement parlant le risque de
confusion est faible, pour le développeur fatigué qui cherche un bug à
2h du matin et qui lit le code, lui aussi, en diagonale parce qu'il est
à la bourre, la confusion est possible voire probable.
Statistiquement, je te pifométrise que 80% des threads auront une
profondeur inférieur à 6 niveaux de questions/réponses, y'a qu'à
regarder n'importe quel forum Usenet. Sauf sur fufe ou fsp évidemment,
mais là c'est un sport national.
Normal je parlais des classes.
A mon sens oui. C'est le boulot d'un infographiste. On doit le
restreindre dans ses élans et le guider pour lui rappeler, par exemple,
que tel choix c'est du radio button parce que mutuellement exclusif et
non pas du cumulatif, ou que telle zone de type TEXT est en fait un drop
down, mais ce genre de choses doit être faite en accord avec les
utilisateurs du produit (quand on les a sous la main). Ce n'est pas du
codage de la logique de l'application, ça doit rester du haut niveau.
Charge au développeur derrière de se démmerder pour que ça marche (pas
toujours évident).
Oui, mais le problème c'est que l'élégant termine souvent dans le "code
d'esthète" tellement élégant que totalement imbittable et impossible à
maintenir, le tout avec des tétrachiées de couches et de surcouches.
Je n'en connais pas, à mon sens c'est "librairie"
Si le SGBD le permet pas, il suffit de manipuler la chaîne pour le faire
à sa place.
C'est ce que font JDBC, PDO, etc.
Bof. Choisir une méthode de développement/un ensemble de classes en
J'ai bien indiqué que je me place dans le cas précis des webapp où, par
définition, on stocke des trucs (en général en sgbd) et on a *au moins*
comme canal de sortie le HTML, et j'ai bien précisé que je préfère faire
du sanitizing bourrin en entrée quitte à refaire l'opératin inverse si
un canal de sortie (ex. PDF) le nécessite, car dans le cas des webapps,
le canal principal de sortie est le HTML.
C'est vrai que c'est le canal principal de sortie, mais est-ce une
raison pour se focaliser dessus ?
Tu as dit toi-même faire usage de strip_tags.
J'interdits le html dans les saisies, donc oui.
Tu interdis non seulement le html mais aussi tout texte du type <w+.*?w+>
Oui, vu sur ton exemple le rappelant, en effet.
Exemple simple : je veux afficher les x premiers caractères d'un
enregistrement dans la base de données, pour donner un genre d'aperçu de
son contenu.
< fait 4 octets mais n'est qu'un caractère. D'où le problème, mon x
ne sera qu'approximatif.
Je ne vois pas le problème. Je n'ai pas dit qu'il n'y en a pas, je ne le
vois pas. Exemple concret SVP.
- Tri des données
Normalement on devrait avoir
Tablature
Téléphone
Transaction
Si é est é on obtient
Téléphone
Tablature
Transaction
C'est ça qui est plus que dommage avec toi, c'est que 90% de tes
De toutes façons, il est souvent dit sur fciwa que les entités (autres
que celles pour les caractères réservés) sont inutiles, il suffit de
gérer correctement l'encodage des caractères ; ce qui offre d'ailleurs
bien plus de possibilités, suivant l'encodage choisi.
Ils ont du mettre ça dans une base de données à part quand même
j'imagine (flemme de vérifier) justement pour éviter ce genre de conflits.
Tout à fait, raison pour laquelle je disais bien que le risque n'est pas
Ce qui laisse quand même une chance sur 5 que le fil ait une
arborescence complexe et que donc le traitement soit lent.
Pas "lent", "plus lent potentiellement".
Un petit malin pourrait s'amuser à exploiter le cas où ton application
n'est pas performante rien que pour la faire ramer,
Pas difficile, il suffit de faire #!/bin/ksh while(true) wget
ou tout simplement
planter car PHP s'impose lui-même une limite dans la récursivité qui se
traduit par une erreur fatale.
Si on arrive à faire pêter le nombre d'appels empilés de PHP sur un
Qui dit classes ne veut pas dire programmation objet à tout bout de
champ comme en Java (ce qui apporte une lourdeur certaine).
Mouais, bof.
Justement pour faciliter la tâche à l'infographiste ne faudrait-il pas
mieux créer un squelette simpliste avec les formulaires qui pointent là
où il faut et les champs qui vont bien ? Même chose pour les liens
importants etc.
L'infographiste est ensuite libre de modifier.
L'oeuf ou la poule ? En pratique, c'est souvent le développeur qui
Après le truc à la mode c'est de faire un code HTML générique puis
ensuite de réaliser tout le côté graphique avec CSS.
Ce qui n'est pas évident du tout, en fait.
Je n'ai jamais dit le contraire, et justement totu ce que j'en dit c'est
Oui, mais le problème c'est que l'élégant termine souvent dans le "code
d'esthète" tellement élégant que totalement imbittable et impossible à
maintenir, le tout avec des tétrachiées de couches et de surcouches.
Tout dépend des mainteneurs.
Si on intègre du code qu'on ne comprend pas, on va avoir du mal à le
maintenir, effectivement.
Et c'est souvent le cas avec du code d'esthète, ledit esthète étant
La traduction de /library/ c'est plutôt 'bibliothèque'.
Les deux ont été utilisés il y a quelques années quand je gérais des
La différence (du moins telle que je la perçois) c'est que le framework
définit le coeur de l'application, et que les bibliothèques ne font
qu'apporter des outils qu'on peut ou non utiliser.
Vision intéressante, je l'ignore.
Si le SGBD le permet pas, il suffit de manipuler la chaîne pour le faire
à sa place.
C'est ce que font JDBC, PDO, etc.
Bof. Choisir une méthode de développement/un ensemble de classes en
J'ai bien indiqué que je me place dans le cas précis des webapp où, par
définition, on stocke des trucs (en général en sgbd) et on a *au moins*
comme canal de sortie le HTML, et j'ai bien précisé que je préfère faire
du sanitizing bourrin en entrée quitte à refaire l'opératin inverse si
un canal de sortie (ex. PDF) le nécessite, car dans le cas des webapps,
le canal principal de sortie est le HTML.
C'est vrai que c'est le canal principal de sortie, mais est-ce une
raison pour se focaliser dessus ?
Tu as dit toi-même faire usage de strip_tags.
J'interdits le html dans les saisies, donc oui.
Tu interdis non seulement le html mais aussi tout texte du type <w+.*?w+>
Oui, vu sur ton exemple le rappelant, en effet.
Exemple simple : je veux afficher les x premiers caractères d'un
enregistrement dans la base de données, pour donner un genre d'aperçu de
son contenu.
< fait 4 octets mais n'est qu'un caractère. D'où le problème, mon x
ne sera qu'approximatif.
Je ne vois pas le problème. Je n'ai pas dit qu'il n'y en a pas, je ne le
vois pas. Exemple concret SVP.
- Tri des données
Normalement on devrait avoir
Tablature
Téléphone
Transaction
Si é est é on obtient
Téléphone
Tablature
Transaction
C'est ça qui est plus que dommage avec toi, c'est que 90% de tes
De toutes façons, il est souvent dit sur fciwa que les entités (autres
que celles pour les caractères réservés) sont inutiles, il suffit de
gérer correctement l'encodage des caractères ; ce qui offre d'ailleurs
bien plus de possibilités, suivant l'encodage choisi.
Ils ont du mettre ça dans une base de données à part quand même
j'imagine (flemme de vérifier) justement pour éviter ce genre de conflits.
Tout à fait, raison pour laquelle je disais bien que le risque n'est pas
Ce qui laisse quand même une chance sur 5 que le fil ait une
arborescence complexe et que donc le traitement soit lent.
Pas "lent", "plus lent potentiellement".
Un petit malin pourrait s'amuser à exploiter le cas où ton application
n'est pas performante rien que pour la faire ramer,
Pas difficile, il suffit de faire #!/bin/ksh while(true) wget
ou tout simplement
planter car PHP s'impose lui-même une limite dans la récursivité qui se
traduit par une erreur fatale.
Si on arrive à faire pêter le nombre d'appels empilés de PHP sur un
Qui dit classes ne veut pas dire programmation objet à tout bout de
champ comme en Java (ce qui apporte une lourdeur certaine).
Mouais, bof.
Justement pour faciliter la tâche à l'infographiste ne faudrait-il pas
mieux créer un squelette simpliste avec les formulaires qui pointent là
où il faut et les champs qui vont bien ? Même chose pour les liens
importants etc.
L'infographiste est ensuite libre de modifier.
L'oeuf ou la poule ? En pratique, c'est souvent le développeur qui
Après le truc à la mode c'est de faire un code HTML générique puis
ensuite de réaliser tout le côté graphique avec CSS.
Ce qui n'est pas évident du tout, en fait.
Je n'ai jamais dit le contraire, et justement totu ce que j'en dit c'est
Oui, mais le problème c'est que l'élégant termine souvent dans le "code
d'esthète" tellement élégant que totalement imbittable et impossible à
maintenir, le tout avec des tétrachiées de couches et de surcouches.
Tout dépend des mainteneurs.
Si on intègre du code qu'on ne comprend pas, on va avoir du mal à le
maintenir, effectivement.
Et c'est souvent le cas avec du code d'esthète, ledit esthète étant
La traduction de /library/ c'est plutôt 'bibliothèque'.
Les deux ont été utilisés il y a quelques années quand je gérais des
La différence (du moins telle que je la perçois) c'est que le framework
définit le coeur de l'application, et que les bibliothèques ne font
qu'apporter des outils qu'on peut ou non utiliser.
Vision intéressante, je l'ignore.
Si le SGBD le permet pas, il suffit de manipuler la chaîne pour le faire
à sa place.
C'est ce que font JDBC, PDO, etc.
Bof. Choisir une méthode de développement/un ensemble de classes en
J'ai bien indiqué que je me place dans le cas précis des webapp où, par
définition, on stocke des trucs (en général en sgbd) et on a *au moins*
comme canal de sortie le HTML, et j'ai bien précisé que je préfère faire
du sanitizing bourrin en entrée quitte à refaire l'opératin inverse si
un canal de sortie (ex. PDF) le nécessite, car dans le cas des webapps,
le canal principal de sortie est le HTML.
C'est vrai que c'est le canal principal de sortie, mais est-ce une
raison pour se focaliser dessus ?
Tu as dit toi-même faire usage de strip_tags.
J'interdits le html dans les saisies, donc oui.
Tu interdis non seulement le html mais aussi tout texte du type <w+.*?w+>
Oui, vu sur ton exemple le rappelant, en effet.
Exemple simple : je veux afficher les x premiers caractères d'un
enregistrement dans la base de données, pour donner un genre d'aperçu de
son contenu.
< fait 4 octets mais n'est qu'un caractère. D'où le problème, mon x
ne sera qu'approximatif.
Je ne vois pas le problème. Je n'ai pas dit qu'il n'y en a pas, je ne le
vois pas. Exemple concret SVP.
- Tri des données
Normalement on devrait avoir
Tablature
Téléphone
Transaction
Si é est é on obtient
Téléphone
Tablature
Transaction
C'est ça qui est plus que dommage avec toi, c'est que 90% de tes
De toutes façons, il est souvent dit sur fciwa que les entités (autres
que celles pour les caractères réservés) sont inutiles, il suffit de
gérer correctement l'encodage des caractères ; ce qui offre d'ailleurs
bien plus de possibilités, suivant l'encodage choisi.
Ils ont du mettre ça dans une base de données à part quand même
j'imagine (flemme de vérifier) justement pour éviter ce genre de conflits.
Tout à fait, raison pour laquelle je disais bien que le risque n'est pas
Ce qui laisse quand même une chance sur 5 que le fil ait une
arborescence complexe et que donc le traitement soit lent.
Pas "lent", "plus lent potentiellement".
Un petit malin pourrait s'amuser à exploiter le cas où ton application
n'est pas performante rien que pour la faire ramer,
Pas difficile, il suffit de faire #!/bin/ksh while(true) wget
ou tout simplement
planter car PHP s'impose lui-même une limite dans la récursivité qui se
traduit par une erreur fatale.
Si on arrive à faire pêter le nombre d'appels empilés de PHP sur un
Qui dit classes ne veut pas dire programmation objet à tout bout de
champ comme en Java (ce qui apporte une lourdeur certaine).
Mouais, bof.
Justement pour faciliter la tâche à l'infographiste ne faudrait-il pas
mieux créer un squelette simpliste avec les formulaires qui pointent là
où il faut et les champs qui vont bien ? Même chose pour les liens
importants etc.
L'infographiste est ensuite libre de modifier.
L'oeuf ou la poule ? En pratique, c'est souvent le développeur qui
Après le truc à la mode c'est de faire un code HTML générique puis
ensuite de réaliser tout le côté graphique avec CSS.
Ce qui n'est pas évident du tout, en fait.
Je n'ai jamais dit le contraire, et justement totu ce que j'en dit c'est
Oui, mais le problème c'est que l'élégant termine souvent dans le "code
d'esthète" tellement élégant que totalement imbittable et impossible à
maintenir, le tout avec des tétrachiées de couches et de surcouches.
Tout dépend des mainteneurs.
Si on intègre du code qu'on ne comprend pas, on va avoir du mal à le
maintenir, effectivement.
Et c'est souvent le cas avec du code d'esthète, ledit esthète étant
La traduction de /library/ c'est plutôt 'bibliothèque'.
Les deux ont été utilisés il y a quelques années quand je gérais des
La différence (du moins telle que je la perçois) c'est que le framework
définit le coeur de l'application, et que les bibliothèques ne font
qu'apporter des outils qu'on peut ou non utiliser.
Vision intéressante, je l'ignore.
