Reprise du message précédent :
pour l'instant, fuck le MVC, j'ai 200 lignes de PHP, ça serait déjà bien qu'elles fuient pas trop avant de les complexifier.

Si tu veux retourner une chaine, je te suggère le mot-clé "return".

ouais, je viens de regarder c'est pas un scénario catastrophe.  
 
Vous en feriez quoi de l'erreur ? la logger et la bouffer parce qu'elle vient du client ?

Si c'est pas important de ton coté autant la bouffer, oui...mais si t'as moyen de la remonter au client ça peut être intéressant pour lui non?

je renomme Job en JsonJob et je fais renvoyer une chaine à doIt() ?

le client (le XHR) c'est moi qui l'écrit, donc je pense que le log côté serveur c'est pas mal, mais pas plus. C'est pas l'utilisateur qui peut la déclencher.

Si tu veux systématiquement remonter une chaine, autant que ce soit le type de retour de doIt(), oui...enfin c'est comme ça que je le vois.

Si job doit absolument renvoyer du json, oui ,ça me semble une bonne idée( mais je préfère un booléen si tu ne veux pas mettre  d'exception )  
 
Celui qui appelle jsonjob se charge de faire afficher le résultat au bon endroit

pour l'instant, oui. Ok, je vais faire ça.

mais ça me fait un peu chier, j'ai eu beaucoup de sarcasmes sur ma classe Job, mais pas trop d'autres propositions.

si tu parles d'ici  
j'ai pas vu le contenu de la classe job, donc  pour proposer mieux, c'est chaud

Dans ce cas oui, un log et tu bouffes...mais t'as aussi intérêt à pas laisser moisir tes logs dans un coin.

<?php
interface Job {
    /**
     * @abstract
     * @param PDO $db the PDO object
     * @return void
     */
    public function doIt($db);
}

 
j'pensais pas que ce soit utile en fait

je pensais qu'il y avait plus d'autres choses ( genre l'encapsulation en transaction, le log d'erreur, ... )  
 
Vu comme ça , j'ai du mal à en voir une quelconque utilité

'tain c'est relou les langages où ils mettent pas tout côte-à-côte pour apprendre plus vite
 
j'ai une tonne d'onglets ouverts : PHPdoc, PHPunit, PDO etc.

<?php
interface Job {
    /**
     * @abstract
     * @param PDO $db the PDO object
     * @return void
     */
    public function doIt($db);
}

 
Pourquoi tu as pas carrément une implémentation de cette interface du style "SqlJob" qui prend la requête en paramètre? Ca t'éviterait de te faire chier à subclasser pour chaque requête...ou alors c'est volontaire? ça me parait super répétitif pour peu de valeur ajoutée, non?

j'ai des transactions plus longues qu'une seule requête.
et puis il faut bien transformer le résultat entre le SQL et le JSON
 
là j'ai juste donné un exemple booléens, mais j'ai des trucs un poil plus complexes.
 
 
 
sinon, j'ai une question subsidiaire : http://fr.php.net/manual/en/pdostatement.execute.php
imaginons que cette fonction renvoie "false", je diagnostique comment mon erreur ?

Sinon, pour répondre un peu plus à la question d'origine, j'ai des classes perso qui s'utilisent à peu près comme ça, chez moi :

$db = new DbConnector([...]);
 
try{
   $sql = new DbQuery("select ... where truc = :truc" );
   $sql->parameter(':truc', $machin);
   $db->execute($sql);
   $results = $sql->results();
}
catch(...){
[...]
}

avec errorCode et errorInfo? http://fr.php.net/manual/en/pdostatement.errorinfo.php

les années 70 viennent d'appeler, elles veulent leur API. Et leur veste à paillettes aussi, y'a une surboom samedi soir    
 
 
merci

sinon, en plus récent , il y a les exceptions , mais ça n'a pas l'air de t'enchanter

ben moi je les ai activées hein
c'est pas moi qui ai mis un boolean comme type de retour à la fonction.

$dbh = new PDO($sqlite_DSN, '', '',  array(PDO::ATTR_PERSISTENT => true));

et pourquoi ?
 
j'ai des jobs qui font des trucs beaucoup plus complexes (comme retourner une liste d'url d'images )

et surtout vous avez l'air de cracher sur la classe job, donc comment je la vire ?

...mais tes jobs c'est systématiquement définition d'une classe, et execute(new monJob()), et voilà?

oui, c'est con à chier, c'est pour ça que j'aimerai le virer

je la logge avec error_log ?
http://www.php.net/manual/en/function.error-log.php
vous avez mieux ?

Ok, donc perso je séparerais complètement les requêtes/transactions du reste.
Ca me donnerait une interface Transaction avec une signature proche de mon DbQuery() dans l'exemple plus haut, genre ça:

<?php
interface Transaction{
    function execute(DbConnector $db, $format='json');
    function results();
    function jsonResults();//...ou pas, j'aurais tendance à dissocier la transformation json de la transaction, mais bon.
}
?>

Là dessus, tes jobs deviennent de bêtes scripts du style :

session_start();
 
try{
    include "db.php";
    $tr = new loginTransaction($_POST['login']);
    echo $tr->execute($db, 'json');
}
catch(MachintrucException $e){
    echo "{success: false, errors: { reason: '" . $e->getMessage() . "'}}";
    die();
}

*tout* le but du Job c'est justement de pas répéter le session_start(), le try/catch et le echo
 
pour l'instant, la séparation des concerns, c'est pas le sujet, pas quand y'a aussi peu de lignes de code.
 
pour l'instant, je veux éliminer la redondance et gérer centralement les erreurs.

Rien de bien plus joyeux, je me suis fait ma propre classe pour gérer différents niveaux de log, mais c'est tout.

// create an array
$my_array = array ( 'a', 'b', 'c' );
 
// now append a few items
$my_array[] = 'd';
$my_array[] = 'e';
$my_array[] = 'f';
 
 
// print the resulting array to see if it worked
print_r($my_array);
 
results in
 
Array 
( 
    [0] => a 
    [1] => b 
    [2] => c 
    [3] => d 
    [4] => e 
    [5] => f 
)

 
tous les cris les SOS, partent dans le vent ...

skeye > ok, merci.

Bah tu rajoutes une classe JobRunner :

class JobRunner{
 
    function __construct(){
        session_start();
    }
 
    function run(Transaction $tr){
    try{
        return $tr->execute($dbh, 'json');
    }
    catch(MachintrucException $e){
        return "{success: false, errors: { reason: '" . $e->getMessage() . "'}}";
    }
}

...et là ton script est minimaliste :

include "db.php";
 
$job = new JobRunner();
echo $job->run(new loginTransaction($_POST['login']);

class JobRunner{
 
    function __construct(){
        session_start();
    }
 
    function run(Transaction $tr){
    try{
        return $tr->execute($dbh, 'json');
    }
    catch(MachintrucException $e){
        return "{success: false, errors: { reason: '" . $e->getMessage() . "'}}";
    }
}

include "db.php";
 
$job = new JobRunner();
echo $job->run(new loginTransaction($_POST['login']);

c'est quoi la différence fondamentale avec mon code ?

La disparition de ta fonction execute() bizarre, tu ne sous-classes plus juste pour instancier ta classe 1 seule fois et dans le même fichier que tu la définis, tu as des Transaction réutilisables dans d'autres contextes si besoin, et tu as en bonus une séparation des couches raisonnable?

// create an array
$my_array = array ( 'a', 'b', 'c' );
 
// now append a few items
$my_array[] = 'd';
$my_array[] = 'e';
$my_array[] = 'f';
 
 
// print the resulting array to see if it worked
print_r($my_array);
 
results in
 
Array 
( 
    [0] => a 
    [1] => b 
    [2] => c 
    [3] => d 
    [4] => e 
    [5] => f 
)

C'est quoi le pb ?

// create an array
$my_array = array ( 'a', 'b', 'c' );
 
// now append a few items
$my_array[] = 'd';
$my_array[] = 'e';
$my_array[] = 'f';
 
 
// print the resulting array to see if it worked
print_r($my_array);
 
results in
 
Array 
( 
    [0] => a 
    [1] => b 
    [2] => c 
    [3] => d 
    [4] => e 
    [5] => f 
)

dans les airs

http://adodb.sourceforge.net/ oui ? non ?

Connais pas, mais ça t'apporterait quoi?

avoir les scripts DDL et les requêtes SQL dans un langage qui n'est pas spécifique à la base, ce qui me permettrai d'utiliser sqlite en dev et postgres en intégration et prod.