Bienvenue sur <a href="http://hurlantenova2007.c.la">HURLANTE NOVA
2007</a></span> Pour consulter notre site vous devez vous inscrire.
Cette inscription est gratuite et vous donne acces à tout nos
services.<br />
Ceci est votre <?php
echo $_COOKIE['hnovcoockivisite'];
?> visite.
Il y a actuelement <span class="Style1">
<?php
$tab = file("enligne.txt") ;
srand((double)microtime() * 1000000) ;
$nbr = rand(0, (count($tab) - 1)) ;
echo $tab[$nbr] ;
?>
</span>internautes sur le site et <span class="Style1">
<? // Compteur PHP de hits
$fichier="compteur.txt";
// Lecture du fichier s'il existe et incrémente
$cpt = 1;
if(file_exists($fichier)) {
$inF = fopen($fichier,"r");
$cpt = intval(trim(fgets($inF, 4096))) + 1;
fclose($inF);
}
// Sauvegarde du compteur
$inF = fopen($fichier,"w");
fputs($inF,$cpt."\n");
fclose($inF);
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
[ rien d'autre que du code ]
Bonjour Akira. Tout d'abord une première remarque : il est d'usage d'expliquer de quoi il est question dans le corps d'un article, et pas seulement dans son titre.
<?php $ajout = 1 + $hnovcoockivisite;
register_global = true, et tu utilises les variables sans les tester ? C'est plutôt dangereux, ça.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml">
Mouais... m'étonnerait que tu aies vraiment besoin de XHTML, mais bon... (surtout en Transitional)
<style type="text/css"> <!--
Ce commentaire est invalide en XHTML.
[plusieurs dizaines de lignes de css] --> </style>
Au passage, mettre les css dans un fichier externe ne peut qu'améliorer les perfs si tu utilises les mêmes définitions pour toutes tes pages HTML... et cela aiderait à rendre ton code valide si tu restes en XHTML.
<noscript> <body> </noscript> <body>
Aaargh ! Si le contenu de <noscript> n'est pas ignoré, tu as deux <body>.
Ceci est votre <?php echo $_COOKIE['hnovcoockivisite'];
?> visite.
Première visite ou pas de cookie => « Ceci est votre visite »
Deuxième visite avec cookie => « Ceci est votre 2 visite »
:-(
Il y a actuelement <span class="Style1"> <?php $tab = file("enligne.txt") ; srand((double)microtime() * 1000000) ; $nbr = rand(0, (count($tab) - 1)) ; echo $tab[$nbr] ; ?> </span>internautes sur le site et <span class="Style1">
Voilà qui est très sérieux... D'un autre côté, les compteurs de visiteurs présents sont toujours de l'arnaque, alors arnaque pour arnaque, pourquoi pas un nombre aléatoire en effet !
<? // Compteur PHP de hits
$fichier="compteur.txt";
// Lecture du fichier s'il existe et incrémente $cpt = 1; if(file_exists($fichier)) { $inF = fopen($fichier,"r"); $cpt = intval(trim(fgets($inF, 4096))) + 1; fclose($inF); }
// Sauvegarde du compteur $inF = fopen($fichier,"w"); fputs($inF,$cpt."n"); fclose($inF);
Ce qui est bien, c'est qu'à chaque visite tu as un membre supplémentaire.
Bon, il faudrait que tu nous expliques ce que tu voulais exactement.
[ rien d'autre que du code ]
Bonjour Akira. Tout d'abord une première remarque : il est d'usage
d'expliquer de quoi il est question dans le corps d'un article, et pas
seulement dans son titre.
<?php
$ajout = 1 + $hnovcoockivisite;
register_global = true, et tu utilises les variables sans les tester ?
C'est plutôt dangereux, ça.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
Mouais... m'étonnerait que tu aies vraiment besoin de XHTML, mais bon...
(surtout en Transitional)
<style type="text/css">
<!--
Ce commentaire est invalide en XHTML.
[plusieurs dizaines de lignes de css]
-->
</style>
Au passage, mettre les css dans un fichier externe ne peut qu'améliorer
les perfs si tu utilises les mêmes définitions pour toutes tes pages
HTML... et cela aiderait à rendre ton code valide si tu restes en XHTML.
<noscript>
<body>
</noscript>
<body>
Aaargh ! Si le contenu de <noscript> n'est pas ignoré, tu as deux <body>.
Ceci est votre <?php
echo $_COOKIE['hnovcoockivisite'];
?> visite.
Première visite ou pas de cookie
=> « Ceci est votre visite »
Deuxième visite avec cookie
=> « Ceci est votre 2 visite »
:-(
Il y a actuelement <span class="Style1">
<?php
$tab = file("enligne.txt") ;
srand((double)microtime() * 1000000) ;
$nbr = rand(0, (count($tab) - 1)) ;
echo $tab[$nbr] ;
?>
</span>internautes sur le site et <span class="Style1">
Voilà qui est très sérieux... D'un autre côté, les compteurs de
visiteurs présents sont toujours de l'arnaque, alors arnaque pour
arnaque, pourquoi pas un nombre aléatoire en effet !
<? // Compteur PHP de hits
$fichier="compteur.txt";
// Lecture du fichier s'il existe et incrémente
$cpt = 1;
if(file_exists($fichier)) {
$inF = fopen($fichier,"r");
$cpt = intval(trim(fgets($inF, 4096))) + 1;
fclose($inF);
}
// Sauvegarde du compteur
$inF = fopen($fichier,"w");
fputs($inF,$cpt."n");
fclose($inF);
Bonjour Akira. Tout d'abord une première remarque : il est d'usage d'expliquer de quoi il est question dans le corps d'un article, et pas seulement dans son titre.
<?php $ajout = 1 + $hnovcoockivisite;
register_global = true, et tu utilises les variables sans les tester ? C'est plutôt dangereux, ça.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml">
Mouais... m'étonnerait que tu aies vraiment besoin de XHTML, mais bon... (surtout en Transitional)
<style type="text/css"> <!--
Ce commentaire est invalide en XHTML.
[plusieurs dizaines de lignes de css] --> </style>
Au passage, mettre les css dans un fichier externe ne peut qu'améliorer les perfs si tu utilises les mêmes définitions pour toutes tes pages HTML... et cela aiderait à rendre ton code valide si tu restes en XHTML.
<noscript> <body> </noscript> <body>
Aaargh ! Si le contenu de <noscript> n'est pas ignoré, tu as deux <body>.
Ceci est votre <?php echo $_COOKIE['hnovcoockivisite'];
?> visite.
Première visite ou pas de cookie => « Ceci est votre visite »
Deuxième visite avec cookie => « Ceci est votre 2 visite »
:-(
Il y a actuelement <span class="Style1"> <?php $tab = file("enligne.txt") ; srand((double)microtime() * 1000000) ; $nbr = rand(0, (count($tab) - 1)) ; echo $tab[$nbr] ; ?> </span>internautes sur le site et <span class="Style1">
Voilà qui est très sérieux... D'un autre côté, les compteurs de visiteurs présents sont toujours de l'arnaque, alors arnaque pour arnaque, pourquoi pas un nombre aléatoire en effet !
<? // Compteur PHP de hits
$fichier="compteur.txt";
// Lecture du fichier s'il existe et incrémente $cpt = 1; if(file_exists($fichier)) { $inF = fopen($fichier,"r"); $cpt = intval(trim(fgets($inF, 4096))) + 1; fclose($inF); }
// Sauvegarde du compteur $inF = fopen($fichier,"w"); fputs($inF,$cpt."n"); fclose($inF);
Ce qui est bien, c'est qu'à chaque visite tu as un membre supplémentaire.
Bon, il faudrait que tu nous expliques ce que tu voulais exactement.
Steuf
Oui possiblement Les fonction ne sont utiles que pour des partis de codes qui se répétent. (Plusieurs fois les mêmes calculs etc...) Sinon c'est parfaitement inutile.
Oui possiblement
Les fonction ne sont utiles que pour des partis de codes qui se
répétent. (Plusieurs fois les mêmes calculs etc...)
Sinon c'est parfaitement inutile.
Oui possiblement Les fonction ne sont utiles que pour des partis de codes qui se répétent. (Plusieurs fois les mêmes calculs etc...) Sinon c'est parfaitement inutile.
Techniquement, c'est peut être inutile, mais d'un point de vue organisation, séparer les sous-traitements / préoccupations aide souvent à la lisibilité et par conséquent à la maintenance du code.
Evidemment, tout est une question d'échelle, mais le mélange d'opérations d'accès aux données au milieu du code de présentation est rarement productif à long terme.
Techniquement, c'est peut être inutile, mais d'un point de vue
organisation, séparer les sous-traitements / préoccupations aide
souvent à la lisibilité et par conséquent à la maintenance du code.
Evidemment, tout est une question d'échelle, mais le mélange
d'opérations d'accès aux données au milieu du code de présentation
est rarement productif à long terme.
Techniquement, c'est peut être inutile, mais d'un point de vue organisation, séparer les sous-traitements / préoccupations aide souvent à la lisibilité et par conséquent à la maintenance du code.
Evidemment, tout est une question d'échelle, mais le mélange d'opérations d'accès aux données au milieu du code de présentation est rarement productif à long terme.
AkiraChaplin
merci pour ta lecture c'est mon 1er script et je suis amusé qu'on puisse le lire
le resultat est a cette url : http://s149314122.onlinehome.fr/hurlantenova2007/hurlantenova.php
ceci est juste un pre squelette je veux dans l'absolut créer une interface dynamique basé sur : - un visiteur arrive sur le site (alors) une page web est créé avec son ip - des informations sont ajouté a sa page pendant qu'il visite le site - ces informations sont relative à sa navigation - pendant sa navigation ou lorsqu'il qu'il quite le site ou lors ce qu'il revient : on lui propose de voir sa page créer, celle ci contient des informations sensible de l'interessé.
En résumé : créer une page web juste en navigant création robotisé d'un site en fonction des visiteurs et de leurs navigations.
......
merci pour ta lecture
c'est mon 1er script
et je suis amusé qu'on puisse le lire
le resultat est a cette url :
http://s149314122.onlinehome.fr/hurlantenova2007/hurlantenova.php
ceci est juste un pre squelette
je veux dans l'absolut créer une interface dynamique basé sur :
- un visiteur arrive sur le site (alors) une page web est créé avec
son ip
- des informations sont ajouté a sa page pendant qu'il visite le site
- ces informations sont relative à sa navigation
- pendant sa navigation ou lorsqu'il qu'il quite le site ou lors ce
qu'il revient : on lui propose de voir sa page créer, celle ci
contient des informations sensible de l'interessé.
En résumé :
créer une page web juste en navigant
création robotisé d'un site en fonction des visiteurs et de leurs
navigations.
merci pour ta lecture c'est mon 1er script et je suis amusé qu'on puisse le lire
le resultat est a cette url : http://s149314122.onlinehome.fr/hurlantenova2007/hurlantenova.php
ceci est juste un pre squelette je veux dans l'absolut créer une interface dynamique basé sur : - un visiteur arrive sur le site (alors) une page web est créé avec son ip - des informations sont ajouté a sa page pendant qu'il visite le site - ces informations sont relative à sa navigation - pendant sa navigation ou lorsqu'il qu'il quite le site ou lors ce qu'il revient : on lui propose de voir sa page créer, celle ci contient des informations sensible de l'interessé.
En résumé : créer une page web juste en navigant création robotisé d'un site en fonction des visiteurs et de leurs navigations.
......
AkiraChaplin
réponse grandiose, merci néanmoins imaginos que la conception d'un page soit pensé des le départ en prennant en compte une construction complexe a variable multiple alors la maintenance se ferait aisément ?
réponse grandiose, merci
néanmoins
imaginos que la conception d'un page soit pensé des le départ en
prennant en compte une construction complexe a variable multiple
alors
la maintenance se ferait aisément ?
réponse grandiose, merci néanmoins imaginos que la conception d'un page soit pensé des le départ en prennant en compte une construction complexe a variable multiple alors la maintenance se ferait aisément ?
fgirault
grandiose ma réponse qui étale des généralités éculés ? j'en doute fort mais merci quand même :)
il n'y a pas vraiment de recette miracle pour garantir qu'un code sera maintenable. (certes il reste la boule de cristal, les viscères de poulet, le marre de café ...)
tout ce passe entre la chaise et le clavier !
c'est en général en apprenant de ses propres erreurs (et celles des autres) qu'on "trouve la voie". bref, l'expérience (ça tombe bien, ici, pas mal d'intervenants en possèdent une bonne couche ;) ), de laquelle émerge les "bonnes pratiques".
et celle que je préfère : séparer clairement les préoccupations, car produire du html n'a rien à voir avec des accès fichiers ou base de données. on rassemble des données, et on les injecte dans du html pour présenter ces données. mais par pitié, pas de code sql ou d'accès aux fichiers au milieu du html. dans votre cas, faites une batterie de fonctions qui vont lire et écrire vos fichiers dans un source à part. le jour où il faut modifier quelque chose, on ne cherche pas dans quelques milliers de lignes de langages hétérogènes, mais dans le seul fichier source concerné.
j'ai pu voir les pires cochonneries où des requêtes sql généraient directement du javascript, ou encore du code html dans des champs de base de données (sympa quand il faut retoucher 10000 enregistrements quand la classe css a changé), etc, etc ...
php n'impose aucune contrainte là dessus, mais je dirais qu'on a les défauts de ses qualités et vice-versa :)
grandiose ma réponse qui étale des généralités éculés ? j'en
doute fort mais merci quand même :)
il n'y a pas vraiment de recette miracle pour garantir qu'un code sera
maintenable. (certes il reste la boule de cristal, les viscères de
poulet, le marre de café ...)
tout ce passe entre la chaise et le clavier !
c'est en général en apprenant de ses propres erreurs (et celles des
autres) qu'on "trouve la voie". bref, l'expérience (ça tombe bien,
ici, pas mal d'intervenants en possèdent une bonne couche ;) ), de
laquelle émerge les "bonnes pratiques".
et celle que je préfère : séparer clairement les préoccupations,
car produire du html n'a rien à voir avec des accès fichiers ou base
de données. on rassemble des données, et on les injecte dans du html
pour présenter ces données. mais par pitié, pas de code sql ou
d'accès aux fichiers au milieu du html. dans votre cas, faites une
batterie de fonctions qui vont lire et écrire vos fichiers dans un
source à part. le jour où il faut modifier quelque chose, on ne
cherche pas dans quelques milliers de lignes de langages
hétérogènes, mais dans le seul fichier source concerné.
j'ai pu voir les pires cochonneries où des requêtes sql généraient
directement du javascript, ou encore du code html dans des champs de
base de données (sympa quand il faut retoucher 10000 enregistrements
quand la classe css a changé), etc, etc ...
php n'impose aucune contrainte là dessus, mais je dirais qu'on a les
défauts de ses qualités et vice-versa :)
grandiose ma réponse qui étale des généralités éculés ? j'en doute fort mais merci quand même :)
il n'y a pas vraiment de recette miracle pour garantir qu'un code sera maintenable. (certes il reste la boule de cristal, les viscères de poulet, le marre de café ...)
tout ce passe entre la chaise et le clavier !
c'est en général en apprenant de ses propres erreurs (et celles des autres) qu'on "trouve la voie". bref, l'expérience (ça tombe bien, ici, pas mal d'intervenants en possèdent une bonne couche ;) ), de laquelle émerge les "bonnes pratiques".
et celle que je préfère : séparer clairement les préoccupations, car produire du html n'a rien à voir avec des accès fichiers ou base de données. on rassemble des données, et on les injecte dans du html pour présenter ces données. mais par pitié, pas de code sql ou d'accès aux fichiers au milieu du html. dans votre cas, faites une batterie de fonctions qui vont lire et écrire vos fichiers dans un source à part. le jour où il faut modifier quelque chose, on ne cherche pas dans quelques milliers de lignes de langages hétérogènes, mais dans le seul fichier source concerné.
j'ai pu voir les pires cochonneries où des requêtes sql généraient directement du javascript, ou encore du code html dans des champs de base de données (sympa quand il faut retoucher 10000 enregistrements quand la classe css a changé), etc, etc ...
php n'impose aucune contrainte là dessus, mais je dirais qu'on a les défauts de ses qualités et vice-versa :)
fgirault
grandiose ma réponse qui étale des généralités éculés ? j'en doute fort mais merci quand même :)
il n'y a pas vraiment de recette miracle pour garantir qu'un code sera maintenable. (certes il reste la boule de cristal, les viscères de poulet, le marre de café ...)
tout ce passe entre la chaise et le clavier !
c'est en général en apprenant de ses propres erreurs (et celles des autres) qu'on "trouve la voie". bref, l'expérience (ça tombe bien, ici, pas mal d'intervenants en possèdent une bonne couche ;) ), de laquelle émerge les "bonnes pratiques".
et celle que je préfère : séparer clairement les préoccupations, car produire du html n'a rien à voir avec des accès fichiers ou base de données. on rassemble des données, et on les injecte dans du html pour présenter ces données. mais par pitié, pas de code sql ou d'accès aux fichiers au milieu du html. dans votre cas, faites une batterie de fonctions qui vont lire et écrire vos fichiers dans un source à part. le jour où il faut modifier quelque chose, on ne cherche pas dans quelques milliers de lignes de langages hétérogènes, mais dans le seul fichier source concerné.
j'ai pu voir les pires cochonneries où des requêtes sql généraient directement du javascript, ou encore du code html dans des champs de base de données (sympa quand il faut retoucher 10000 enregistrements quand la classe css a changé), etc, etc ...
php n'impose aucune contrainte là dessus, mais je dirais qu'on a les défauts de ses qualités et vice-versa :)
grandiose ma réponse qui étale des généralités éculés ? j'en
doute fort mais merci quand même :)
il n'y a pas vraiment de recette miracle pour garantir qu'un code sera
maintenable. (certes il reste la boule de cristal, les viscères de
poulet, le marre de café ...)
tout ce passe entre la chaise et le clavier !
c'est en général en apprenant de ses propres erreurs (et celles des
autres) qu'on "trouve la voie". bref, l'expérience (ça tombe bien,
ici, pas mal d'intervenants en possèdent une bonne couche ;) ), de
laquelle émerge les "bonnes pratiques".
et celle que je préfère : séparer clairement les préoccupations,
car produire du html n'a rien à voir avec des accès fichiers ou base
de données. on rassemble des données, et on les injecte dans du html
pour présenter ces données. mais par pitié, pas de code sql ou
d'accès aux fichiers au milieu du html. dans votre cas, faites une
batterie de fonctions qui vont lire et écrire vos fichiers dans un
source à part. le jour où il faut modifier quelque chose, on ne
cherche pas dans quelques milliers de lignes de langages
hétérogènes, mais dans le seul fichier source concerné.
j'ai pu voir les pires cochonneries où des requêtes sql généraient
directement du javascript, ou encore du code html dans des champs de
base de données (sympa quand il faut retoucher 10000 enregistrements
quand la classe css a changé), etc, etc ...
php n'impose aucune contrainte là dessus, mais je dirais qu'on a les
défauts de ses qualités et vice-versa :)
grandiose ma réponse qui étale des généralités éculés ? j'en doute fort mais merci quand même :)
il n'y a pas vraiment de recette miracle pour garantir qu'un code sera maintenable. (certes il reste la boule de cristal, les viscères de poulet, le marre de café ...)
tout ce passe entre la chaise et le clavier !
c'est en général en apprenant de ses propres erreurs (et celles des autres) qu'on "trouve la voie". bref, l'expérience (ça tombe bien, ici, pas mal d'intervenants en possèdent une bonne couche ;) ), de laquelle émerge les "bonnes pratiques".
et celle que je préfère : séparer clairement les préoccupations, car produire du html n'a rien à voir avec des accès fichiers ou base de données. on rassemble des données, et on les injecte dans du html pour présenter ces données. mais par pitié, pas de code sql ou d'accès aux fichiers au milieu du html. dans votre cas, faites une batterie de fonctions qui vont lire et écrire vos fichiers dans un source à part. le jour où il faut modifier quelque chose, on ne cherche pas dans quelques milliers de lignes de langages hétérogènes, mais dans le seul fichier source concerné.
j'ai pu voir les pires cochonneries où des requêtes sql généraient directement du javascript, ou encore du code html dans des champs de base de données (sympa quand il faut retoucher 10000 enregistrements quand la classe css a changé), etc, etc ...
php n'impose aucune contrainte là dessus, mais je dirais qu'on a les défauts de ses qualités et vice-versa :)