N'étant pas très doué je n'arrive pas à modifié les 3 scripts suivants.
Il fonctionne très bien sous php4 mais rien à faire sous php5.
1) la recherche ne se fait pas
2) l'affichage dans le pop est vide
Merci à celui qui voudras bien me résoudre cet incident.
Amitiés
Début des scripts
INDEX.PHP
<?php /* echo "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?".">"; */?>
<?
//INCLUSION DU FICHIER DE CONNEXION
include("connect.inc");
//CONNEXION A LA BASE
$mysql_id=mysql_connect($server,$user,$pwd);
// Sortir du script en cas de problème de connexion
//au serveur.
if(!$mysql_id){
echo "Problème de connexion à la base : ".mysql_errno().":
".mysql_error()."<br />";
exit;
}
//SELECTION DE LA BASE
mysql_select_db($base,$mysql_id);
//SELECTION DE LA TABLE
$table = 'FP_Complet';
//CONSTRUCTION DE LA CLAUSE 'WHERE'
if ($nom){ // Si un nom est inscrit dans le formulaire
$where=" WHERE nom LIKE '%".$nom. "%'";
if ($prenom){ // Si le prénom est aussi renseigné
$where=" WHERE nom='".$nom."' AND prenom LIKE '%".$prenom. "%'";
}
}
else{ // Les deux champs sont vides
$where="";
}
//CONSTRUCTION DE LA CLAUSE 'LIMIT'
//Nombre d'enregistrements souhaités par page
$nb_par_page=10;
if (!$page){
$ligne_debut=0;
}
else{
$page=$page-1;
$ligne_debut=$page*$nb_par_page;
}
$limit=" LIMIT ".$ligne_debut.", ".$nb_par_page;
//REQUETE SQL
$qry="SELECT * FROM $table".$where." ORDER BY nom " .$limit;
//echo $qry;
//EXECUTION DE LA REQUETE
$result=mysql_query($qry);
if (!$nb_pages) { // Si le nb de pages n'a encore jamais été calculé
if ($nom){
$nb_fiches_max=mysql_num_rows($result);
}
else{
$qry2="SELECT * FROM $table";
//echo $qry2;
$result2=mysql_query($qry2);
$nb_fiches_max=mysql_num_rows($result2);
}
$nb_pages=($nb_fiches_max/$nb_par_page);
$nb_pages=ceil($nb_pages);
}
// MESSAGE AU DESSUS DU TABLEAU
if ($nb_fiches_max > 0){ //S'il y a au moins un résultat
$page=$page+1;
$msg= "page ".$page." sur ".$nb_pages; //On affiche le nombre de
pages sur le total
}
else{
$msg="Désolé, aucun enregistrement trouvé !"; //Sinon, on signale
qu'il n'y a pas de résultats
}
?>
body{
background-color:#ffffff;
font-family: Trebuchet MS,Verdana,Geneva,Arial,Helvetica,sans-serif;
}
table.result{
font-family:Arial,sans-serif;
border-collapse:collapse;
border:1px solid #333333;
margin-top:10px;
width:780px;
text-align: center;
}
td.nom {
padding:5px;
width: 200px;
border:1px solid #333333;
text-align: center;
background-color:#087417;
color:#ffffff;
}
td.prenom {
padding:5px;
width: 250px;
border:1px solid #333333;
text-align: center;
background-color:#087417;
color:#ffffff;
}
td {
border:1px solid #333333;
padding:3px;
text-align: left;
}
span.page{
padding-left: 10px;
}
div.pages{
text-align: center;
padding-top: 5px;
}
</style>
</head>
<div align="center">
<body bgcolor="#E7FFB3"><h1>Les fonctionnaires dans les registres</h1>
Vous trouverez ici les données de fonctionnaires vues dans
les registres.<br>
<strong>Pourquoi cette base?</strong><br>
Le fait que les fonctionnaires soient appelés à se déplacer les rends
difficilement localisables.<br>
<br>
</div><center>
<?
##########################
# Recherche infos pour affichage des infos completes
$r=mysql_query("SELECT id FROM $table ORDER by id DESC LIMIT 1 " );
while($row =mysql_fetch_array($r))
{
echo ("<b><p>Il y a "); ?>
<font color="#006599">
<? echo (" $row[id] "); ?>
</font>
<? echo (" entrées dans la base <br> "); }
//$r=mysql_query("SELECT nom, id FROM $table ORDER by id LIMIT 1 ");
// while($row =mysql_fetch_array($r))
// {
// echo ("Pour "); ?>
<font color="#006599">
<? // echo (" $row[id] "); ?>
</font>
<?// echo (" patronymes dans la base<br></b>"); }
?>
</div>
<!-- FIN FORMULAIRE -->
<br><br>
Interrogez la base par départements<br>
<a href="FP_cartes.php">Lieux des registres</a><br>
<a href="FP_cartes_n.php">Lieux de naissances</a><br>
Lieux de décès à l'étude
<br>
<?php
echo "<br />\n"; //On passe une ligne
include ('../../Pied_page.php'); ?>
</center>
</body>
</html>
<?php /* echo "<?xml version=\"1.0\" encoding=\"iso-8859-1\"?".">"; */?>
<?php
//INCLUSION DU FICHIER DE CONNEXION
include("connect.inc");
//CONNEXION A LA BASE
$mysql_id=mysql_connect($server,$user,$pwd);
// Sortir du script en cas de problème de connexion
//au serveur.
if(!$mysql_id){
echo "Problème de connexion à la base : ".mysql_errno().":
".mysql_error()."<br />";
exit;
}
//SELECTION DE LA BASE
mysql_select_db($base,$mysql_id);
//SELECTION DE LA TABLE
$table = 'FP_Complet'; // Le nom de cette table ne passe pas chez Sivit !
//CONSTRUCTION DE LA CLAUSE 'WHERE'
if ($nom){ // Si un nom est inscrit dans le formulaire
$where=" WHERE Nom LIKE '%". $nom. "%'";
if ($prenom){ // Si le prénom est aussi renseigné
$where=" WHERE nom='". $nom."' AND prenom LIKE '%".$prenom. "%'";
}
}
else{ // Les deux champs sont vides
$where="";
}
//CONSTRUCTION DE LA CLAUSE 'LIMIT'
//Nombre d'enregistrements souhaités par page
$nb_par_page=50;
if (!$page){
$ligne_debut=0;
}
else{
$page=$page-1;
$ligne_debut=$page*$nb_par_page;
}
$limit=" LIMIT ".$ligne_debut.", ".$nb_par_page;
//REQUETE SQL
$qry="SELECT * FROM $table".$where." ORDER BY nom " .$limit;
//echo $qry;
//EXECUTION DE LA REQUETE
$result=mysql_query($qry);
if (!$nb_pages) { // Si le nb de pages n'a encore jamais été calculé
if ($nom){
$nb_fiches_max=mysql_num_rows($result);
}
else{
$qry2="SELECT * FROM $table";
//echo $qry2;
$result2=mysql_query($qry2);
$nb_fiches_max=mysql_num_rows($result2);
}
$nb_pages=($nb_fiches_max/$nb_par_page);
$nb_pages=ceil($nb_pages);
}
// MESSAGE AU DESSUS DU TABLEAU
if ($nb_fiches_max > 0){ //S'il y a au moins un résultat
$page=$page+1;
$msg= "page ".$page." sur ".$nb_pages; //On affiche le nombre de
pages sur le total
}
else{
$msg="Désolé, aucun enregistrement trouvé !"; //Sinon, on signale
qu'il n'y a pas de résultats
}
?>
<!DOCTYPE php PUBLIC "-//W3C//DTD Xphp 1.1//EN"
"http://www.w3.org/TR/xphp11/DTD/xphp11.dtd"><head>
<title>Fonctionnaires</title>
<center><h1>Les fonctionnaires dans les registres</h1></center>
<?php
echo $msg."\n"; // On écrit le message au dessus du tableau
?>
<!-- EN-TÊTES DU TABLEAU -->
<center>
Pour obtenir les informations complètes vous devez accepter les 'pop-up'
de ce site<br><br>
Cliquez sur la ligne de votre choix.
<link rel="stylesheet" href="base_resultat.css" type="text/css">
</table>
</center>
<!-- FIN REMPLISSAGE DU TABLEAU -->
</div>
<!-- LIENS VERS LES AUTRES PAGES -->
<div align="center" class="pages">
<?php
$i=0;
while ($i <= $nb_pages-1):
$j=$i+1;
if ((!$nom) AND (!$prenom)){
echo "<span class=\"page\"><a
href=\"FP_adh.php?page=".$j."&nb_pages=".$nb_pages."\">".$j."</a></span>\n";
}
else if (($nom) AND ($prenom)) {
echo "<span class=\"page\"><a
href=\"FP_adh.php?page=".$j."&nb_pages=".$nb_pages."&nom=".$nom."&prenom=".$prenom."\">".$j."</a></span>\n";
}
else{
echo "<span class=\"page\"><a
href=\"FP_adh.php?page=".$j."&nb_pages=".$nb_pages."&nom=".$nom."\">".$j."</a></span>\n";
}
$i++;
endwhile;
?>
</div>
<!-- FIN LIENS VERS LES AUTRES PAGES -->
<?php
echo "<br />\n"; //On passe une ligne
include ('../../Pied_page.php'); ?>
</body>
</html>
<?
//INCLUSION DU FICHIER DE CONNEXION
include("connect.inc");
//CONNEXION A LA BASE
$mysql_id=mysql_connect($server,$user,$pwd);
// Sortir du script en cas de problème de connexion
//au serveur.
if(!$mysql_id){
echo "Problème de connexion à la base : ".mysql_errno().":
".mysql_error()."<br />";
exit;
}
//SELECTION DE LA BASE
mysql_select_db($base,$mysql_id);
//SELECTION DE LA TABLE
$table = 'FP_Complet'; // Le nom de cette table ne passe pas chez Sivit !
//REQUETE SQL
$qry="SELECT * FROM $table WHERE id='".$id."'";
//echo $qry;
//EXECUTION DE LA REQUETE
$result=mysql_query($qry);
<hr width="50%" />
<?
//Cote
if ($cote){
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Cote du
document: </span><span>$cote</span></div>";
}
//Titre
if ($titre){
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Titre du
document: </span><span>$titre</span></div>";
}
?>
<hr width="50%" />
<?
//Profession
if ($profession){
echo "<div style=\"padding-left: 15px;\"><span
class=\"bold\">Profession: </span><span>$profession</span></div>";
}
//LIGNE NAISSANCE
if (($date_n) AND ($lieu_n) AND ($dpt_n)) { // Si le lieu et la date de
naissance sont présents
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Né le
</span><span>$date_n</span><span class=\"bold\"> à
</span><span>$lieu_n</span> (<span>$dpt_n</span>)</div>";
}
else if (($date_n) AND (!$lieu_n) AND ($dpt_n)){ // Si la date de
naissance est présente mais pas le lieu
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Né le
</span><span>$date_n</span> dans le <span>$dpt_,</span></div>";
}
else if ((!$date_n) AND ($lieu_n) AND ($dpt_n)){ // Si le lieu est
présent sans la date de naissance (si ça existe ;-))
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Né à
</span><span>$lieu_n</span> (<span>$dpt_n</span>)</div>";
}
// Type acte
if ($acte){
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Type
d'acte: </span><span>$acte</span></div>";
}
// Date de l'acte
if ($date_acte){
echo "<div style=\"padding-left: 15px;\"><span class=\"bold\">Date de
l'acte: </span><span>$date_acte</span></div>";
}
La vraie difficulté est de comprendre les effets de register_globals sur le comportement de PHP en terme de transmission d'informations entre pages, c'est très largement documenté dans des tutoriels disponibles en ligne. L'essentiel est que tu ais compris le mécanisme et résolu ton problème. Inutile je pense, compte tenu du grand nombre de sites traitant déjà de cela, d'écrire une documentation supplémentaire, même si cette proposition t'honore :)
Dire que j'ai compris est bien grand mot! J'ai résolu un problème c'est tout. Cela marche sur cette table maintenant je vais faire du copié-collé pour toutes mes autres tables.
Quant à la documentation elle existe belle et bien mais faite par des spécialistes pour des spécialistes! Si vraiment elle avait été faite pour des novices je n'aurais probablement jamais posé la question car j'aurais trouvé la solution à mon problème. A noter que le lien que tu m'as indiqué est meilleur que les autres sur ce point.
Je fais de l'entraide dans d'autres domaines et il me parait important de transmettre ce que je sais en étant le plus proche possible en langage de celui qui démarre. Lorsque je fais un mode opératoire c'est du pas à pas cad un clic égale un commentaire écrit. Je préfère 50 lignes inutiles car je suis sûr que l'information est complète et peut être comprise de quiconque.
Amitiés
-- Yannick VOYEAUD
Bonjour,
Eric Demeester a écrit :
La vraie difficulté est de comprendre les effets de register_globals sur
le comportement de PHP en terme de transmission d'informations entre
pages, c'est très largement documenté dans des tutoriels disponibles en
ligne. L'essentiel est que tu ais compris le mécanisme et résolu ton
problème. Inutile je pense, compte tenu du grand nombre de sites
traitant déjà de cela, d'écrire une documentation supplémentaire, même
si cette proposition t'honore :)
Dire que j'ai compris est bien grand mot!
J'ai résolu un problème c'est tout.
Cela marche sur cette table maintenant je vais faire du copié-collé pour
toutes mes autres tables.
Quant à la documentation elle existe belle et bien mais faite par des
spécialistes pour des spécialistes!
Si vraiment elle avait été faite pour des novices je n'aurais
probablement jamais posé la question car j'aurais trouvé la solution à
mon problème.
A noter que le lien que tu m'as indiqué est meilleur que les autres sur
ce point.
Je fais de l'entraide dans d'autres domaines et il me parait important
de transmettre ce que je sais en étant le plus proche possible en
langage de celui qui démarre.
Lorsque je fais un mode opératoire c'est du pas à pas cad un clic égale
un commentaire écrit. Je préfère 50 lignes inutiles car je suis sûr que
l'information est complète et peut être comprise de quiconque.
La vraie difficulté est de comprendre les effets de register_globals sur le comportement de PHP en terme de transmission d'informations entre pages, c'est très largement documenté dans des tutoriels disponibles en ligne. L'essentiel est que tu ais compris le mécanisme et résolu ton problème. Inutile je pense, compte tenu du grand nombre de sites traitant déjà de cela, d'écrire une documentation supplémentaire, même si cette proposition t'honore :)
Dire que j'ai compris est bien grand mot! J'ai résolu un problème c'est tout. Cela marche sur cette table maintenant je vais faire du copié-collé pour toutes mes autres tables.
Quant à la documentation elle existe belle et bien mais faite par des spécialistes pour des spécialistes! Si vraiment elle avait été faite pour des novices je n'aurais probablement jamais posé la question car j'aurais trouvé la solution à mon problème. A noter que le lien que tu m'as indiqué est meilleur que les autres sur ce point.
Je fais de l'entraide dans d'autres domaines et il me parait important de transmettre ce que je sais en étant le plus proche possible en langage de celui qui démarre. Lorsque je fais un mode opératoire c'est du pas à pas cad un clic égale un commentaire écrit. Je préfère 50 lignes inutiles car je suis sûr que l'information est complète et peut être comprise de quiconque.
Amitiés
-- Yannick VOYEAUD
Eric Demeester
dans (in) fr.comp.lang.php, Yannick ecrivait (wrote) :
Bonjour,
Dire que j'ai compris est bien grand mot!
Mais si tu verras, avec le temps ça rentrera. On a tous débuté...
Cela marche sur cette table maintenant je vais faire du copié-collé pour toutes mes autres tables.
Attention au copié-collé, ça aide parfois, mais si on ne comprend pas au moins un peu ce qu'on fait, ça peut être dangereux...
Quant à la documentation elle existe belle et bien mais faite par des spécialistes pour des spécialistes!
On trouve de tout, mais il est vrai que les références « officielles » de PHP ne sont pas forcément évidentes à assimiler, surtout quand on débute.
A noter que le lien que tu m'as indiqué est meilleur que les autres sur ce point.
Si tu parles de http://www.siteduzero.com, même s'il est parfois décrié par les puristes, je trouve qu'il est très didactique, tout est expliqué pas à pas. C'est l'idéal quand on débute, ou pour trouver un exemple simple quand on a comme moi (la vieillesse est un naufrage) des trous de mémoire.
Je te conseille si tu as le temps, de suivre les cours de PHP proposés sur ce site. C'est progressif, simple, plein d'exemples pour faire des tests, et des QCM permettent à la fin de chaque chapitre de vérifier l'acquisition des connaissances.
Lorsque je fais un mode opératoire c'est du pas à pas cad un clic égale un commentaire écrit.
C'est une excellente habitude de commenter au maximum ce qu'on écrit. Cela permet de se relire facilement et ça aide, du moins en mon cas, à mémoriser.
Bon courage pour la suite !
-- Eric
dans (in) fr.comp.lang.php, Yannick <76@voyeaud.org> ecrivait (wrote) :
Bonjour,
Dire que j'ai compris est bien grand mot!
Mais si tu verras, avec le temps ça rentrera. On a tous débuté...
Cela marche sur cette table maintenant je vais faire du copié-collé pour
toutes mes autres tables.
Attention au copié-collé, ça aide parfois, mais si on ne comprend pas au
moins un peu ce qu'on fait, ça peut être dangereux...
Quant à la documentation elle existe belle et bien mais faite par des
spécialistes pour des spécialistes!
On trouve de tout, mais il est vrai que les références « officielles »
de PHP ne sont pas forcément évidentes à assimiler, surtout quand on
débute.
A noter que le lien que tu m'as indiqué est meilleur que les autres sur
ce point.
Si tu parles de http://www.siteduzero.com, même s'il est parfois décrié
par les puristes, je trouve qu'il est très didactique, tout est expliqué
pas à pas. C'est l'idéal quand on débute, ou pour trouver un exemple
simple quand on a comme moi (la vieillesse est un naufrage) des trous de
mémoire.
Je te conseille si tu as le temps, de suivre les cours de PHP proposés
sur ce site. C'est progressif, simple, plein d'exemples pour faire des
tests, et des QCM permettent à la fin de chaque chapitre de vérifier
l'acquisition des connaissances.
Lorsque je fais un mode opératoire c'est du pas à pas cad un clic égale
un commentaire écrit.
C'est une excellente habitude de commenter au maximum ce qu'on écrit.
Cela permet de se relire facilement et ça aide, du moins en mon cas, à
mémoriser.
dans (in) fr.comp.lang.php, Yannick ecrivait (wrote) :
Bonjour,
Dire que j'ai compris est bien grand mot!
Mais si tu verras, avec le temps ça rentrera. On a tous débuté...
Cela marche sur cette table maintenant je vais faire du copié-collé pour toutes mes autres tables.
Attention au copié-collé, ça aide parfois, mais si on ne comprend pas au moins un peu ce qu'on fait, ça peut être dangereux...
Quant à la documentation elle existe belle et bien mais faite par des spécialistes pour des spécialistes!
On trouve de tout, mais il est vrai que les références « officielles » de PHP ne sont pas forcément évidentes à assimiler, surtout quand on débute.
A noter que le lien que tu m'as indiqué est meilleur que les autres sur ce point.
Si tu parles de http://www.siteduzero.com, même s'il est parfois décrié par les puristes, je trouve qu'il est très didactique, tout est expliqué pas à pas. C'est l'idéal quand on débute, ou pour trouver un exemple simple quand on a comme moi (la vieillesse est un naufrage) des trous de mémoire.
Je te conseille si tu as le temps, de suivre les cours de PHP proposés sur ce site. C'est progressif, simple, plein d'exemples pour faire des tests, et des QCM permettent à la fin de chaque chapitre de vérifier l'acquisition des connaissances.
Lorsque je fais un mode opératoire c'est du pas à pas cad un clic égale un commentaire écrit.
C'est une excellente habitude de commenter au maximum ce qu'on écrit. Cela permet de se relire facilement et ça aide, du moins en mon cas, à mémoriser.
Bon courage pour la suite !
-- Eric
Mickael Wolff
Eric Demeester wrote:
1. on initialise les variables
Complètement d'accord.
2. on les récupère via $_REQUEST en vérifiant au passage si elles existent et sont non vides)
Complètement pas d'accord. Il faut traiter $_GET (pour déterminer les ressources consultées) et $_POST (pour déterminer les alterations des ressources. Et je ne vois pas pourquoi une valeur vide serait incorrecte.
3. on effectue les traitements associés aux variables (interrogation de la base de données ou tout autre traitement)
Ce que je trouve dommage c'est que tu traites indistinctement les données d'alteration et de consultation.
4. on affiche les résultats
Certes.
Même principe que ci-dessus, il faut récupérer les variables et les traiter _avant_ de les afficher. Après, l'endroit et l'ordre dans lequels elles seront affichées dans la page importe peu...
Ce qui est intéressant de préciser, c'est que cette méthode permet de faciliter l'affichage de messages d'erreur.
La vraie difficulté est de comprendre les effets de register_globals sur le comportement de PHP en terme de transmission d'informations entre pages, c'est très largement documenté dans des tutoriels disponibles en ligne. L'essentiel est que tu ais compris le mécanisme et résolu ton problème. Inutile je pense, compte tenu du grand nombre de sites traitant déjà de cela, d'écrire une documentation supplémentaire, même si cette proposition t'honore :)
Surtout que le problème est tellement commun et général qu'il existe des ressources de partout ;)
2. on les récupère via $_REQUEST en vérifiant au passage si elles
existent et sont non vides)
Complètement pas d'accord. Il faut traiter $_GET (pour déterminer les
ressources consultées) et $_POST (pour déterminer les alterations des
ressources. Et je ne vois pas pourquoi une valeur vide serait incorrecte.
3. on effectue les traitements associés aux variables (interrogation
de la base de données ou tout autre traitement)
Ce que je trouve dommage c'est que tu traites indistinctement les
données d'alteration et de consultation.
4. on affiche les résultats
Certes.
Même principe que ci-dessus, il faut récupérer les variables et les
traiter _avant_ de les afficher. Après, l'endroit et l'ordre dans
lequels elles seront affichées dans la page importe peu...
Ce qui est intéressant de préciser, c'est que cette méthode permet de
faciliter l'affichage de messages d'erreur.
La vraie difficulté est de comprendre les effets de register_globals sur
le comportement de PHP en terme de transmission d'informations entre
pages, c'est très largement documenté dans des tutoriels disponibles en
ligne. L'essentiel est que tu ais compris le mécanisme et résolu ton
problème. Inutile je pense, compte tenu du grand nombre de sites
traitant déjà de cela, d'écrire une documentation supplémentaire, même
si cette proposition t'honore :)
Surtout que le problème est tellement commun et général qu'il existe
des ressources de partout ;)
2. on les récupère via $_REQUEST en vérifiant au passage si elles existent et sont non vides)
Complètement pas d'accord. Il faut traiter $_GET (pour déterminer les ressources consultées) et $_POST (pour déterminer les alterations des ressources. Et je ne vois pas pourquoi une valeur vide serait incorrecte.
3. on effectue les traitements associés aux variables (interrogation de la base de données ou tout autre traitement)
Ce que je trouve dommage c'est que tu traites indistinctement les données d'alteration et de consultation.
4. on affiche les résultats
Certes.
Même principe que ci-dessus, il faut récupérer les variables et les traiter _avant_ de les afficher. Après, l'endroit et l'ordre dans lequels elles seront affichées dans la page importe peu...
Ce qui est intéressant de préciser, c'est que cette méthode permet de faciliter l'affichage de messages d'erreur.
La vraie difficulté est de comprendre les effets de register_globals sur le comportement de PHP en terme de transmission d'informations entre pages, c'est très largement documenté dans des tutoriels disponibles en ligne. L'essentiel est que tu ais compris le mécanisme et résolu ton problème. Inutile je pense, compte tenu du grand nombre de sites traitant déjà de cela, d'écrire une documentation supplémentaire, même si cette proposition t'honore :)
Surtout que le problème est tellement commun et général qu'il existe des ressources de partout ;)
Si tu parles de http://www.siteduzero.com, même s'il est parfois décrié par les puristes, je trouve qu'il est très didactique, tout est expliqué pas à pas. C'est l'idéal quand on débute, ou pour trouver un exemple simple quand on a comme moi (la vieillesse est un naufrage) des trous de mémoire.
Il n'est pas décrié, il est honnis. Les imprécisions et les mauvaises pratiques en font une source de médiocrité constante/
Je te conseille si tu as le temps, de suivre les cours de PHP proposés sur ce site. C'est progressif, simple, plein d'exemples pour faire des tests, et des QCM permettent à la fin de chaque chapitre de vérifier l'acquisition des connaissances.
Je n'ai jamais compris en quoi les QCM sont une méthode fiable de sondage des connaissances. En plus, ils sont souvent faux sur ce site.
C'est une excellente habitude de commenter au maximum ce qu'on écrit. Cela permet de se relire facilement et ça aide, du moins en mon cas, à mémoriser.
C'est une très mauvaise idée de commenter excessivement. Il faut commenter à point nommé, ce qui est nécessaire.
Si tu parles de http://www.siteduzero.com, même s'il est parfois décrié
par les puristes, je trouve qu'il est très didactique, tout est expliqué
pas à pas. C'est l'idéal quand on débute, ou pour trouver un exemple
simple quand on a comme moi (la vieillesse est un naufrage) des trous de
mémoire.
Il n'est pas décrié, il est honnis. Les imprécisions et les mauvaises
pratiques en font une source de médiocrité constante/
Je te conseille si tu as le temps, de suivre les cours de PHP proposés
sur ce site. C'est progressif, simple, plein d'exemples pour faire des
tests, et des QCM permettent à la fin de chaque chapitre de vérifier
l'acquisition des connaissances.
Je n'ai jamais compris en quoi les QCM sont une méthode fiable de
sondage des connaissances. En plus, ils sont souvent faux sur ce site.
C'est une excellente habitude de commenter au maximum ce qu'on écrit.
Cela permet de se relire facilement et ça aide, du moins en mon cas, à
mémoriser.
C'est une très mauvaise idée de commenter excessivement. Il faut
commenter à point nommé, ce qui est nécessaire.
Si tu parles de http://www.siteduzero.com, même s'il est parfois décrié par les puristes, je trouve qu'il est très didactique, tout est expliqué pas à pas. C'est l'idéal quand on débute, ou pour trouver un exemple simple quand on a comme moi (la vieillesse est un naufrage) des trous de mémoire.
Il n'est pas décrié, il est honnis. Les imprécisions et les mauvaises pratiques en font une source de médiocrité constante/
Je te conseille si tu as le temps, de suivre les cours de PHP proposés sur ce site. C'est progressif, simple, plein d'exemples pour faire des tests, et des QCM permettent à la fin de chaque chapitre de vérifier l'acquisition des connaissances.
Je n'ai jamais compris en quoi les QCM sont une méthode fiable de sondage des connaissances. En plus, ils sont souvent faux sur ce site.
C'est une excellente habitude de commenter au maximum ce qu'on écrit. Cela permet de se relire facilement et ça aide, du moins en mon cas, à mémoriser.
C'est une très mauvaise idée de commenter excessivement. Il faut commenter à point nommé, ce qui est nécessaire.
Il faut traiter $_GET (pour déterminer les ressources consultées) et $_POST (pour déterminer les alterations des ressources). [...] Ce que je trouve dommage c'est que tu traites indistinctement les données d'alteration et de consultation.
tu peux expliciter ce qui te parait manquer ?
ici tu nommes (assez pompeusement) 2 moyens de transmettre des données à un script, merci pour cette grande leçon de sémantique mais quel est l'apport ? dans moulte cas, ce moyen de transmission n'est que pure évidence pragmatique; le traitement des paramètres, de tous les paramètres, reste nécessaire, un nommage branché ne change rien.
Sylvain.
Mickael Wolff a écrit :
Il faut traiter $_GET (pour déterminer les ressources consultées)
et $_POST (pour déterminer les alterations des ressources).
[...]
Ce que je trouve dommage c'est que tu traites indistinctement les
données d'alteration et de consultation.
tu peux expliciter ce qui te parait manquer ?
ici tu nommes (assez pompeusement) 2 moyens de transmettre
des données à un script, merci pour cette grande leçon de
sémantique mais quel est l'apport ? dans moulte cas, ce
moyen de transmission n'est que pure évidence pragmatique;
le traitement des paramètres, de tous les paramètres, reste
nécessaire, un nommage branché ne change rien.
Il faut traiter $_GET (pour déterminer les ressources consultées) et $_POST (pour déterminer les alterations des ressources). [...] Ce que je trouve dommage c'est que tu traites indistinctement les données d'alteration et de consultation.
tu peux expliciter ce qui te parait manquer ?
ici tu nommes (assez pompeusement) 2 moyens de transmettre des données à un script, merci pour cette grande leçon de sémantique mais quel est l'apport ? dans moulte cas, ce moyen de transmission n'est que pure évidence pragmatique; le traitement des paramètres, de tous les paramètres, reste nécessaire, un nommage branché ne change rien.
Sylvain.
Olivier Miakinen
Le 09/04/2009 22:47, Sylvain SF répondait à Mickaël Wolff :
Il faut traiter $_GET (pour déterminer les ressources consultées) et $_POST (pour déterminer les alterations des ressources). [...] Ce que je trouve dommage c'est que tu traites indistinctement les données d'alteration et de consultation.
C'est le printemps : les marronniers sont en fleurs...
tu peux expliciter ce qui te parait manquer ?
ici tu nommes (assez pompeusement) 2 moyens de transmettre des données à un script, merci pour cette grande leçon de sémantique mais quel est l'apport ? dans moult cas, ce moyen de transmission n'est que pure évidence pragmatique; le traitement des paramètres, de tous les paramètres, reste nécessaire, un nommage branché ne change rien.
Je suis du même avis.
Si un programmeur était assez tordu pour demander à recevoir deux données de même nom, l'une dans $_GET et l'autre dans $_POST (ou bien l'une des deux dans $_COOKIE), alors oui, il aurait probablement besoin de distinguer par où lui parvient chacune de ces données. Mais dans le cas d'un programmeur sain d'esprit je ne vois pas ce que ça peut lui apporter de contrôler ça. Il vaut mieux se concentrer sur les valeurs reçues !
Le 09/04/2009 22:47, Sylvain SF répondait à Mickaël Wolff :
Il faut traiter $_GET (pour déterminer les ressources consultées)
et $_POST (pour déterminer les alterations des ressources).
[...]
Ce que je trouve dommage c'est que tu traites indistinctement les
données d'alteration et de consultation.
C'est le printemps : les marronniers sont en fleurs...
tu peux expliciter ce qui te parait manquer ?
ici tu nommes (assez pompeusement) 2 moyens de transmettre
des données à un script, merci pour cette grande leçon de
sémantique mais quel est l'apport ? dans moult cas, ce
moyen de transmission n'est que pure évidence pragmatique;
le traitement des paramètres, de tous les paramètres, reste
nécessaire, un nommage branché ne change rien.
Je suis du même avis.
Si un programmeur était assez tordu pour demander à recevoir deux
données de même nom, l'une dans $_GET et l'autre dans $_POST (ou bien
l'une des deux dans $_COOKIE), alors oui, il aurait probablement besoin
de distinguer par où lui parvient chacune de ces données. Mais dans le
cas d'un programmeur sain d'esprit je ne vois pas ce que ça peut lui
apporter de contrôler ça. Il vaut mieux se concentrer sur les valeurs
reçues !
Le 09/04/2009 22:47, Sylvain SF répondait à Mickaël Wolff :
Il faut traiter $_GET (pour déterminer les ressources consultées) et $_POST (pour déterminer les alterations des ressources). [...] Ce que je trouve dommage c'est que tu traites indistinctement les données d'alteration et de consultation.
C'est le printemps : les marronniers sont en fleurs...
tu peux expliciter ce qui te parait manquer ?
ici tu nommes (assez pompeusement) 2 moyens de transmettre des données à un script, merci pour cette grande leçon de sémantique mais quel est l'apport ? dans moult cas, ce moyen de transmission n'est que pure évidence pragmatique; le traitement des paramètres, de tous les paramètres, reste nécessaire, un nommage branché ne change rien.
Je suis du même avis.
Si un programmeur était assez tordu pour demander à recevoir deux données de même nom, l'une dans $_GET et l'autre dans $_POST (ou bien l'une des deux dans $_COOKIE), alors oui, il aurait probablement besoin de distinguer par où lui parvient chacune de ces données. Mais dans le cas d'un programmeur sain d'esprit je ne vois pas ce que ça peut lui apporter de contrôler ça. Il vaut mieux se concentrer sur les valeurs reçues !
Denis Beauregard
Le 09 Apr 2009 21:25:53 GMT, Olivier Miakinen <om+ écrivait dans fr.comp.lang.php:
Si un programmeur était assez tordu pour demander à recevoir deux données de même nom, l'une dans $_GET et l'autre dans $_POST (ou bien l'une des deux dans $_COOKIE), alors oui, il aurait probablement besoin de distinguer par où lui parvient chacune de ces données. Mais dans le cas d'un programmeur sain d'esprit je ne vois pas ce que ça peut lui apporter de contrôler ça. Il vaut mieux se concentrer sur les valeurs reçues !
Pourquoi pas les 3 en parallèle ? get, post et cookie (il y en a un 4e ?).
Ceci dit, quand je développe, j'aime bien voir les noms des variables dans l'URL, histoire de ne pas avoir à cliquer 2 fois quand je rafraichis une page (avec POST, de mémoire). Donc, cela a du sens de développer avec une méthode, puis d'utiliser l'autre méthode (sans que les noms soient dans l'URL), histoire d'avoir un historique sans les détails des transactions par exemple quand c'est sensible. On pourrait même utiliser des cookies pour avoir une sorte de machine à états durant le développement.
Denis
Le 09 Apr 2009 21:25:53 GMT, Olivier Miakinen <om+news@miakinen.net>
écrivait dans fr.comp.lang.php:
Si un programmeur était assez tordu pour demander à recevoir deux
données de même nom, l'une dans $_GET et l'autre dans $_POST (ou bien
l'une des deux dans $_COOKIE), alors oui, il aurait probablement besoin
de distinguer par où lui parvient chacune de ces données. Mais dans le
cas d'un programmeur sain d'esprit je ne vois pas ce que ça peut lui
apporter de contrôler ça. Il vaut mieux se concentrer sur les valeurs
reçues !
Pourquoi pas les 3 en parallèle ? get, post et cookie (il y en a un
4e ?).
Ceci dit, quand je développe, j'aime bien voir les noms des variables
dans l'URL, histoire de ne pas avoir à cliquer 2 fois quand je
rafraichis une page (avec POST, de mémoire). Donc, cela a du sens
de développer avec une méthode, puis d'utiliser l'autre méthode (sans
que les noms soient dans l'URL), histoire d'avoir un historique sans
les détails des transactions par exemple quand c'est sensible. On
pourrait même utiliser des cookies pour avoir une sorte de machine
à états durant le développement.
Le 09 Apr 2009 21:25:53 GMT, Olivier Miakinen <om+ écrivait dans fr.comp.lang.php:
Si un programmeur était assez tordu pour demander à recevoir deux données de même nom, l'une dans $_GET et l'autre dans $_POST (ou bien l'une des deux dans $_COOKIE), alors oui, il aurait probablement besoin de distinguer par où lui parvient chacune de ces données. Mais dans le cas d'un programmeur sain d'esprit je ne vois pas ce que ça peut lui apporter de contrôler ça. Il vaut mieux se concentrer sur les valeurs reçues !
Pourquoi pas les 3 en parallèle ? get, post et cookie (il y en a un 4e ?).
Ceci dit, quand je développe, j'aime bien voir les noms des variables dans l'URL, histoire de ne pas avoir à cliquer 2 fois quand je rafraichis une page (avec POST, de mémoire). Donc, cela a du sens de développer avec une méthode, puis d'utiliser l'autre méthode (sans que les noms soient dans l'URL), histoire d'avoir un historique sans les détails des transactions par exemple quand c'est sensible. On pourrait même utiliser des cookies pour avoir une sorte de machine à états durant le développement.
Denis
Yannick
Mickael Wolff a écrit :
C'est une excellente habitude de commenter au maximum ce qu'on écrit. Cela permet de se relire facilement et ça aide, du moins en mon cas, à mémoriser.
C'est une très mauvaise idée de commenter excessivement. Il faut commenter à point nommé, ce qui est nécessaire.
Bonsoir,
Ce qui est important c'est de savoir ce qui se passe à tel ou tel moment dans le script. En conséquence un pro n'a pas besoin de commentaires car il sait mais un amateur en a besoin pour repérer rapidement ses commandes et les actions qu'elles sont sensées faire. Un programme bien documenté et bien commenté est réutilisable par une autre personne. Un programme non commenté EST illisible donc mieux vaut trop que pas assez.
Si je m'en sort c'est bien parce que mon code, bien que pas génial pour les puristes, est commenté en abondance. Certes il y a beaucoup à dire sur le travail que j'ai fait mais pour un programmeur dilettant je crois que j'ai le droit d'être fier car j'ai été très largement largué techniquement alors que je programmais en basic puis en DbaseII en auto-formé.
Amitiés
-- Yannick VOYEAUD
Mickael Wolff a écrit :
C'est une excellente habitude de commenter au maximum ce qu'on écrit.
Cela permet de se relire facilement et ça aide, du moins en mon cas, à
mémoriser.
C'est une très mauvaise idée de commenter excessivement. Il faut
commenter à point nommé, ce qui est nécessaire.
Bonsoir,
Ce qui est important c'est de savoir ce qui se passe à tel ou tel moment
dans le script.
En conséquence un pro n'a pas besoin de commentaires car il sait mais un
amateur en a besoin pour repérer rapidement ses commandes et les actions
qu'elles sont sensées faire.
Un programme bien documenté et bien commenté est réutilisable par une
autre personne. Un programme non commenté EST illisible donc mieux vaut
trop que pas assez.
Si je m'en sort c'est bien parce que mon code, bien que pas génial pour
les puristes, est commenté en abondance.
Certes il y a beaucoup à dire sur le travail que j'ai fait mais pour un
programmeur dilettant je crois que j'ai le droit d'être fier car j'ai
été très largement largué techniquement alors que je programmais en
basic puis en DbaseII en auto-formé.
C'est une excellente habitude de commenter au maximum ce qu'on écrit. Cela permet de se relire facilement et ça aide, du moins en mon cas, à mémoriser.
C'est une très mauvaise idée de commenter excessivement. Il faut commenter à point nommé, ce qui est nécessaire.
Bonsoir,
Ce qui est important c'est de savoir ce qui se passe à tel ou tel moment dans le script. En conséquence un pro n'a pas besoin de commentaires car il sait mais un amateur en a besoin pour repérer rapidement ses commandes et les actions qu'elles sont sensées faire. Un programme bien documenté et bien commenté est réutilisable par une autre personne. Un programme non commenté EST illisible donc mieux vaut trop que pas assez.
Si je m'en sort c'est bien parce que mon code, bien que pas génial pour les puristes, est commenté en abondance. Certes il y a beaucoup à dire sur le travail que j'ai fait mais pour un programmeur dilettant je crois que j'ai le droit d'être fier car j'ai été très largement largué techniquement alors que je programmais en basic puis en DbaseII en auto-formé.
Amitiés
-- Yannick VOYEAUD
Mickael Wolff
Sylvain SF wrote:
tu peux expliciter ce qui te parait manquer ?
Ben la distinction entre les méthodes. Utiliser $_REQUEST revient à reproduire le comportement stupide de register_global, qui a entra^iné tant de désillusions en compromettant la sécurité des données en raison d'une erreur grave de conception.
ici tu nommes (assez pompeusement)
Désolé, quand ça ménerve je ne me retiens plus :-/
2 moyens de transmettre des données à un script, merci pour cette grande leçon de sémantique mais quel est l'apport ? dans moulte cas, ce moyen de transmission n'est que pure évidence pragmatique; le traitement des paramètres, de tous les paramètres, reste nécessaire, un nommage branché ne change rien.
Je pense que par nommage branché tu désigne la distinction des données soumises en $_POST ou en $_GET.
Je considère ceci comme fondamental. Les utilisateurs avancé de la liste savent que de nombreuses applications voyaient leur comportement détourné en raison du manque de discernement au niveau du tra^itement des données soumises par le navigateur. Par exemple OsCommerce, Wordpress, Dotclear, etc. C'est pourquoi je considère inconcevable qu'on puisse conseiller l'usage de $_REQUEST à un débutant. D'ailleurs, j'espère que $_REQUEST dispara^itra un jour !
Ben la distinction entre les méthodes. Utiliser $_REQUEST revient à
reproduire le comportement stupide de register_global, qui a entra^iné
tant de désillusions en compromettant la sécurité des données en raison
d'une erreur grave de conception.
ici tu nommes (assez pompeusement)
Désolé, quand ça ménerve je ne me retiens plus :-/
2 moyens de transmettre
des données à un script, merci pour cette grande leçon de
sémantique mais quel est l'apport ? dans moulte cas, ce
moyen de transmission n'est que pure évidence pragmatique;
le traitement des paramètres, de tous les paramètres, reste
nécessaire, un nommage branché ne change rien.
Je pense que par nommage branché tu désigne la distinction des
données soumises en $_POST ou en $_GET.
Je considère ceci comme fondamental. Les utilisateurs avancé de la
liste savent que de nombreuses applications voyaient leur comportement
détourné en raison du manque de discernement au niveau du tra^itement
des données soumises par le navigateur. Par exemple OsCommerce,
Wordpress, Dotclear, etc. C'est pourquoi je considère inconcevable qu'on
puisse conseiller l'usage de $_REQUEST à un débutant. D'ailleurs,
j'espère que $_REQUEST dispara^itra un jour !
Ben la distinction entre les méthodes. Utiliser $_REQUEST revient à reproduire le comportement stupide de register_global, qui a entra^iné tant de désillusions en compromettant la sécurité des données en raison d'une erreur grave de conception.
ici tu nommes (assez pompeusement)
Désolé, quand ça ménerve je ne me retiens plus :-/
2 moyens de transmettre des données à un script, merci pour cette grande leçon de sémantique mais quel est l'apport ? dans moulte cas, ce moyen de transmission n'est que pure évidence pragmatique; le traitement des paramètres, de tous les paramètres, reste nécessaire, un nommage branché ne change rien.
Je pense que par nommage branché tu désigne la distinction des données soumises en $_POST ou en $_GET.
Je considère ceci comme fondamental. Les utilisateurs avancé de la liste savent que de nombreuses applications voyaient leur comportement détourné en raison du manque de discernement au niveau du tra^itement des données soumises par le navigateur. Par exemple OsCommerce, Wordpress, Dotclear, etc. C'est pourquoi je considère inconcevable qu'on puisse conseiller l'usage de $_REQUEST à un débutant. D'ailleurs, j'espère que $_REQUEST dispara^itra un jour !
Si un programmeur était assez tordu pour demander à recevoir deux données de même nom, l'une dans $_GET et l'autre dans $_POST (ou bien l'une des deux dans $_COOKIE), alors oui, il aurait probablement besoin de distinguer par où lui parvient chacune de ces données. Mais dans le cas d'un programmeur sain d'esprit je ne vois pas ce que ça peut lui apporter de contrôler ça. Il vaut mieux se concentrer sur les valeurs reçues !
Imaginons que nous ayons le formulaire suivant dans notre application :
if(isset($_POST['action'])) { $action = $_POST['action'] ; if($action === 'news.delete') { // on traite la suppression de la news } }
?>
Si on avais utiliser $_REQUEST, que les données soient soumises en GET ou en POST n'a pas d'importance. Dans ce cas là, un attaquant pourrait transmettre un lien forgé à une victime utilisatrice du site :
<http://example.com/?action=news.delete&idB>
Ce lien peut ^etre explicite (dans un courriel par exemple), ou caché (et chargé automatiquement) dans une page HTML visitée par l'utilisateur alors qu'il est connecté à l'application compromise. On peut cacheer dans une balise img, stype, script, etc. Bien s^ur, le HTML peut ^etre caché dans le courriel...
Moralité, ce n'est pas parce que le programmeur tordu du site a décidé d'utiliser un nom commun entre les paramètres HTTP (COOKIE compris) qu'il faut distinguer POST et GET, mais parce qu'un attaquant peut ^etre tordu et profiter de la na"iveté de chacun pour nuir.
Je vous conseille à tous la lecture du très bon « Sécurité PHP 5 et MySQL » qui détaille ce genre de trous de sécurité auquelles on ne peut que difficilement imaginer. A moins d'^etre tordu ;)
Si un programmeur était assez tordu pour demander à recevoir deux
données de même nom, l'une dans $_GET et l'autre dans $_POST (ou bien
l'une des deux dans $_COOKIE), alors oui, il aurait probablement besoin
de distinguer par où lui parvient chacune de ces données. Mais dans le
cas d'un programmeur sain d'esprit je ne vois pas ce que ça peut lui
apporter de contrôler ça. Il vaut mieux se concentrer sur les valeurs
reçues !
Imaginons que nous ayons le formulaire suivant dans notre application :
if(isset($_POST['action']))
{
$action = $_POST['action'] ;
if($action === 'news.delete')
{
// on traite la suppression de la news
}
}
?>
Si on avais utiliser $_REQUEST, que les données soient soumises en
GET ou en POST n'a pas d'importance. Dans ce cas là, un attaquant
pourrait transmettre un lien forgé à une victime utilisatrice du site :
<http://example.com/?action=news.delete&idB>
Ce lien peut ^etre explicite (dans un courriel par exemple), ou caché
(et chargé automatiquement) dans une page HTML visitée par l'utilisateur
alors qu'il est connecté à l'application compromise. On peut cacheer
dans une balise img, stype, script, etc. Bien s^ur, le HTML peut ^etre
caché dans le courriel...
Moralité, ce n'est pas parce que le programmeur tordu du site a
décidé d'utiliser un nom commun entre les paramètres HTTP (COOKIE
compris) qu'il faut distinguer POST et GET, mais parce qu'un attaquant
peut ^etre tordu et profiter de la na"iveté de chacun pour nuir.
Je vous conseille à tous la lecture du très bon « Sécurité PHP 5 et
MySQL » qui détaille ce genre de trous de sécurité auquelles on ne peut
que difficilement imaginer. A moins d'^etre tordu ;)
Si un programmeur était assez tordu pour demander à recevoir deux données de même nom, l'une dans $_GET et l'autre dans $_POST (ou bien l'une des deux dans $_COOKIE), alors oui, il aurait probablement besoin de distinguer par où lui parvient chacune de ces données. Mais dans le cas d'un programmeur sain d'esprit je ne vois pas ce que ça peut lui apporter de contrôler ça. Il vaut mieux se concentrer sur les valeurs reçues !
Imaginons que nous ayons le formulaire suivant dans notre application :
if(isset($_POST['action'])) { $action = $_POST['action'] ; if($action === 'news.delete') { // on traite la suppression de la news } }
?>
Si on avais utiliser $_REQUEST, que les données soient soumises en GET ou en POST n'a pas d'importance. Dans ce cas là, un attaquant pourrait transmettre un lien forgé à une victime utilisatrice du site :
<http://example.com/?action=news.delete&idB>
Ce lien peut ^etre explicite (dans un courriel par exemple), ou caché (et chargé automatiquement) dans une page HTML visitée par l'utilisateur alors qu'il est connecté à l'application compromise. On peut cacheer dans une balise img, stype, script, etc. Bien s^ur, le HTML peut ^etre caché dans le courriel...
Moralité, ce n'est pas parce que le programmeur tordu du site a décidé d'utiliser un nom commun entre les paramètres HTTP (COOKIE compris) qu'il faut distinguer POST et GET, mais parce qu'un attaquant peut ^etre tordu et profiter de la na"iveté de chacun pour nuir.
Je vous conseille à tous la lecture du très bon « Sécurité PHP 5 et MySQL » qui détaille ce genre de trous de sécurité auquelles on ne peut que difficilement imaginer. A moins d'^etre tordu ;)
