Reprise du message précédent :
Moi j'ai du SQL dans le métier et je vous merde.
Mais d'un autre coté j'aimerais bien reprendre ce code...

Si ça peut t'aider FlorentG, regarde ActiveRecord [1] utilisé dans rubyonrails pour la base de données (SGBD supportés: mysql, sqlite,sql server,oracle, postgresql...); et accessoirement rubyonrails [2] tout court pour regarder leur modèle MVC qui est vraiment très bon et simple d'emploi.
 
[1] http://ar.rubyonrails.org/
[2] http://rubyonrails.com

Ouais, je connais l'ActiveRecord, il est cité dans le POEAA.  
 
Maintenant est-ce qu'un ActiveRecord peut accéder à plusieurs tables ? Si je crois bien la page sur rubyonrails, ils peuvent utiliser plusieurs tables liées... Ce qui est fort intéressant

sa doutes façons en PHP c'est fondamentalement vicié : c'est fait pour avoir du HTML dans le business

 
Avec un moteur de templates on peut déporter ça proprement...

Oublie pas que PHP est un langage de template à la base...

 
Nan, un langage de script.

Nan, un langage de template

justement, c'est débile de tout vouloir faire avec.

Pour ça que j'utilise des templates XSLT

Bon, et pour gérer plusieurs modes d'identification, vous feriez comment?
 
J'ai plusieurs possibilités de ce coté-là, grâce auxquelles je récupère une valeur (pas forcément la même) qui me permet de construire mon objet 'utilisateur'.
Vous feriez quoi, une classe mère "identification" avec une méthode "checkparameters()" et une méthode "getuser()", puis une classe fille par type d'identification?

Quels sont tes différents types d'identification ?

 
1) Saisie d'un identifiant + mot de passe spécifiques à l'appli.
2) Saisie d'un identifiant + mdp LDAP, le LDAP me donnant l'identifiant du cas 1)
3) Passage par un serveur d'authentification complètement externe, qui me retourne...le login LDAP.

Bon, pour ma couche d'accès à la base, je doute...
Je me demande franchement comment implémenter ça correctement.

tu fais comment pour savoir dans quel cas tu te trouves ? y'a une combobox ?

Fichier de config.

(mais en fait pour mon identification je pense que j'ai un diagramme de classes qui tient la route...plus qu'à l'implémenter.)

donc tu fais une interface AuthenticationSource avec 3 impleméntations concrètes, l'implémentation concrète est choisie par la config.

 
wala. Enfin une classe AuthenticationSource et 3 classes filles, parce-qu'en PHP4 ya pas d'interfaces...
 
Et derrière je vais créer un manager de ldap, un manager de serveur d'auth, et enfin me décider à faire un manager de bdd...

Moi j'utilise des interfaces en PHP4 Enfin ArgoUML me génère ça. donc tu te retrouves avec :

 
 

 
En fait je viens de me rendre compte que je vais devoir réinstaller php sur le serveur de toute manière...donc gogogo php5!

Bonjour à tous,
 
Je choppe la discussion sur le fil. Je suis développeur Web, je développe un CMS/Framework basé sur PEAR (DataObject/Quickform), XML (pour la configuration) et PHP5 (POO, MVC, ...)
 
Ca fait un an que je développe petit à petit mon CMS/Framework et forcement au bout d'un an ça devient très bordélique, ça a beaucoup évolué, j'ai appris beaucoup de concept, découvert d'autres packages PEAR.
 
Bref une version 2 ne serait pas de trop.
Cette version serait déjà découpé en 4 :
- Le CMS proprement dit (pas opensource à priori) donc l'application, le CMS.
- Le Framework : debbugage, gestion des logs, configuration (base de données, environnement), "utilitaires web" (stats, détection robots) etc.
- La Logique métier : Ici normalement, tout est dans des classes DataObject généré (une par table). Ces classes qui héritent donc de PEAR::DB_DataObject peuvent accèder librement à la base de données (MySQL ou autre) et ajouter les méthodes métiers.
- Les packages (des classes) qui peuvent être des packages PEAR, des packages PEAR créés spécifiquement pour cette application.
 
Je m'intéresse au CMS qui utilise le Framework
Voilà ma logique MVC :
Le Controleur devrait être une classe qui controle :
- le CMS (gestion utilisateur, gestion des modèles, lecture de fichier de config XML de description)
- L'intégration de l'exécution dans le framework (conf, logs, debbugage)
- Une couche optionnelle d'authentification (PEAR::Auth)
 
Le modèle contient :
- Le package PEAR::DB_Dataobject, les classes métiers générés et étendues. Plus besoin de singleton, DB_Dataobject s'occupe de tout.
- Ici je pense que tout doit partir d'une superclasse (DataObject pour moi) et être hérité, au besoin il est toujours possible d'accèder directement à la base de données en SQL grâce à PEAR::DB mais là on perd le bénéfice de DB_Dataobject qui permet de se libéré du code SQL et d'être portable (parmis les SGBD supporté par PEAR::DB)
 
La vue contient :
- Les transfertObject : package qui contiennent les données sous forme d'objets appropriés : formulaire (PEAR::HTML_Quickform), Listing (PEAR::Structure_Datagrid ?), Hiérarchie (PEAR::HTML_Treemenu), etc.
- Les renderer : Transforme les TransfertObject en HTML ou autre (XHTML, CSV, code pour template, PDF, etc)
- L'assemblage et le traitement : exemple, pour une sortie HTML : créé la page HTML (intégration de javascript, css), structure le document, ... l'enregistre ou l'envoi au client, etc.
 
Pour tout ceci je me suis aidé de votre topic (yabon) et de :
http://fashion.hosmoz.net/blog/200 [...] pos-de-mvc (gooOOood)
 
Pour développer mon CMS, la partie Model est réduite car mon CMS doit pouvoir en théorie à n'importe quelle logique métier (pas trop complexe quand même) : table liées, hiérarchisées, ordonnées... Il est possible de développé des modules pour des logique métier prédéterminé (actualités , annuaire, catalogue produit ...)
 
La couche Controleur concerne donc le CMS et le Framework proprement dit. Ya donc pas mal à coder (c'est ma version 1 à restructurer).
 
- La couche Vue : Là ce que j'aimerai faire c'est utiliser un max de package PEAR ou développer de nouveaux packages PEAR (j'ai déjà des idées).
 
Merci de vos avis, commentaires, conseils là dessus.
Si du monde est intéressé ou participe à un projet similaire, merci de me contacter à sylvain at com - ocean point com

En tout cas travailler comme ça, ça allège beaucoup mon index.php..

 
...et c'est le seul script du répertoire!

C'est pas trop lourdingue avec tous les transferObject qui utilisent des classes Pear ?
 
Sinon chez moi, c'est des XmlBinder (ou autre), qui, à partir d'un modèle, créer une vue XML. Pis les renderer sont en XSLT pour transformer ça en texte, XHTML, PDF, etc...

Bonjour,  
j'ai une application 3-tiers ( jsp, servlets, beans) codée en java, je veux integrer xml/xsl à cette application pour qu'elle puisse fonctionner sur plusieurs terminaux pc, pda, téléphones, ... mais je ne sais pas à quel niveau je vais pouvoir utiliser le xml puis le xsl qui va le transformer, ni comment les créer.  
si tu peut m'aider FlorentG ça serait sympa.  

Intérêt des interfaces dans un langage à typage dynamique

ben c'est propre
 tu declares que ce tu peux faire avec et puis basta

Tu définis des protocoles et tu passes par le duck typing, l'interface devient un peu redondante vu qu'elle est totalement inutile

tout de suite les gros mots

 
Enfin bon, toujours est-il que les interfaces peuvent peut être avoir un ou deux usages dans les langages à typage dynamique, mais c'est franchement rare

définir les contrats ?

 
Définir un protocole a le même résultat, avec des couches en moins

Si t'es un bourrin, tu fais comme moi, et tu te contente de faire un contenu XHTML... Les mobiles WAP 2.0 gèrent bien l'XHTML, et même les CSS (mon motorola v500 et le Sharp de mon frangin utilisent la CSS définie pour le media handheld).

En fait, c'est dans mon diagramme que j'utilise des interfaces. Pour être strict au point de vue design : utilisation de classes et d'interfaces quand il le faut. Après c'est le générateur de code PHP à partir de l'UML qui me fait sa tambouille...

Dire ce que les classes correspondantes à cette interface sont censé avoir comme fonctions et/ou variables.
Une aide mémoire évolué en quelque sorte.

bis repetita: définir un protocole dans la doc sans s'emmerder à coder ça en dur donne strictement la même chose avec des couches en moins
 
(zêtes gentils mais je sais ce que sont les interfaces et comprend à quoi elles servent dans un langage à typage statique, je ne leur vois simplement aucune utilité dans un langage à typage dynamique, surtout faiblement typé comme PHP)

à faire du joli code.

Non
 
(au contraire même, puisqu'on doit caster - ne serait-ce qu'implicitement - notre objet de type A dans le type virtuel que génère notre interface B)

Avec la description dans la doc, tu ne peux pas t'assurer que le programmeur qui passe derriére a bien tout fait comme il faut. Avec une interface, le compilo gueulera même si on utilise pas toutes les fonctions devant exister dans la classe. Du moins normalement, il gueule. (ma derniére utilisation d'une interface, c'était il y a un an)

hein?

Bordel de bite à cul, on parle pas de Java là, on parle de langages à typage dynamique, interprétés, le compilo ne fait pas de vérifications de types c'est tout juste si il fait une vérif de syntaxe