Reprise du message précédent :

Et is_writeable alias de is_writable     C'est cool, ils commencent à aliaser toutes les fautes possibles. Vivement is_fiel

Ca c'est vieux

(c'est pas plutôt pour gagner la retro-compatibilité d'une faute qu'il avaient commise dans l'API avant nan ?)

Bon vous connaissez des IDE PHP qui ne soient pas basés sur Eclipse et qui supportent PHP 5.3 & Co - à part Netbeans ?

Quand phpdesigner était gratuit, je le trouvais pas mal. Je ne l'ai plus testé depuis qu'il est payant, mais il a l'air encore plus complet qu'il ne l'était.

php5 , sans hésiter. A moins que tu ne sois fan d'archéologie.
Principale différence : les classes sont largement mieux géreés dans php5  . Et puis le suport va durer plus longtemsp

Pour le coté nouveauté, tu sais qu'il y a PHP6 sinon ? (juste pour foutre ma merde )

en version stable? c'est tellement nouveau que php.net ne le propose même pas dans les téléchargements dis-donc!

sans blague ?
 
 

C'est même pas une version alpha

Par contre tu peux passer à php 5.3 si tu veux être à la pointe de la technologie (namespaces, fonctions anonymes, plus performant, etc)

C'est assez vieux hein PHP5

Quelqu'un utilise Eclipse PDT ?

J'ai plus de "class" dans mon menu pour créer un nouveau fichier, et ma template de class (via "new PHP file" ) est foireuse et ressemble à ça :

Et je ne trouve aucune variable fonctionnelle pour ajouter le nom du fichier après "class", ${file} ne marchant pas (ça fait une page blanche)

Wat? ça a jamais existé ça dans PDT, non?

Hmm, j'ai peut-être confondu avec Zend Studio pour ça
 
Mais pour la template ? Ya rien de correct qui existe ?

 
J'ai jamais réussi à avoir un résultat raisonnable avec ce machin, j'ai laissé tomber...

Han.

Ok.

Merci.

C'est quand même bien Netbeans, avant de planter au bout d'une heure Je vais tenter PDT 2.2 tiens.

question symfony et jointure :

$q = Doctrine_Query::create()
                ->select('SUM(duree) AS duree')
                ->from('ActivitesAgent aa')
                ->leftJoin('Activite');
 
echo $q->getSqlQuery();

Porquuoi il ne me fait pas la jointure  ?

Dans ma définition de table ActivitesAgent , j'ai bien

$this->hasOne('Activite as activite', array(
             'local' => 'idActivites',
             'foreign' => 'id'));

A noter qu'en spécifiant explicitement la jointure, ça ne change rien ( ->leftJoin('Activite ON Activite.id = ActivitesAgent.idActivite'); )
mais dans ce cas la getDQL m'affiche bien ma jointure ( mais toujours pas getSQLQuery) , et ça me fait toujours un cross join  au lieu d'un left join

$q = Doctrine_Query::create()
                ->select('SUM(duree) AS duree')
                ->from('ActivitesAgent aa')
                ->leftJoin('Activite');
 
echo $q->getSqlQuery();

Parce que ta syntaxe du ->leftJoin() n'est pas bonne, c'est :

$q = Doctrine_Query::create()
                ->select('SUM(duree) AS duree')
                ->from('ActivitesAgent aa')
                ->leftJoin('aa.Activite act');
 
echo $q->getSqlQuery();

pas les yeux en face des trous, comme d'habitude

euh, étant totalement novice en matière d'utilisation d'ORM, je me pose une question en regardant la reqûete créee avec Doctrine de flonuméro : c'est quoi la différence avec une requête en full SQL ?

parce que là, à part le critère de jointure, j'ai du mal à voir la différence (et donc l'intérêt) en fait

Etre sûr qu'on est portable

sur les jointures la syntaxe est assez normalisée, mais sur les limit par exemple , il y a des surprise ,non ?
LA syntaxe utilisée par doctrine est le DQL ( Doctrine Query Language)

Déja ça, c'est chiant à écrire.

Ensuite en utilisant un objet tu peux chaîner, tu peux ajouter/supprimer des directives dans n'importe quel sens, réutiliser facilement, étendre, éviter les fautes de frappe (je connais pas d'éditeur PHP qui parse les strings SQL) etc.

pour le coup des fautes de frappes, c'est raté, puisque flo850 avait justement fait une faute de frappe qui bloquait son code, et son IDE lui disait rien.

Allez ok, éviter des fautes de frappe (même si en l'occurence c'en était pas une, ça avait du sens en dehors du comportement voulu)

non c'est pire, j'avais pas compris comment ça marchait
 
( mais je suis spécialiste des fautes de frappes, j'ai déjà perdu pas mal de temps sur un UDPATE au lieu de UPDATE)

[Dotrine]
j'ai une relation one to many  :  une limite  correspond  à un type d'activité  
 
$typeActivite->getLimite() => j'ai une Doctrine_collection
$limite->getTypeActivite() => j'ai la valeur de l'id  
 
c'est le comportement normal ? ou j'ai raté qq chose ?

salut les nazes
 
DBExecutor.php :

<?php
 include_once 'Job.php';
/**
 * @param Job $job
 * @return void
 */
function execute($job) {
    try{
        include_once 'db.php';
        $job->doIt($dbh);
    } catch (PDOException $e) {
        echo "{success: false, errors: { reason: '" . $e->getMessage() . "'}}";
        die();
    }
}

<?php
include_once 'DBExecutor.php';
class UsernameCommand implements Job {
    public function doIt($pdo) {
        session_start();
        if(isset($_POST['login'])) {
            $stmt = $pdo->prepare("SELECT COUNT(*) FROM user WHERE user_login = ?" );
            if($stmt->execute(array($_POST['login']))){
                if($stmt->fetchColumn() > 0){
                    echo "{success:false}";
                }else{
                    echo "{success:true}";
                }
            }
        }
    }
}
execute(new UsernameCommand());
?>

 
vous avez pas mieux en stock ? je veux que tout le code qui touche à la DB soit wrappé dans le try/catch (et je pense que bientôt il sera wrappé aussi dans une transaction)
 
merci

Un code qui me semble mieux

public function save($con = null)
  {
    try
    {
      $con->beginTransaction();
 
      $this->doSave($con);
 
      $con->commit();
    }
    catch (Exception $e)
    {
      $con->rollBack();
 
      throw $e;
    }
 
    return $this->getObject();
  }

Je trouve l'usage des exceptions plus propre que echo "{success:false}"; dans le modele
et la vue se charge de prendre l'exception et d'en faire ce qu'elle veut

hum, ok.
 
et pour éviter d'avoir à faire une classe par job, y'a pas mieux ?  
Y'a pas de closures en PHP ?

Euh oui, les catch(PDOException) qui font des echo, wtf?
Sinon, j'ai du mal à voir l'intérêt de la fonction execute(), en fait...l'archi est étrange.

Première fois que je vois cette notion de "job" pour wrapper une requête sql bien précise...j'ai l'impression que dans ton truc tu crées de nouvelles classes au lieu d'instancier un Job avec une requête passée en paramètre quelquepart...

J'imagine...

on remarquera que si $_POST est vide, il n'y a ni succès ,ni erreur

j'aurai écrit la même chose dans tous les langages objet qui n'ont pas de closures.

bon, comment j'exécute un bout de code arbitraire dans un bloc try/catch fixe ("template creux" ) ?

moi à la fin je veux renvoyer au client une chaine, comment je fais si echo c'est mal ?

et le code du job, c'est celui d'un junior, pas le mien , je suis justement en train d'essayer de l'industrialiser

en tout cas, c'est pas du mvc, si dans le modèle tu fais un affichage

return $success par exemple
Meme si je préfère le throw Exception en cas d'erreur, et à l'etage d'au dessus

try{
UsernameCommand->doIt();
}catch(InvalidLoginException ile){
echo' false';
}

marrant que tu n'utilise pas ça , c'est comme ça qu'on m'a appris à  faire en java

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.