Ses derniers messages sur les forums
(La Globule) J'ai déjà fait, et plus d'une fois. C'est très pratique.
(Snooze59) Quelle expression cocasse, « bonnes habitudes en PHP » ;)
Venant d'ADA, dans un mois tu auras commencé à chercher autre chose ;)
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
C'est une solution parmi d'autres. Il y a peut être plus élégant, plus puissant, plus performant, etc. C'est une question de goût, et surtout de besoin.
Il n'y a pas une seule solution. Le problème auquel tu veux répondre peut être traité de différentes manières, selon les ressources dont tu disposes, et des fonctionnalités que tu dois fournir. Ainsi que les performances attendues, la maintenabilité, l'évolutivité.
Ce qu'il faut que tu gardes à l'esprit, c'est que pour mieux régner, il faut diviser. Donc essaye de séparer au maximum les concepts, quitte à devoir dénormaliser par la suite.
Il faut aussi que tu acquiert le vocabulaire. Par exemple, on ne parle pas de tables liées, mais de jointures ou de relations. Comprendre et maîtriser ces mécanismes te permettrons de facilement modéliser ton application.
Essaye déjà de créer quelque chose de simple, teste, fais valider par les utilisateurs (ou commanditaires), en précisant que c'est un prototype (et précise ces limites, pour éviter d'être noyé dans les demandes de fonctionnalités). Puis rajoute les fonctionnalités progressivement, comme si tu incorporait du sucre à ton blanc d'œuf monté en neige : si tu ajoutes tout d'un coup, ta meringue est râtée. Dans le développement, c'est pareil : quand l'incorporation a échouée, vaut mieux jeter la préparation et recommencer. Ce qui est rarement faisable. Donc vas-y au fur et à mesure.
Ceci dit : c'est un développement professionnel ? Tu es seul à le réalisé ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Je n'ai pas directement testé ton code. Mais chez moi, j'arrive au résultat escompté :
<?php
$cre_sql = 'create table corrupted (id integer not null auto_increment, data char(100), primary key (id))' ;
$selall_sql = 'select * from corrupted' ;
$drop_sql = 'drop table corrupted' ;
$ins_fmt = 'insert into corrupted (data) values (\'%s\')' ;
$upd_fmt = 'update corrupted set data = \'%2$s\' where id = \'%1$s\'' ;
$values = array
( 'Toto' => 'Toto'
, 'Toto & Tata' => 'Toto & Tata'
, 'A' => 'A'
, 'f' => 'f'
, 't' => 't'
, '\' and \'w00t' => '\' and \'w00t'
) ;
$con = new mysqli('localhost', 'test', '', 'test') ;
$con->query($cre_sql) or die($con->error) ;
try
{
foreach(array_keys($values) as $value)
{
$ins_sql = sprintf($ins_fmt, $con->real_escape_string($value)) ;
if(!$con->query($ins_sql))
throw new exception($con->error) ;
}
foreach($con->query($selall_sql)->fetch_all() as $tuple)
{
$old = $tuple[1] ;
$new = html_entity_decode($old) ;
assert('$new == $values[$old]') ;
$tuple[1] = $new ;
$upd_sql = vsprintf($upd_fmt, $tuple) ;
$con->query($upd_sql) ;
}
}
catch(exception $e)
{
$con->query($drop_sql) ;
throw $e ;
}
$con->query($drop_sql) ;
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(fauto) Qu'est-ce qu'un filtre ?
<?php
$resultats = fonction_qui_cherche_les_lignes();
$resultats_filtres = fonction_qui_filtre_les_lignes($results) ;
fonction_qui_filtre_les_lignes faisant le boulot de filtration. C'est à dire qu'il va manipuler le tableau pour qu'il n'y ai pas de doublon. Il va falloir boucler sur les lignes et comparer des valeurs. Avec un peu de réflexion tu peux y arriver.
Ceci dit, la table d'origine a un défaut de conception. Je verrais plutôt quelque chose dans ce goût là :
create table article_keywords
( article_id integer not null
, word varchar(255) not null
, primary key(article_id, word)
, foreign key (article_id) references articles(id)
) ;
create table articles
( id integer not null
, title char(50) not null
, content text
, primary key (id)
) ;
Ainsi, la recherche des articles par mot clé se ferait ainsi :
select a.* from articles as a
join article_keywords as ak
on a.id = ak.article_id
where ak.word = '?' ;
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(dark_nemo) Je crois que tu t'es emmêlé dans ton explication, puisqu'une URL est un lien ;)
(lady_vm) Je vais faire court.
Un disque est un espace de stockage de données.
Ces données sont séquestrées dans des fichiers (ensembles contigus de données ayant un début et une taille).
Les fichiers sont accessible par un chemin dans le système de fichier.
Le serveur web est un serveur de fichier.
Il fournit un arbres d'accès aux fichiers *différent* de l'arbre du système de fichier.
Lorsque tu demandes à ton navigateur d'accéder à un fichier, si celui-ci commence par http, il interroge un serveur Web. Ce serveur web tente de trouver à quoi correspond le fichier demander. Pour ce faire, il regarde sa configuration et le système de fichiers. Puis il tente de servir la ressource qu'il trouve.
Pour un fichier généré via PHP, et en supposant que chaque étape réussie :
- L'internaute demande http://localhost/index.php à son navigateur web
- Le navigateur demande au système quelle machine est localhost.
- le système lui répond 127.0.0.1
- le navigateur toque à la porte 80 de la machine 127.0.0.1
- le serveur lui répond « qu'est-ce donc ? »
- le navigateur demande la ressource /index.php de l'hôte localhost
- le serveur vérifie qu'il sert localhost
- le serveur détermine où sont les fichiers correspondant à l'hôte localhost, et y cherche le fichier demandé
- le serveur prend index.php
- le serveur passe dans le filtre PHP le fichier index.php
- le serveur renvoie le résultat issu du filtre et l'envoie au navigateur
- le navigateur reçoit le ficher et l'interprète
- le navigateur commence à créer un rendu visuel du document HTML
- le navigateur tente de résoudre les ressources externes du document nécessaire au rendu du document (images, CSS, Javascript)
- pour chaque ressource externe au document HTML, le navigateur demande à l'hôte localhost le fichier qui va bien
Ceci implique que les ressources requises par les documents servis via le serveur web doivent être servies par le serveur Web.
Relis plusieurs fois, fait des schémas, réfléchis, et ne reviens pas si tu n'as rien compris du tout :p
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(Rahan) Quand on a une HTTP 500, il faut regarder dans le journal d'erreur du serveur web.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
MVC mériterais un article entier (que j'essaye décrire, mais j'ai peu de temps).
Pour faire court, le M correspond au modèle, qui n'a rien à voir avec la base de données. C'est une erreur commune dans la communauté PHP, où on fait l'amalgame entre le concept de modèle (les règles métiers et les structures de nos objets et de leurs relations) et celui de persistance des données. Parce que finalement, une base de données ne fait qu'assurer la persistance des données.
De toute façon, en Web, le MVC est une chimère. Je considère que c'est une approche à considérer pour tenter de séparer les responsabilités.
Bon, je vais essayer de terminer mon article :D
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Plusieurs remarques pour améliorer ton code.
Je n'aime pas la concaténation.
echo '<p>'.$message_erreur_formulaire.'</p>'."\n";
Je lui préfère ceci, en corrigeant un éventuel problème :
printf("<p>%s</p>\n", htmlspecialchars($message_erreur_formulaire)) ;
$text = trim($text); // delete white spaces after & before text
Pourquoi ? Ça ne sert strictement à rien.
Ensuite tu créés une fonction à la volée. Je ne vois pas bien l'intérêt. Tu devrais plutôt faire cette opération une fois pour toute en début de script, pour corriger le comportement de cette ignominie qu'est magic quotes, avec quelque chose dans ce goût là :
<?php
if(get_magic_quotes_gpc())
foreach(array(&$GLOBAL, &$_POST, &$_GET) as $gpc)
array_walk($gpc, 'stripslashes') ;
Ta Regex est fausse :
<?php
$pattern = "^([a-z0-9_]|\\-|\\.)+@(([a-z0-9_]|\\-)+\\.)+[a-z]{2,7}$";
Il faut lui préférer l'usage de filter_var et associés. Précisons aussi que les fonctions ereg sont lentes, déconseillées, et seront supprimées dans les prochaines versions de PHP.
<?php
$nom = (isset($_POST['nom'])) ? Rec($_POST['nom']) : '';
Pourquoi tant de parenthèses ? Il ne faut en mettre que là où c'est nécessaire. Quel est l'intérêt d'entourer l'expression isset(...) de parenthèses ?
Que veut dire Rec ? Des noms de fonctions courtes peuvent être pratiques. Mais leur usage doit être limité au strict minimum. En règle générale, un nom de fonction doit être explicite pour tout ceux qui devront maintenir ton code. Et pas que toi.
On peut faire les mêmes commentaires sur les parenthèses à propos de :
<?php
if (($nom != '') && ($prenom != '') && ($mail != '') && ($entreprise != '') && ($commentaire != ''))
Un fumet de trou de sécurité que tout bon spameur apprécie avec délectation :
<?php $headers = 'From: '.$nom.' <'.$mail.'>' . "\r\n";
En gros, tu devrais écrire quelque chose comme ça :
<?php $headers = sprintf("From: %s <%s>\r\n", mailescape($nom), mailescape($email)) ;
Avec la fonction mailescape à définir, qui échappe correctement les variables pour éviter le détournement du formulaire.
Pourquoi avoir utilisé nl2br ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(mario23) Commence par ton
orthographe, tu pourras toujours apprendre la programmation quand tu sauras exprimer tes idées en Français *puis* en PHP.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
(ebenezer) En français comme en PHP, sans syntaxe, tu n'obtiens rien de correct.
(dark_nemo) La Globule disait bien que c'était la méthode canonique. Quand à l'usage de la base de données, très franchement, ça dépend de ta logique métier. Sans connaître la nature exacte de son problème, on ne peut que rester aux suppositions : « long et fastidieux » est très relatif. Pour l'utilisateur moyen, remplir un formulaire de contact est déjà trop long et fastidieux.
(ebenezer) Mais au final, c'est quoi ce formulaire méga-long ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Chargement en cours