Reprise du message précédent :

Si le code php génère un truc statique il faut se demander si on a fait le bon choix
L'autre exemple se rapproche de cette appellation fourre tout de dhtml.
 
Rien de bien pas logique dans ça
 
Quand je dis entre 2 appels, c'est tout confondu, même entre 2 visiteurs, header envoyés, vérification de droits d'accès... Même si ça change pas au final entre 2 accès, il se passe d'autres choses Contrairement à un truc qui est pas généré dynamiquement ou modifié côté client.
 

Question bonne pratique ou pas :
 
les __autoload(), ca vaux le coup ou pas?
 
Est ce que ca fou pas la merde dans certain cas?
Est ce que au bout d'un moment ca n'enleve pas de clareté au code au lieu d'un bon vieu require?
 
bref je vais tester, mais je suis pas convaincu

Ca fout pas la merde si c'est bien géré
 
PAr contre question clarté, en effet faut savoir se limiter à là où c'est vraiment nécessaire. D'autant que c'est pas le plus économique en ressources non plus.
 
Mon avis c'est que c'est une possibilité assez intéressante que t'offres php. Comme pour tout à utiliser quand c'est nécessaire. En gros si t'es capable de trouver le bon fichier à inclure dans le autoload, tu devrais pouvoir faire la même chose dans un factory Après ça dépend du type de codage de ton appli

Il est plus intéressant de se servir des autres méthodes magiques AMHA

Je l'avais même pas vu ce topic

 
Y'a 10x mieux qu'__autoload, c'est spl_autoload_register. Qui permet entre autre d'utiliser une méthode d'instance comme fonction de chargement. On peux ainsi instancier un loader, le configurer et tout (genre pour définir des chemins où chercher des classes), et après l'enregistrer comme autoload

oulalal ca m'a l'air bien compliqué tout ca aux vues de la doc et des exemples, mais je vais tenter de persévérer ^^

J'ai laissé un commentaire dans la doc de spl_autoload_register pour expliquer ce qu'on peut faire Sinon ça change pas grand chose à __autoload, genre :

class ClassLoader {
 
  private $chemins;
 
  public function __construct($chemins)
  {
      $this->chemins = $chemins;
  }
 
  public function load($className)
  {
     $fileName = str_replace('_', DIRECTORY_SEPARATOR, $className) . '.php';
     foreach($this->chemins as $chemin)
     {
        if(is_readable($chemin . $fileName)) {
          require $chemin . $fileName;
          break;
        }
      }
   }
}

Et après :

$loader = new ClassLoader(array(
  'C:\www\', 'C:\php\lib\myFramework\', 'C:\autreDossier\'));
 
spl_autoload_register(array($loader, 'load'));

Et voilà

Sinon, si ca peut interesser...
 
Une classe Entity ( inspiree par celle du bouquin "best practices PHP5" ) qui se sert de __call() pour gerer des accesseurs automatiquement:
 

<?php
 
# Entity.class.php
# ----------------
 
class EntityException extends Exception {};
 
/*
*   Provides automatic accessors like getMyparam() or setNicevalue('foo');
*/
abstract class Entity
{
  protected function set($prop, $val)
  {
    $this->$prop = $val;
    return true;
  }  
  protected function get($prop)
  {
    return $this->$prop;
  }  
  public function __call($method, $params)
  {
    $type = substr($method, 0, 3);
    $prop = strtolower(substr($method, 3));
    $paramCount = count($params);    
    if (property_exists($this, $prop)) {
      switch ($type) {
      case 'set':
        $nb = 'exactly 1';
        if ($paramCount === 1) return $this->set($prop, $params[0]);
        break;
      case 'get':
        $nb = 'no';
        if ($paramCount === 0) return $this->get($prop);
        break;
      default:  
        throw new EntityException("Unknown method: $method" );
      }
      throw new EntityException("Invalid args count $method() takes $nb argument." );
    } else {
      throw new EntityException("Unknown property: $prop, $type() failed." );
    }    
  }
}
?>

 
Et ca s'utilise comme ca:
 

<?php
 
class Foo extends Entity {
  var $bar;
  var $baz;
}
 
$foo = new Foo();
 
$foo->setBar('toto');
 
try {
 
  $foo->setQuux('aha');
 
}
catch (EntityException $e)
{
  echo $e->getMessage();
}
?>

PDT, le plug-in Eclipse pour PHP est vraiment super pratique (facile à installer, Windows, linux, Mac ?), mais forcément, pas super simple à prendre en main, et il faut prévoir de la RAM

yop yop,  j'aurais quelques pitites questions sans doute naïves
 
1. Est-ce mal d'utiliser des fonctions "imbriquées" :

 
2. Programmer en Objet "consomme"-t-il plus de mémoire parce qu'il faut garder tout l'objet en mémoire même si on n'utilise pas toutes ces méthodes (je ne sais pas si ça change quelque chose en fait )
 
3. Y a-t-il une limite raisonnable de constantes et de variables de session à avoir.
 
 
   
 
 

1) non
2) oui, ne seraisse que la persistance des données (par exemple, avec des fonctions, si tu n'as plus besoin de l'age du capitaine, tu peux faire un "unset" sur la variable qui contient cette info, avec un objet, tant que t'as besoin du nom du capitaine, t'es obligé de te trainer son age, son identifiant, peut être même son salaire, s'il est marié et etc du moins tant que l'objet existe)
3) j'aurais tendance à dire oui : si t'as des milliers de variables dans ta session ou des milliers de constantes déclaré alors t'en as beaucoup trop. En pratique, t'auras jamais des milliers de constantes à moins d'avoir mal organiser ton code (toutes les constantes déclaré au même endroit même si une page n'est susceptible d'en utiliser que deux) quand aux sessions, si tu te contentes de n'y mettre que le nécessaire, alors tu n'atteindras jamais les milliers de valeurs sauf sur de très gros sites. Mais bon, pour les sessions, rechercher toutes les données peut prendre plus de temps que de les charger à chaque page par le biais de la session et il y a peu de chance que tu satures le serveur à cause de ces données là.
En bref, pour le moment ne te préoccupe pas de ça tant que tu ne t'amuses pas à y mettre des éléments inutile.

Allez, un ptit topo rapide pour utiliser les prepared statements avec mysqli.
 
Problématique:
 
On cherche a sécuriser les appels a notre base de données, l'écriture mysql_real_escape_string ou intval devient vite imbittable.
De plus, lors d'appels répétés d'une meme requete avec des parametres changeants, on perd un temps fou.
 
Avantages des P.S.:
 
Plus de real_escape_string, plus de intval qui trainent. On définit une seule fois pour la requete, les types des champs passés en parametres, on leur attache des variables, et on exécute.
 
Implé:

<?php
 
$db = new MySqli($host, $login, $pass, $base);
 
$stmt = $db->prepare('INSERT INTO table (champ1, champ2, champ3) VALUES (?,?,?);');
 
# On veut par exemple champ1 en INT, champ2 et champ3 en VARCHAR
# Les valeurs qu'on veut passer a la requete, sont dans un tableau tablo[].
 
$stmt->bind_param('iss', $tablo[0], $tablo[1], $tablo[2]);
 
$stmt->execute();
 
?>

 
Pour les differents types de donnees, voir la doc: http://fr.php.net/manual/fr/functi [...] -param.php
 
Autre cas, imaginons qu'on veuille faire une moulinette qui lit un fichier CSV pour mettre les valeurs en base.
 

<?php
 
$db = new MySqli($host, $login, $pass, $base);
 
$stmt = $db->prepare('INSERT INTO table (champ1, champ2, champ3) VALUES (?,?,?);');
 
$stmt->bind_param('iss', $data[0], $data[1], $data[2]);
 
$handle = fopen("test.csv", "r" );
while (($data = fgetcsv($handle, 1000, "," )) !== FALSE) {
    $stmt->execute();
}
$stmt->close();
fclose($handle);
$db->close();
?>

 
La seule instruction dans la boucle est le execute(), les parametres de la requete sont attachés aux valeurs du tableau $data.
 
 

Un autre topo rapide sur la facon d'utiliser les include() proprement ( sans faille de sécu ) conjointement avec un url-rewriting de bon aloi.
 
La situation:
 
On a un controlleur général, index.php, qui fait toute une cuisine nécéssaire au fonctionnement de l'appli.
On veut passer en parametre, la page a afficher.
 
Typiquement, sans protection, ca fait une belle faille exploitable par un gamin de 10 ans:
 

<?php
 
# plein de trucs
 
include($_GET['page'].'.php');
 
# encore des trucs
 
?>

 
Deux exploits possibles ( entre autres ), sont index.php?page=./.htaccess%00 ou encore index.php?page=index qui va joliment faire planter php.
 
Pour sécuriser ca, une méthode simple consiste a énumerer les pages valides dans un tableau, et vérifier que le $_GET['page'] corresponde a un element:
 

<?php
  $pages_ok = array('accueil', 'categorie', 'produit');
 
  if (in_array($_GET['page'], $pages_ok)) {
    include $_GET['page'].'.php';
  } else {
    header ('HTTP/1.1 404 Not Found');
    die();
  }
?>

 
Pour redonner une bonne tronche a nos url, on pourra utiliser un htaccess similaire a celui ci:
 

Pourquoi préferer mysqli à PDO?
Si je demande c'est que je ne vois aucune raison hein

aucune raison, mysqli et les ps fonctionnent, donc je documente brievement, perso j'utilise pas pdo, je suppose que c'est similaire.
 
Et pourquoi j'utilise mysqli plutot que pdo, ben euh, joker. J'ai découvert les ps avec mysqli, c'est resté, voila tout.

Oki merci beaucoup

Si je me plante pas, mysqli a des perfs légèrement supérieures à PDO

Masklinn > La différence de performance, elle serait pas du niveau de la micro-optimisation?

Alors ça je peux pas te le dire, je me souviens juste avoir vu passer ça sur une paire de blogs

Je ferai des bench dans la journee vu que ca a l'air de vous interesser

T'as les résultats ou ça tourne encore
 

ca a du planter

ah bon ? on reçoit pas une notification pour ça ?
j'y comprends plus rien au jocedoctiforum moi

parce que tu y as déjà compris quelque chose ?
 
(drapal déguisé)

 
 
EUhh mouii mais ca sert a quoi exactement ce bout de code, a prioris ca a un rapport pour gere les exceptions mais je comprends pas trop ?
 
merci

Ca m'a l'air cool
Juste faudrais que je sache ce que ça veut dire  
 
Recherche toujours bouquins (signature)
 
XaT

up ( sondage )
 
Je répondrai aux questions sur Entity demain.
 
Au passage, pourquoi le topic de dé-sticky-ise quand je l'edite ?

Rapide topo sur : %B %d, %Y, %I:%M:%S %p
 
Pour par exemple 12/24H etc ?
 
XaT

Bon, avec un peu de retard je reponds aux questions sur Entity.
 
@krifur: Non, ca n'a pas de rapport avec les exceptions. Enfin, la classe leve des exceptions oui, mais seulement parce que c'est une facon propre de remonter les erreurs.
 
@XaT: A quoi qu'ça sert, j'explique.
 
Quand tu travailles avec des objets, il est de bon ton de réduire la portée de tes variables de classe.
 
Genre:
 

<?php
  class Vehicule
  {
    public $modele;
    public $marque;
  }
?>

 
C'est pas bien de faire ca. Pourquoi ?
 
La réponse courte: ca viole le principe d'encapsulation.
La réponse longue: Quand tu utilises un objet, tu ne dois pas avoir a savoir comment il fonctionne ( principe de boite noire ). Tu as une interface pour acceder aux données ( les accesseurs ), peu importe de ton coté si les données sont stockées dans des variables, dans les cases d'un tableau ou autre. Si un jour le développeur de la classe que tu utilises change sa maniere de stocker les données, tu l'auras dans le cul, a moins que tu passes par les accesseurs prévus a cet effet.
 
Les accesseurs, c'est betement ( je simplifie ) un couple de méthodes par variable de classe:
 
getLaVariable() et setLaVariable();
 
du coup, la classe vehicule de d'taleur, elle devient ca:
 
 

<?php
  class Vehicule
  {
    private $modele;
    private $marque;
 
    public function getModele()
    {
      return $this->modele;
    }
    
    public function setModele($modele)
    {
      $this->modele = $modele;
    }
 
    public function getMarque()
    {
      return $this->marque;
    }
 
    public function setMarque($marque)
    {
        $this->marque = $marque;
    }
  }
?>

 
Le truc c'est que c'est relou a ecrire, ces foutus accesseurs. Quand t'as 10 variables de classe, t'as 20 accesseurs...
 
Donc on s'arrange pour déléguer la gestion des accesseurs a une autre classe, par heritage.
 
L'heritage, en tres gros, c'est dire qu'une classe dérive d'une autre, en quelque sorte qu'elle est une version spécialisée d'une autre classe.
 
Du coup la classe 'A' qui herite de la classe 'B' peut utiliser les methodes publiques et protégées de 'B' comme si elles lui appartenaient.
 
notre classe Vehicule devient ca:
 
 

<?php
  class Vehicule extends Entity
  {
    protected $modele;
    protected $marque;
  }
?>

 
Un mécanisme spécial codé dans Entity lui permet d' "attraper" les appels de methode qui commencent par "get" ou "set". On émule en quelque sorte la présence d'accesseurs pour toutes nos variables.
 
Comme Vehicule hérite d'Entity, vehicule herite aussi de ce comportement.
 
Le passage de "private" a "protected" est nécéssaire pour que les methodes de Entity puissent acceder aux variables de Vehicule.
 
L'avantage, c'est de d'automatiser la creation des accesseurs pour tes classes. Apres, tu peux faire sans, mais perso, eviter de taper des centaines de lignes de code, j'approuve

Menage fait.
 
Masklinn, je me suis permis d'effacer ta reponse a NazzTazz sur Entity, je te laisse en refaire une argumentee qui servira aux lecteurs de cette FAQ, si tu t'en sens l'envie.

Bon, conformément aux résultats du sondage, le topic a été élargi a un blabla@php.
 
Ca evitera au modalfachal d'avoir a faire le menage toutes les semaines, et ca permettra aux gens de discuter plus librement /obviousproof.

cool  

XaT

On a pas déjà blabla@web pour se foutre de la gueule de php?

cay nul.. ya déjà blabla@web qui suffit..
 
en venant sur ce topic j'esperais y trouver que de bonnes pratiques avancées de PHP niveau GURU.. pas pleins de nioubs (dont je fait parti) qui  poluent 90% des messages en demandant toujours la meme chose..
 
une sorte de bible de PHP quoi
 
domage

pit-etre mettre ce topic en lien ?
 
http://forum.hardware.fr/hfr/Progr [...] 1273_1.htm

je suis aps hyper fan de celui-ci, perso.

pit-etre mais il a des liens vers au moins un topic dont tu es fan

 
Donc en gros il faut avoir d'un coté les fichiers avec le mysql et le php et d'un autre l'affichage en HTML et CSS?