Reprise du message précédent :

En quoi ton système machin vérifie spécialement l'existence d'une variable

function_exists
method_exists
property_exists
class_exists
isset
...
 
is_array
is_float
...
 
Si avec tout ça t'es pas capable de vérifier l'existance d'un élément alors dit moi ce qu'il te faut.

 
Déjà t'es meilleur que moi ... parce que j'avais même pas compris sa phrase

Rien sauf que ça perd tout l'intéret du concept de template si tu te mets à coller du php partout dans le html
 

Quel système Je disais juste que d'utiliser le concept de template force plus ou moins à inclure des données contenues dans des variables (jusque là on est d'accord ) dont tu peux pas vérifier l'existence (enfin si mais après c'est plus du template) et dont l'existence repose sur le bon déroulement du modèle/controleur
 
Pour être clair, un exemple:

$montexte est inclu sans que l'on soit absoluement sur qu'elle soit définie   Et même si tu me dis que la vue est choisie volontairement en fonction du modèle qui renverra les bonnes données au controleur, c'est quand même un peu à l'aveuglette le truc    
 
C'est juste ça qui me dérange, mais c'est pas bien grave  

Prends moi pour un canard je t'en prie    
 
Je parle dans la vue, si faut caser du code comme ça, il dit qu'il voit pas bien l'intéret de séparer la vue du traitement des données (tout au moins de leur passage à la vue )

Quelle différence avec smarty ?

Smarty ne fait pas de vérification sur la définition ou non d'une variable à ma connaissance.

J'ai pas parlé de smarty Je connais pas ce truc et à la limite je m'en tamponne Y'avait pas de comparaison. Juste une interrogation sur la façon dont gérer un système de template en php pur Soit gérer la vue en php sans moteur de template particulier

Haaaa euké

Tient c'est intéressant, donc c'est bien ce que je dis, on inclu des variables qui pourraient ne pas exister   La seule façon d'être sur qu'elles existent c'est parce qu'on sait qu'on les renvoit au controleur.
 
A moins de rajouter une couche pour vérifier qu'on a toute les variables déclarées dans une vue donnée   Ou de faire un gestionnaire d'erreur maison

Faut le dire si je suis pas clair

Ben c'est ma faute à moi si tu parles d'un systéme de template tellement mal codé qu'il utilise dans tous les sens des noms de variables définis en dur?  
Pour moi un bon systéme de template s'en contre fout des noms de variable. On lui passe la variable qui contient toutes les données et il se démerde avec pour pondre le fichier final.

Perso je trouve que c'est pas à la vue de controler ce qu'elle reçoit ... Mais chaos a raison smarty ne fait aucun controle.  
Remarquons juste que rien n'empeche de le faire soit même dans le template via des conditions en "langage smarty", mais ça devient juste n'importe quoi.

C'est au dev d'avoir un modèle qui chie pas de la merde en bâtons, et d'avoir un contrôleur capable de rattraper le coup au cas où le modèle se prend les pieds dans le tapis. Mais c'est pas à la vue de vérifier ça, la vue théoriquement elle est passive. Elle est soumise. Elle prend ses claques dans les fesses sans râler, sinon coup de tatanne. Non mais.

Euh, non. Dans un langage fortement type, d'accord. Mais dans une merde comme PHP, t'es oblige, pour coder proprement, de rendre ta vue implicitement intelligente.

Je plussoie Chaos Intestinal, et je moinssoie gizmo    
Le controller n'est pas un médiateur, il ne doit pas transmettre les données à la vue. Donc l'histoire du controller qui va faire les verifs et tout ça, je suis moyen d'accord. C'est le model qui doit directement être transmis à la vue.  
 
Et si les attributs de votre Model sont public, que la vue n'utilisent pas d'accesseurs pour récupérer les données, votre vue peut vite partir en couille on est d'accord. Maintenant, quand la vue ne fait que utiliser les accesseurs qui vont bien, bah le model il renvoit pas de la merde.
 
Donc je suis d'accord, la vue est soumise, elle aime le fouet, et elle a pas besoin de vérifier la validité ou l'existence des données, les accesseurs du model sont là pour ça.

Tu veux dire un tableau donc Ou à la limite avec un objet

J'ai un peu de mal à "voir" quel type de pattern concerne le controller.
 
Parmi mes candidats il y a le factory pattern ou le delegation pattern.
 
Des conseils ?

Moi j'ai cinquante douze patterns.
 
Sinon pour le Controller, il est ensuite découpé en Action (Command Pattern)

Factory aussi, cela va de soit

ok
 
J'arrive pas encore à formaliser mais pour l'instant j'obtient ca:
 
- controller = factory(model,view)
- modele = bibliotheque de classe + singleton connect SQL + singleton log instance.
 
Au niveau des exceptions j'ai ciblé les accès données et les requetes user:
 
SQLException extends Exception
InputException extends Exception
FileException extends Exception
 
J'vois pas encore le bout, jreposterais quand ca ira mieux

J'ai dégagé tous mes singletons, j'en ai plus un seul Finalement j'me rend compte qu'il faut effectivement faire attention à ne pas tout singletoniser... Tous mes singletons en fait étaient plus là en tant que "classe d'accès globale" qu'autre chose

Bah j'pensais que le singleton etait pas mal pour les ressources d'accès.
 
Voila le code pompé de OO Php No Starch: (http://objectorientedphp.com)
 

 
 
Il dit que ce wrapper mimique mysql_connect().  
 
Moi j'aurais plutot fait:
 

 
Pareil pour un handle fopen, le singleton me parait pas mal.

static public function getInstance($hostname, $username, $password){
    //instance must be static in order to be referenced here
    if(self::$instance == NULL ){
      self::$instance = new MySQLConnect($hostname, $username, $password);
      return self::$instance;
    }else{
      $msg = "Close the existing instance of the ".
        "MySQLConnect class.";
      throw new MySQLException($msg, self::ONLY_ONE_INSTANCE_ALLOWED);
    }
  }

Mais qu'est-ce que c'est que cette merde

static public function getInstance($hostname, $username, $password){
    
    if(self::$instance == NULL ){
      self::$instance = new MySQLConnect($hostname, $username, $password);
}
      return self::$instance;
  
  }

Super, les connections et les accès fichiers qui ne se ferment jamais jusqu'à ce que le programme se termine, vachement bonne idée tiens

Moi pas comprendre  
 

 
Avoir une connection ouverte toute la duree du script, je ne vois pas pourquoi ca ne serait pas rentable ?
 
Le principe étant de réutiliser la connection ouverte si il y a lieu ... Pourquoi ?
 
Pourquoi ?
 
Pourquoi ?
 

Euh... Une méthode getInstance() avec paramètres ? C'est pour ce genre de bizarrerie que j'ai dégagé les singletons...
 
Je passe à mes Controller, mes Model et View un objet Context qui contient la config, les chemins, la requête, et tout ce qui est connexion etc...

J'ai une question !
 
Le contrôleur appelle le métier et la vue, mais n'a pas rôle de les faire dialoguer, ok.
 
Dans ce cas, la vue doit récupérer les données : comment ?
L'objet métier (par exemple GestionnaireDeForums), après avoir fini son travail :
* créé un objet "entité" (MonForum - donc avec en gros beaucoup de paramètres identifiant, nom, les modos, etc... et des fonctions permettant d'y accèder), la vue devra alors récupérer ces infos, les (dans mon cas) transformer en un fichier XML, puis on passe un coup de XSLT et zou.
 
* retourne directement les données sous forme XML (mais, dans ce cas, il y a déjà une part du travail de la vue, non ?)
 
* Une troisième méthode que je ne pige pas
 
J'ai tendance à pencher pour la première, mais ça risque de faire chargé, non ?

Moi j'aurais stocker toutes les données dans une variable du modele. Puis la vue recupere ces données par une méthode generique => class XML => class RSS extend XML ou class XSLT extend XML => output
 
Puis pour le singleton en connection SQL, toujours pas de réponse, j'ai bon lire plein de code beaucoup de gens utilise le singleton ou un truc equivalent pour verifier que la connection n'est pas déjà ouverte.
 
Bref ...

En effet, pour le SQL je pensais à un singleton, par contre, là seule idée que j'ai pour éviter des "global $sql" systématiques, c'est :
$sql = ${sql::$instance};
 
sinon, il faudrait un objet qui gère les DAOs, mais pareil, il faut le "globaliser"...

Pas de problème niveau heritage.
 
Le singleton te permettra d'eviter d'utiliser les global qui s'initialisent au runtime de ton application.
 
Conclusion: pas de $global mais plutot ObjetTresCouteux::getInstance() juste quand tu en as besoin, la reference elle restera disponible pendant la durée de ton application ( ou bien tant que le garbage collector ne la pas suppr ).  
 
La connection est un exemple parfait d'objet très couteux à passer en singleton quoi qu'on dise. Sans le singleton le background de l'application serait truffé de réference à des objets semi-morts, en attente d'etre collecté.
 
Meme un gamin de 5 ans pourrait faire le choix ici ...

c'est à dire ?

Si tu pars d'un framework encapsulé dans une classe PHPapplication qui s'occupe de tout : accès données, filtrage ...  
Bah tu laisses l'initialisation des accès aux classes parentes, et les classes dérivées hérite des propriétes et méthodes ( donc des accès ).
 
Logiquement une nouvelle application devra posséder un point d'accès sur ton framework ou les objets dont elle à besoin pour s'executer. Par héritage le reste se fait.
 
L'heritage dans ce cas est une solution simple et passe partout, mais il a plus de défauts que de qualité ( je pense au framework sur onlamp qui est une suite de classes derivées, chacunes faisant leur petites fonctions ).
 
D'après tout ce que j'ai pu lire sur OO, aucune règle de design ne favorise l'héritage ( sauf le decorator pattern ).  
 
Puis j'ai qu'une semaine d'expérience en programmation OO, j'ai pas vraiment les compétences pour te répondre  
 
Tu ne trouveras PAS ton bonheur ici , je te conseille de t'orienter sur un bouquin comme "design pattern elements of reusable o-o software".
 
Adieu hfr

Je suis en train de regarder le Zend Framework, ça à l'air plutôt pas mal...
 
Certains d'entre vous l'utilisent ?
 
J'avoue que j'ai toujours des doutes concernant l'utilité d'un framework ... j'ai un peu de mal à cerner ce que ça apporte vraiment ??? (sauf 200 lignes de code pour afficher 1 page )

ne pas réinventer la roue?

Je suis du même avis que toi pour les frameworks tels .net pour php
 
Mais là je dirais qu'il faut tirer intelligement le truc à ton avantage, plutot s'orienter vers un framework d'éxécution qui ne te laisse plus qu'à faire quelques petits fichiers de config pour l'éxécution et à développer la partie métier de ton appli ainsi que les vues, l'éxécution étant au final toujours la même dans les grandes lignes (requête client, controller frontal, choix controlleur, choix modèle, éxécution modèle, choix vue, envoie vue).
 
Je vois l'intéret comme ça, pas à cliquer sur un truc qui te pond du code moisi dans un cadre moisi

Ben disons que quand je vois cet exemple :
 

<?php
// mettre vos constantes ici...
define("WEBAPP_DIR","C:/users/levan/_boulot/eclipse/Tutoriaux" );
define("PHP_INF_DIR",WEBAPP_DIR."/PHP-INF" );
define("ROOT_URL","http://localhost/Tutoriaux" );
define("INCLUDE_PATH_SEPARATOR",";" );
define("ZEND_FRAMEWORK_DIR","C:/phplib/ZendFramework" );
 
set_include_path(
  ".".INCLUDE_PATH_SEPARATOR.
  PHP_INF_DIR.INCLUDE_PATH_SEPARATOR.
  ZEND_FRAMEWORK_DIR.INCLUDE_PATH_SEPARATOR.
  get_include_path()
);
 
require_once 'Zend.php';
 
// Controller init et RewriteRouter
Zend::loadClass('Zend_Controller_Front');
Zend::loadClass('Zend_Controller_RewriteRouter');
 
$controller = Zend_Controller_Front::getInstance();
$router = new Zend_Controller_RewriteRouter();
$router->setRewriteBase('/Tutoriaux/');
$controller->setRouter($router);
$controller->setControllerDirectory('PHP-INF/ctrl');
 
// View init
Zend::loadClass('Zend_View');
$view = new Zend_View;
$view->setScriptPath('PHP-INF/view');
// On enregistre la vue
Zend::register('view', $view);
 
// call dispatcher
$controller->dispatch(); 
?>

<?php
require_once 'Zend/Controller/Action.php';
 
class IndexController extends Zend_Controller_Action {
    
    public function indexAction() {
        // Récupération de la vue créée dans index.php
        $view = Zend::registry('view');
        // On appelle la vue qui devra
        // s'afficher quand cette action est appellée
        echo $view->render('accueil.html');
    }
 
    public function noRouteAction() {
        // Si l'action demandée n'existe pas 
        //(ex : http://localhost/Tutoriaux/index/toto)
        $this->_redirect(ROOT_URL);
    }
}
?>

 
Tout ça pour afficher une simple page (alors oui je sais que ce n'est un exemple, mais ça montre quand même le déroulement pour n'afficher qu'une page) ... je me dis que c'est sacrément "complexe" ...

Chez moi c'est plus simple Et pis attention, le Zend Framework est pour l'instant à l'état de preview...

C'est pour ça qu'il faut étudier le sujet qui est en effet très complexe et voir comment simplifier tout ça. De toutes manières, le développement informatique m'a toujours fait rire dans certains langages: t'as une usine à gaz alors qu'un print("coucou" ) suffirait
 
Mais c'est juste qu'en général y'a plus que ça et qu'au final on est obligé d'abstraire tout même ce qui est simple et ne mériterait pas de l'être sauf que dans un souci d'homogénéisation t'as pas trop le choix
 
C'est l'avantage et l'inconvénient de php: simple pas besoin d'avoir une certification $soft pour développer un truc simple. Mais on tombe dans du développement moisi pensant pouvoir faire bien simplement en faisant du procédural comme à la vieille époque.
 
Php c'est pas du C# et ça le sera jamais c'est pas son esprit Mais certains veulent l'utiliser dans le même esprit parce qu'il commence à pouvoir le permettre, chacun fait son choix
 
 
Pour Zend Studio, on peut se dire que vu que c'est développer par les concepteurs de php, il doit y avoir quand même un minimum de logique et d'intéret. Après c'est l'utilisation de la chose: utiliser un framework pour une page perso parlant de la vie de ton poisson rouge c'est peut être simplement démesuré et inadapté

C'est pour ça que j'ai laisser la structure de mon Framework plutôt libre.
 
A la base, c'est juste les fichiers .html statiques comme ça. Y'a juste un fichier .php avec l'html commun à toutes les pages, et qui reprend la page qu'on veut (donc pas mieux qu'une pseudo-frames améliorées). C'est ce que j'appelle le layout (terme un peu piqué à cakephp).
 
Après s'il faut un peu de PHP, on peut aussi mettre une page .php comme ça normalle, foutre ce qu'on veut dedans à condition que ça génère de l'xhtml. Après le résultat est injecté au layout aussi. Alors évidemment ça permet de faire du moche de chez moche, mais si jamais faut balancer un truc rapidos, hop un script moche et ça fonctionne. Ou s'il faut intégrer un truc genre osCommerce, c'est très pratique.
 
Ensuite, on peut faire un vrai MVC avec Controller, mappage URL <-> Controller, Command pattern, etc...
 
Et enfin j'ai des Controller fournis avec le framework, des modules (genre des trucs à utiliser partout, diaporamas, formulaires de contact), qui peuvent être appellés dans le site.
 
Pour les modules j'me démerder pour faire du MVC propre : interface ou classe abstraite pour les models, actions découpées en command pattern, et view composées d'une classe qui cherche les données + la template PHP. On pourrait même mettre des templates smarty, pas de probs.
 
La structure est conçue pour permettre d'être totalement libre, tout en pouvant bénéficier du framework. Tu veux faire du code moche mais tout de même avoir le confort des pseudos-frames ? Tu peux. Tu veux faire du MVC intégriste ? Tu peux. Tu veux faire des modules MVC réutilisables ? Tu peux. T'as un site à toi, avec tes technologies à toi, mais tu voudrais utiliser un de mes modules ? Tu peux.

C'est sûr que ça demande réflexion. Chaque méthode a ses avantages et ses inconvénients.
 
Par exemple, d'un côté j'aime bien ne rien utiliser du tout (pas de véritable MVC, pas de template ni rien). J'ai mes petites classes perso (galerie, contrôle de formulaire, gestion de news etc...), et je me démerde très bien comme ça. Vu que c'est mon bouzin, je le maitrise, et je code rapidement...
 
Seulement quand je vois parler de Templates (avec Smarty par exemple), de MVC, de framework & co, j'ai l'impression de coder comme un porc (alors que mon code est propre, indenté, documenté, assez robuste je pense ...). Donc il est là le problème.
 
Moi ça ne me gène pas d'avoir des petits morceaux de php partout dans mon html