Reprise du message précédent :
Sinon ya aussi is_null() et === null qui font pareil

 
Eh mais prends des vacances  

peut-etre que les null remontent avec http://fr3.php.net/manual/fr/funct [...] d-vars.php

Oui, c'est donc la seule solution a priori

Excellent topic

Faire une redirection client avec des headers de requete bien précis (genre post, referer, etc), c'est possible ?

Hein ?

Bah genre, comme un "Location: xxx.htm", sauf qu'en plus on précise les headers de la requete effectuée par le navigateur pour obtenir xxx.htm.

Typiquement, ya je crois un header de requête qui permet de n'obtenir qu'une partie d'un fichier (Range je sais plus quoi, d'ailleurs si vous le retrouviez... )

Et bien moi, je suis dans un script PHP, et je veux rediriger vers tel fichier, à partir de tel octet, en utilisant le header sus-cité.

Toujours pas clair ?

Hein ?

Bon ok, je vais sur developpez.com

Haha Nan mais je pige pas trop ce que tu veux faire exactement, quand tu parles de « n'obtenir qu'une partie du fichier. »

Alors ya deux choses en fait :
- Le problème général : comment fait-on pour faire une redirection avec des headers précis ? (et pas juste une url)
- Mon utilisation particulière : c'est pour faire du streaming "sans script" : je veux obtenir par ex les octets 1500 à 200000 de http://blabla.com/yoyo.mp3. On m'a dit que c'était possible avec certains headers, mais je sais pas lesquels.
 
En fait dans l'idée, ce serait une anim flash qui appelerait http://blabla.com/streaming.php?so [...] ition=1500, qui écrirait dans la BDD (stats), puis redirigerait vers http://blabla.com/yoyo.mp3 avec les headers nécessaire pour ne lire que les octets à partir de la position 1500 (lecture directe)

Coté serveur, tu peux envoyer tout les headers que tu veux avec la fonction header.
 
Tu peux jeter un oeil dans la RFC HTTP/1.1, ya la liste des headers définis par le protocole : http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html (14.16 Content-Range, 14.35 Range entre autres).
 
Mais j'ai l'impression que ce que tu veux faire, c'est plutôt du coté client : c'est lui qui va demander quel range il veut, et je sais pas si tu as moyen de déclencher cette demande coté serveur simplement comme ça. Avec du Javascript tu devrais pouvoir générer une requête HTTP au serveur comme il faut.

Bah ouais c'est ça la question, car qq part le header('Location:') fait ça, mais en moins évolué... Et en JS/Flash c'est tendu, pas le temps et c'est pas moi sur le front...
Il faudrait une sorte de LocationHeaders:

Et si tu fais ça genre pas proprement avec un appel à un script php ?
 
[code]header('Location: range.php?start=X&end=Y');[/quote]
 
Et tous les serveurs HTTP supportent ça ?

C'est ce que je fais actuellement mais le tech serveur du client trouve ça plus galère pour la réplication.

(et accessoirement, j'aurais pas besoin de faire une redirection dans ce cas )

Bonjour, question à la con :
 
J'utilise depuis très très récemment PDO et étant elle même une classe, je me demandais comment l'utiliser dans une de mes classes en fait
 
ps : je ne fais pas de MVC.
 
Imaginons que j'ai une classe news avec une méthode qui récupère toutes les news dans la bdd, comment doit on procéder pour utiliser les méthodes de la classe PDO ?

c'est une question piège?

Non  

require_once('taclassepdo.php');
 
taClassePdo::taMethode();

Pour afficher des articles dans un site / portail codé en PHP, est-ce mieux de procéder via des inclusions (c'est à dire inclure l'article préalablement généré sour la forme d'une page html) ou de faire des appels à la BDD à chaque fois qu'on souhaite afficher l'article ?

Une methode propre:

Article.class.php

<?php
 
class Article
{
    private $title;
    private $author;
    private $contents;
 
    public function __construct() {}
 
    private function loadData($article_id)
    {
        // Ici ton sql sauce select
        // A toi de voir si tu veux passer ta Db en global ou via une registry
    }
 
    public function __call($getMember)
    {
        $member = ucfirst(substr($getMember, 3));
 
        if ((substr($getMember, 0, 3) !== 'get')
        || (!isset($this->$member)))
            throw new Exception('Article::'.$getMember.': methode inconnue', 0, __LINE__, __FILE__);
        return $this->$member || null;
    }
 
    public static function get($article_id)
    {
        $article = new Article();
        $article->loadData($article_id);
 
        return $article;
    }
}

Code de la page qui affiche l'article:

<?php
 
// Je considere ici que la db est connectee, toussa
require 'Article.class.php';
 
$article = Article::get(3);
 
$template->article = $article;

Template qui affiche l'article:

<h2><?php echo htmlspecialchars($article->getName()); ?></h2>
<p><?php echo htmlspecialchars($article->getContents()); ?></p>

( Pas testé et certainement 2-3 erreurs, mais le concept est la )

edit: oops, fixé une grosse connerie

Ta méthode utilise exclusivement la base de données si je te suis bien, c'est cela ?

Pour des articles, genre de contenu qui n'évolue pas forcément "beaucoup", j'utilise des caches. Les articles sont enregistrés en BDD, mais une première lecture le stock en cache pour une durée déterminée.

Le truc c'est "juste" de bien faire attention à séparer les couches : bien séparer l'endroit/le moment ou tu vas chercher/traiter les données (couche métier) et celui où tu les affiches (couche présentation).

Comme ça les deux sont indépendants et
- tu peux sans problème te dire "j'affiche ça avant ça"
- le code est plus lisible (le html avec le html (+php pour les boucles et conditions), le php/mysql avec le php/mysql) (perso quand j'en ai je mets carrément aussi tout mon SQL ensemble dans des fonctions/classes regroupées)
- le code est plus facile à maintenir (t'es plus perdu dans un truc où tout est mélangé)
- au moment de l'affichage, tu peux décider d'afficher sous n'importe quelle forme (HTML structuré comme ci, HTML structuré comme ça, fichier Texte, Excel, PDF ), les données restent les mêmes
- chacun son taf
- etc

Après t'as plein de manières de faire ça, de la simple séparation des languages dans une même même page jusqu'au "MVC" pur et dur (un peu comme le code de NazzTazz)

 
C'est amha la bonne méthode. Un cache géré par le moteur de templates, que tu peux invalider lors de la modification de l'article.

Et y'a pas un système de cache de requêtes dans les sgdb ?

Ya plein d'endroits où mettre des caches, et l'un n'est pas nécessairement plus valide que l'autre

Si mais ça coute toujours un aller-retour query-resultset, un cache local est toujours preferable, d'autant que tu court-circuites tout: requete, retour du resultat, fetch, mise en forme...

edit-- crosspost w/Masklinn, je répondais a Martius

Pour ceux qui écrivent encore du sql a la main, faites un tour sur www.phpdoctrine.org

Il faut s'adapter un peu au début, mais le jeu en vaut la chandelle

Les retours que j'ai sur ce genre d'outils font état de perfs fortement dégradées à moins mettre les mains dans le cambouis, ce qui finalement réduit énormément le gain de temps au développement apporté par l'outil.

+1 avec skeye et en plus la bonne adresse c'est www.phpdoctrine.org

 
Ca dépend ce que t'appelles mettre les mains dans le cambouis:
 

<?php
 
$users = Doctrine_Manager::getTable('User');
$allUsers = $users->findAll();

 
Si tu fais ca, on est d'accord, il va remonter tout et n'importe quoi ( y compris les FK sous forme d'objets hydratés )
 
Si ca, c'est mettre les mains dans le cambouis:

<?php
 
$users = Doctrine_Query::create()
            ->from('User u')
            ->fetchAll(array(), Doctrine::FETCH_ASSOC | Doctrine::HYDRATE_NONE);

 
Alors oui, il faut mettre les mains dans le cambouis
 
@anapajari, oui, j'edite le lien

<?php
 
$users = Doctrine_Query::create()
            ->from('User u')
            ->fetchAll(array(), Doctrine::FETCH_ASSOC | Doctrine::HYDRATE_NONE);

Ca empêche pas de perdre pas mal de perfs par rapport à du SQL brut hein (même si perso je suis partisan des ORM, j'aime pas le SQL)

 
Non mais je parle de choses plus complexes que ça hein...j'ai régulièrement besoin de jointures sur 5/6 tables, voire même de fonctionnalités spécifiques à mon SGBD (oracle, avoir besoin de conneries du genre connect by/start with sur de grosses tables sont courantes sur certaines applis), et très rapidement sur ce genre de problèmes les perfs peuvent s'effondrer de manière catastrophique avec un ORM.

- crosspost avec skeye, je parle a Masklinn

Ouais, forcément, tu perds par rapport a du sql brut, mais ca change la vie de plus faire tes update/insert/select a la paluche quand meme...

Question requetes, apres examen de mon mysql.log, il faut eviter le plus possible d'hydrater les fk ( et malheureusement tu peux pas le definir comme comportement par defaut ) sinon tu plombes vraiment méchamment tes perfs.

Mais perso, entre:

<?php
 
$users = Doctrine_Manager::getTable('User');
$user = new User();
 
$user->username = 'Masklinn';
$user->Friends[] = $users->findByUsername('Nraynaud');
$user->save();

en 100ms

et

<?php
 
$nraynaud = $db->query("SELECT id FROM user WHERE username='Nraynaud' LIMIT 1;" )->fetch_object()->id;
 
$db->query("INSERT INTO user (username) VALUES ('Masklinn');" );
 
$masklinn = $db->insert_id;
 
$db->query("INSERT INTO friendship (owner_id, friend_id) VALUES ($masklinn, $nraynaud);" );

en 20ms

mon choix est vite fait

- pour skeye:

Ouais, ratibus a ce probleme avec propel: 50 requetes generees alors qu'une seule bien sentie suffirait

<?php
 
$users = Doctrine_Manager::getTable('User');
$user = new User();
 
$user->username = 'Masklinn';
$user->Friends[] = $users->findByUsername('Nraynaud');
$user->save();

<?php
 
$nraynaud = $db->query("SELECT id FROM user WHERE username='Nraynaud' LIMIT 1;" )->fetch_object()->id;
 
$db->query("INSERT INTO user (username) VALUES ('Masklinn');" );
 
$masklinn = $db->insert_id;
 
$db->query("INSERT INTO friendship (owner_id, friend_id) VALUES ($masklinn, $nraynaud);" );

 
t'as un rapport x5 pour un truc aussi simple?
C'est encore pire que je pensais.

J'ai pris des timings au pif
 
Tu pingouinotes un peu vite

 
Tu mets des valeurs, t'assumes
Et c'est exactement le genre d'exemple qui montre qu'on perd du temps. une seule requête suffit largement pour faire tout ça.

Vas voir le post de much' sur ses tests de dbs en java, la perte de perfs dues à hibernate (l'ORM java le plus populaire, un peu bloated comme machin mais bon...) est d'un ordre de grandeur