Reprise du message précédent :

Non le gars il fait du java. Une inner class c'est une classe déclarée dans une autre classe

 
Le but du MVC c'est d'isoler chaque couche, mais ça suppose de savoir définir une interface publique constante pour chaque couche...si tu changes l'interface tu l'as forcément dans l'os...

C'est pas spécifique à rails mais il y a un concept de presenter, implémenté dans ces plugins par exemple :
http://github.com/mhs/caching_presenter/tree/master
http://github.com/nmerouze/action_ [...] ree/master
http://github.com/giraffesoft/acti [...] ree/master (peut réunir plusieurs modèles à la fois)

En gros c'est une classe au dessus du modèle, c'est plus propre que des helpers et ca évite un trop plein de méthodes trop liées aux vues dans le modèle

Ah bah voilà, j'aurais fait pareil

Vous utilisez tous symphony comme framework MVC en PHP ?

Non. On est plus, genre, deux

Mais on gagne contre ZF qui n'a que skeye pour sa défense.

CodeIgniter pour ma part.

symfony depuis plus de 2 ans. Très safisfait (et le framework évolue dans le bon sens).

Moi je suis fou et je fais ma propre tambouille

Je suis sur Zend Framework.
J'ai été séduit par leur paradigme convention de nommage / autoload / abstraction générale et adapteurs

non.

J'ai utilisé ZF une seule fois et encore sur un truc perso jamais terminé...

 
non (code maison)

Zf aussi depuis un peu plus d'un an.

moi je test code igniter en ce moment, et ca semble bien parti

un doute :

j'ai un prix, (1234.45 par exemple),

à l'affichage il sera mis en forme pour avoir quelquechose comme ca :

"1.234,45 €",
ma fonction php qui me fera ma mise en forme sera appelée dans le modele, puis la string transmise a la view ?

ou je transmets à la view mon prix brut, qui sera mis en forme dans ma view ?

j'aurais tendance à penser la 2eme solution, la view met en forme le prix,
mais je me dis aussi qu'il faut peut-etre eviter le code php (appels de fonctions) dans la view ?

oui.
 
 

pourquoi?

Non c'est bien la 2, tu mets tout le code que tu veux dans une vue, du moment que ça s'occupe de l'affichage.

 
ok, bah en fait je me dis que mes vues (j'utilise code igniter) seraient bien avec le moins de php dedans (genre qu'un non-pratiquant de php puisse y toucher), mais bon au pire il touche pas à ca épicétou

ptie question sur me modeles, j'ai une sorte de framework fait maison a forte inspiration de code igniter et donc en gros comme dans CI ilest conseiller de faire une classe Modéle par Table donc je me retrouve avec des trucs comme ca:
 

public function getAllUsers() {
            try {
                $resultats=SPDO::getInstance()->query("select username from users;" );
                $resultats->setFetchMode(PDO::FETCH_OBJ);
                    while( $ligne = $resultats->fetch()) {
                        $data[]=$ligne->username;}
                }
            catch(PDOException $e) { echo $e->getMessage();}
            return  $data;
        }

 
puis  
 
 

public function getAllImg() {
            try {
                $resultats=SPDO::getInstance()->query("select path from pix;" );
                $resultats->setFetchMode(PDO::FETCH_OBJ);
                    while( $ligne = $resultats->fetch()) {
                        $data[]=$ligne->path;}
                }
            catch(PDOException $e) { echo $e->getMessage();}
            //print_r($data);
            return  $data;
        }
            }

 
Donc en fait, j'aimerai bien factoriser tout ca, pour l'instant je cherche autour d'une classe mére par exemple dont chaque classe fille correspondrais a une table sql et avoir dans la classe mére des fonctions genre:
 
SelectAll($table,$option_field,option_limit)(){}
en gros une fontion commune pour rapartrier un select * qui prends en argument la nom de la table, puis peut etre certains champs, un limit...  
 
Mais comme je suis sur de ne pas etre le premier a me poser la question, je pense que ca doit surement deja exister,
 
est ce une sorte d'ORM (je suis en train d'installer Doctrine mais ca m'a tous l'air d'une machine a gaz)?
est ce une mauvaise idéé?
pour implementer un systeme de la sorte des interfaces ou des classes abstraites seraient t-elles les bienvenus?
 
   
 
 

C'est un ORM. Tu ferais mieux d'en utiliser un qui existe déjà.

Oui, en moins bien Non

Disons que toi tu essayes juste de faire les fonctions classiques d'accès/raccourcis à la BDD, de la factorisation de base quoi.
On l'a tous fait je crois, en général ça évolue et ça s'arrête avec une classe "DB" singleton qui comporte des méthodes de raccourcis et se connecte à la première requête.

1 an plus tard tu te diras "tiens ça serait bien que chaque type d'enregistrement soit un objet, comme ça je pourrais y ajouter des méthodes", et là tu voudras faire un ORM, qui sera moins bien que Doctrine qu'est vachement bien.

 
T'aurais pas un exemple histoire de gagner du temps  
je pense capter mais je suis pas trop sur, au lieu d'avoir une fonction selectAll on va dire il vaut mieux avoir une Classe ?
 

Installe Doctrine si tu veux un exemple d'ORM
En gros ça va brancher directement tes classes Model à chaque table de la BDD, et t'auras presque plus de SQL à faire.
Après je sais pas comment ça s'intègre à CI.

Par contre pour rester tes fonctions/méthodes basiques (un peu HS mais bon), il vaudrait mieux que tu fasses des choses qui prennent du SQL en entrée (la requete) et qui diffèrent seulement par le format de sortie ; plutôt que des paramètres spécifiant la table, le limit etc, qui vont vite être trop limités.

genre

class DB
{
  // retourne la première valeur du premier résultat  ( cf PDOStatement::fetchColumn() )
  static public function fetchSingleVal($sql) {} 
  // retourne un tableau avec les premières valeurs de chaque résultat
  static public function fetchVals($sql) {}
  // retourne un tableau avec tous les résultats ( cf PDOStatement::fetchAll() )
  static public function fetchAll($sql) {}
  // retourne le premier résultat ( cf PDOStatement::fetchRow() )
  static public function fetchRow($sql) {}  
  // etc
}

$usernames = DB::fetchVals("SELECT username FROM users" );

$usernames = DB::fetchVals("SELECT username FROM users" );

C'est pas un ORM du tout ça

Je ne l'ai pas prétendu, au contraire

Enfin si, à un moment j'ai dit "oui, c'est un ORM en moins bien", mais c'était juste pour pas te contredire j'édite, j'étais bourré

Donc NON, ce que tu veux faire krifur n'est PAS un ORM

Bah ça pourrait, genre User::selectAll() (ou plus simplement User::all()) qui renvoie une liste User récupérés depuis la db toussa

C'est quand meme pas mal de la masturbation mentale tout ça.
 

n'est-il pas ^^

j'ai toujours eu l'habitude de faire ma tambouille niveau code, et je n'ai jamais eu un besoin en terme d'architecture nécessitant l'emploi de framework déjà tout fait.
ma boite a accueilli il y a peu de temps un nouveau dev qui a fait un truc sympa, il a mais un framework home made, mais résultant de la reprise d'un peu de symphony, et d'un peu de Zend Framework.

J4ai pas regardé de quoi il retournais mais je suis curieux

C'est l'inverse qui se passe en général, c'est quand tu as a des besoins particuliers que tu t'amuses à développer un framework.

Ben c'est pas ce que j'ai dit ?

Non, tu dis "Pas de besoin particulier -> j'utilise mon propre framework"

Moi je dis "Pas de besoin particulier -> j'utilise un framework tout fait déja existant"

Bon, par ailleurs, les frameworks existants (ZF, Symfony) sont assez bien foutus pour s'adapter potentiellement à n'importe quel besoin. Donc dans tous les cas, coder son propre framework c'est mal et ça sert à queud

Tu vois par ex ton nouveau collègue, s'il s'était basé sur symfony j'aurais pu reprendre son code facilement, Ratibus et tous les dev symfony aussi. Mais vu qu'il fait je ne sais quel mélange, c'est plus possible (à moins que ce ne soit un simple symfony avec 2/3 extensions ZF, ou l'inverse).

 
Tu veux dire que florentg et nazztazz ont perdu leur temps ?

Hmm... oui

Enfin c'est pas tant une question de temps que de reprenabilité et de devoir se taper de la maintenance supplémentaire, par ex. Et d'avoir un outil a priori moins bon.
Par contre tu gagnes en temps d'apprentissage... ce que tu perds en temps de dev.

Nan Quand j'ai commencé, ZF n'était même pas encore dans le cerveau d'un de leur dev. Solar était en Alpha, tout comme CakePHP.

Nan et puis bon, si tu fais un bon truc, en surchargeant intelligemment tu peux arriver à un truc assez souple au final
 
j'étais dans le milieu de la web agency, et j'en ai rarement vu utiliser des frameworks tout faits. Même chez publicis NET qui est pourtant une grosse boite ils ont fait leur tambouille

C'est plutôt récent et ça demande un peu d'implication (les framework PHP, contrairement à java ou .net on apprend pas ça à l'école). Et puis les web-agencies c'est pas forcément une référence en matière de dev

Ceci dit on avait vu un mec en entretien qui venait d'une agence qui faisait des sites à la chaine avec symfony.

J'ai un peu de mal à voir l'intérêt de développer son propre framework quand on voit la diversité de l'offre, rien qu'en php

Ca avance toi avec CI ?

 
Ouais, j'ai bien appris grâce à vous, mais là c'est en pause

Si c'est grâce à nous c'est pas bien, si c'est grâce à toi et la doc c'est mieux