Reprise du message précédent :

avant l'upload le fichier n'est pas sur le serveur, le php s'exécute sur le serveur.

 
Ce que je voulais dire c'est avant qu'il le foute dans le répertoire d'upload, avant il le met dans un dossier temporaire. Mais remarque c'est con car le problème est le même du coup

quelle que soit la méthode que tu trouves, je vois pas ce qui empêche de l'appliquer avant de faire le move_uploaded_file, de toute manière.

 
Bah c'était bien mon propos, c'est juste que je ne trouve pas de méthode pour vérifier le vrai type mime du fichier en fait
 
Ou alors faudrait voir si le fichier est ouvrable, et si y'a des balises de type php ou n'importe quel autre script

non, c'est la merde, en gros il faut parser le fichier côté serveur, et faire gaffe au padding en fin de fichier en plus.
 
Dans la mesure du possible, sers les fichiers uploadés depuis un autre domaine que tes pages, au moins tu pètes le Same Origin.

 
Mouarf  
 
Pas con l'idée de mettre ça sur un autre domaine Tiens d'ailleurs, ça fonctionne si c'est un sous-domaine ?

oui, ça le sort du domaine.

 
Détail padding et same-origin ? je connais pas ce genre de hack
 

http://en.wikipedia.org/wiki/Same_origin_policy
en fait il y a plusieurs problème, l'un d'entre eux est que je peux mettre du flash dans un fichier jpeg, l'uploader sur un serveur, puis faire venir un utilisateur du serveur sur une page qui référence le flash. de cette façon, dans le flash je peux lire les cookies de l'utilisateur pour le site.
 
il y a d'autres feintes que je maitrise pas trop en mettant le flash derrière une vraie image jpeg dans le même fichier je crois.

Avec l'extension fileinfo, y'a une fonction qui regarde dans le fichier pour sniffer le type réel. Ça ne garantit pas une sécurité à 100%, mais dans la plupart des cas ça fonctionne pas mal

 
Ah ? Merci je vais aller voir là dedans

<?php
 
abstract class Foo{
}
 
abstract class Bar{
    abstract function dawa(Foo $f);
}
 
class Fuu extends Foo{
    function hello(){
        echo 'hello', PHP_EOL;
    }
}
 
class Baz extends Bar{
    function dawa(Fuu $f){
        $f->hello();
    }
}
 
 
$f = new Fuu;
$b = new Baz;
$b->dawa($f);

 
On est censé déclarer ça comment alors?

les params de l'extended doivent être du même type que ceux existants dans l'abstract ?

oui...mais c'est crétin, en l'occurrence. J'ai des couples de classes, l'une étendant Foo, l'autre Bar, et je peux pas dire dans la déclaration de Bar que la fonction dawa prend en paramètre l'instance d'une classe qui étend Foo.

Ou alors j'ouvre dans la classe fille à tous les Foo, mais ça n'a pas de sens.

 
Si Baz ne peut pas prendre tout les types qu'accepte Bar, alors une instance de Baz ne peut pas être utilisée partout ou une instance de Bar peut être utilisée, donc Baz n'est pas un sous-type de Bar
 
(aka: "les types de retours sont covariants, les types de paramètres contravariants" )
 

Foo <>Fuu , donc tu fais du polymorphisme, aps de l'héritage  
et php ne supporte pas le polymorphisme

<?php
 
abstract class Foo{
}
 
abstract class Bar{
    abstract function dawa(Foo $f);
}
 
class Fuu extends Foo{
    function hello(){
        echo 'hello', PHP_EOL;
    }
}
 
class Baz extends Bar{
    function dawa(Fuu $f){
        $f->hello();
    }
}
 
 
$f = new Fuu;
$b = new Baz;
$b->dawa($f);

On déclare pas, le type-hinting en PHP c'est du flan en barres de 15.

Je crois que tu va chercher la cohérence un peu loin

<?php
 
abstract class Foo{
}
 
abstract class Bar{
    abstract function dawa(Foo $f);
}
 
class Fuu extends Foo{
    function hello(){
        echo 'hello', PHP_EOL;
    }
}
 
class Baz extends Bar{
    function dawa(Fuu $f){
        $f->hello();
    }
}
 
 
$f = new Fuu;
$b = new Baz;
$b->dawa($f);

c'est de la covariance de types d'entrée que tu veux faire, et ça on peut pas. Eiffel en fait un peu, mais y'a des cas où ça se passe mal.

Mais ya vraiment pas de solution pour faire un truc clair de ce style?
Ca va finir en abstract function dawa($f); et function dawa(Fuu $f), c'est nul.

 
Ce que tu veux faire n'est pas type-safe.

Je sais. Il n'empêche que c'est quand même quelque chose qu'intuitivement on voudrait pouvoir faire dans certains cas.
Autant avec php ça m'étonne pas vraiment que ce soit pas possible, autant je pensais que d'autres langages permettraient de le faire...

http://en.wikipedia.org/wiki/Lisko [...] _principle

C'est toi qui m'a envoyé un mail avec un oiseau ?  

What ?

Si ça vient d'un funkybearz je n'en ai jamais vu d'autre, mais je ne me rappelle pas t'avoir mailé, et je ne me rappelle pas avoir envoyé un oiseau à quelqu'un de toute ma vie

Ça vient d'un mec, qui, après fouille sur Facebook viens de Colombe aussi. Coïncidence ? I think not

 
Il s'appelle Max ? Normalement y'a aucune chance de me trouver sur Facebook mais bon, on peut passer en MP si tu veux vérifier

lol ça ira. Mais bizarre ce truc

vos gueules, ya des mp pour ça.

J'comprend pas ce que ça veut dire, c'est juste du type-hinting avec polymorphisme qu'il veut faire, et C++ le fait aussi par ex non ? pas Java ?
 
Sachant qu'avec PHP on peut même pas passer null à foo(Bar $arg), je pencherais plus pour un simple cas non prévu... mais j'ai sûrement zappé un truc

oui, en C++ ça serait vu comme du polymorphisme, mais c'est pas ce que skeye voulait faire je pense.
 
il a une interface Imprimante, une interface Document. Concrètement, son ImprimanteHP ne sait écrire que dans des DocumentHP (et elle rejette les DocumentEpson) et il aurait voulu exprimer ça dans ses types statiques.
 
En C++ ou en java, ce genre de truc se résout en réalité avec des CRTP (qui vont être long comme le bras, et au final ça marche pas. Ceux qui ont essayé comprendront pourquoi).

Dac, je vais juste retenir que c'est plus compliqué qu'il n'y paraît

oui, parce que si t'es une Imprimante et que tu déclares savoir imprimer sur des Document. On s'attend à pouvoir te passer n'importe quoi comme document (principe de Liskov) pour que tu imprimes dessus.  
Si t'es spécialisé, il faut alors t'annoncer comme spécialisé et là concrètement, l'écriture des types est moins simple.

Ah effectivement, ça casse le polymorphisme pour la classe Bar en fait, voilà ce que j'avais zappé

Bonjour, je debute dans le php et le html et j'ai un petit souçis.
 
Je voudrait faire une page index avec un header, un menu a gauche, un menu a droite, un fotter et au milieu de tout celà, le corp, là ou tout s'affichera quand je cliquerai sur un menu etc.
 
Pour celà j'ai voulu faire la methode pratique, à savoir, un fichier .php index, un php menu de gauche, un php menu de droite, un php  header, un php footer et enfin, un .php pour le corp. Et donc dans le code de l'index j'ai:
 

 
Seulement voilà, je n'arrive pas a ce que celà se presente comme je le voudrait, l'header se met bien tout en haut de la page, mais tout le reste est collé les uns aux autres, comment faire pour que chaques menu se mettent a leur palce demandés et le footer bien en bas ?
 
Merci de m'aider.
 
ps: je travail avec un fichier css, si vous avez une solution par rapport à ça.

Ton problème est un problème de html/css, pas de php. Pas de mystère, il va falloir apprendre CSS si tu veux arriver à quelque chose.

C'est donc au niveau du fichier css que je dois faire la mise en page ?

hep les jeunes, y'a un framework petit, simple, et packagé dans pear pour faire un service REST ?
Y'a un micro framework dans les exemples de ext-js, mais j'ai peur de tomber sur un bug de sécu dans le parser ou un truc du genre.

hep, j'ai un petit pb :  
dans db.php :

$database = new PDO($dsn, 'lol', 'lol', array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));
error_log($sqlite_DSN . '  after  ' . $dsn . " - " . print_r($database, true));
if ($create_database && $sqlite_DSN == $dsn) {
    error_log("creating base in " . $sqlite_file);
    $database->exec(file_get_contents('schema.sqlite.sql'));
}

 
dans DBExecutor.php :

function fetchJson(Job $job) {
    try {
        include_once 'db.php';
        $result = json_encode($job->doIt($database));
        $database = null;
        return $result;
    } catch (PDOException $e) {
        error_log('exception ' . $e->getMessage());
        return json_encode(ko_answer($e->getMessage()));
    }
    die();
}

 
et en gros quand $result = json_encode($job->doIt($database)); s'exécute, $database est null.
 
Vous avez une idée de pourquoi ?
 
D'autre part, il semble que par certains chemins de code (appelé depuis d'autres fichiers PHP),  $database n'est pas null.
 
une idée du pb ?

$database = new PDO($dsn, 'lol', 'lol', array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));
error_log($sqlite_DSN . '  after  ' . $dsn . " - " . print_r($database, true));
if ($create_database && $sqlite_DSN == $dsn) {
    error_log("creating base in " . $sqlite_file);
    $database->exec(file_get_contents('schema.sqlite.sql'));
}

function fetchJson(Job $job) {
    try {
        include_once 'db.php';
        $result = json_encode($job->doIt($database));
        $database = null;
        return $result;
    } catch (PDOException $e) {
        error_log('exception ' . $e->getMessage());
        return json_encode(ko_answer($e->getMessage()));
    }
    die();
}

db.php avait déjà été appelé plus haut dans le code et $database mis à null? include_once ne fait plus rien dans ce cas, et boum!