Reprise du message précédent :
Merci Skeye pour ton exemple. Je vais en prendre note.

Ce n'est qu'un exemple, hein, pas une vérité absolue non plus.

Je comprends, il s'agit d'une specialisation de l'exception. Certes on peut definir des "zones" d'exceptions, mais cela ne m'interesse pas.

Ce que je cherche a savoir c'est : est ce que les exceptions on le droit de revenir dans le flux l'application ? Si il existe des limites, les risques d'un code trop "exceptionnel" ou pas assez ...

Une projection pourrait etre d'implementer des mecanismes de rollback pour ces exceptions, si elles entrent dans ce cadre.
Immediatement ca implique des risques potentiels comme un rollback foireux qui endommagerait les donnees, et ou des boucles infinies, ou enfin des cas hors logique non-prevu.
Finalement ca revient a peu pres au dev d'une application complete, c'est peut etre la raison pour laquelle les dev se limite a balancer des messages d'erreurs.

Ok les exceptions sont utilisees pour gerer des problemes exceptionnels qui empeche le bon deroulement de l'app. Mais parmi ces situations, certaines sont clairement recuperable.

Mais c'est pas grave, d'autres dev sur d'autres langages ont deja du faire le tour sur la question.

Maintenant fo de la doc !

C'est un peu pour ça que c'est fait, non?
On attrape l'exception à l'endroit où on sait la traiter pour revenir dans un état stable, ou, si c'est irrécupérable, logger l'erreur/afficher un message cohérent à l'utilisateur...

En supprimant le fameux log d 'erreur de la liste de ce qui se fait pour l instant.

J'ai encore rien trouve qui pourrait revenir a cet etat stable, d'une facon disons organisee.

Prenons l'exemple d'une factory et d'une class DB. Deux classes d'exception sensees pouvoir repondre aux futurs demande de l'application.

Factory plante sur: fichier non existant, fichier illisible, classe non definie, extension incorrecte ....
Db plante sur: connection, erreur db|table non existant, erreur syntaxe

Ok je deroule les extensions pour ces cas irrecuperables. Maintenant j'ai definit des wrapper autour des acces donnees normal.
Ces derniers sont senses etre capable de retrouver leur chemins, du fait qu il accepte beaucoup plus de parametres en entree.

Petit exemple:

Class Sql_Table extends Sql{}
Class Sql_User_Table extends Sql_Table{}

Un probleme arrive sur Sql_User_Table, ce dernier est d'un type recuperable (par exemple un format non supporte pour un parametre) par default. Puis ca remonte jusqu'a resolution du probleme, cas echeant 'prout' error.

Il y a eut un traitement de l'erreur qui s'apparente a celui d'une application : le mecanisme d'heritage et la logique codee en dur.

Niveau limite j'en vois 2 : un code qui throw uniquement pour les irrecuperables, un code qui throw jusqu'a la moindre petite erreur dans un objet non vital a l'execution de l'app.

Ou s'arreter, ou commencer ?

Des exceptions tu en lèves à chaque fois que tu ne sais pas gérer une erreur dans le scope courant.
Si tu sais gérer le problème localement, lever une exception est idiot.
Mais si tu ne sais pas, p-e que l'appelant saura, lui...

Ca n'a pas 100% à voir avec MVC mais je tente quand même.
 
Je découvre les joies du pattern Active Record.
 
1° Comment faire des jointures SQL avec ce pattern ?
On crée toutes les méthodes findByXXX(); avec le SQL dedans et les jointures si besoin => correspond aux queries les plus souvent utilisées
+ une méthode findBySQL($query) => pour les cas plus rares non prévus
 
Vu qu'une classe implémentée en Active Record correspond logiquement à une seule table, c'est bon quand même ?
 
2° J'ai lu à gauche/droite que les méthodes findXXX() ne pouvaient pas être statiques avec PHP, alors qu'elles sont statiques dans d'autres exemples    
 
Quelqu'un a une bonne explication ?
 
kthxbye

J'ai jamais utilisé ce pattern, mais au hasard je dirais que :
 
1) On peut considérer qu'une jointure est l'équivalent d'une vue dans la base, auquel cas tu crées un objet correspondant à la vue, et plus à une table.
 
2) Je ne vois pas pourquoi elles ne pourraient pas être statiques en php si elles peuvent l'être dans d'autres langages...faut voir où tu l'as lu et les explications qu'ils donnent.

Bon après avoir lu un peu partout qu'Active Record n'était pas top pour travailler avec plusieurs tables en même temps, je vais plutôt utiliser Data Mapper
 
Pour les méthodes statiques:

Bref ca dépend de ce qu'on veut faire.

moué, à tester...

Bon apparement même avec un Data Mapper la question des jointures persiste.
 
http://www.sitepoint.com/forums/sh [...] p?t=185352
 
Situation avec une table groups, une table users, un user appartenant à un seul groupe pour simplifier:
Supposons que je veux retrouver le nom du groupe de l'utilisateur

 
ou  
 

???
 
Tout ca pour une seule jointure...
 
Je me prend trop la tête et c'est un faux problème en fait ?

CA depend si c bien fait.

J'vois pas ce que

$userMapper = new UserMapper($db);
$groupName = $userMapper->findById('3')->getGroupName();

a de compliqué
 
Sauf la partie instanciation de userMapper à partir d'une db explicite, qui n'a rien à foutre là (la config de la DB devrait être centralisée et toutes les classes devraient taper dedans automagiquement pour pouvoir écrire un truc du style

$group = $User::find('3')->getGroupName();

$userMapper = new UserMapper($db);
$groupName = $userMapper->findById('3')->getGroupName();

$group = $User::find('3')->getGroupName();

L'intérêt de passer $db en paramètre c'est de pouvoir plus tard faire des requêtes sur des db différentes.
 
C'est pas moi qui le dit, c'est mon bouquin de patterns php et plusieurs forums

 
C'est complètement con comme idée
 
Et en bonus, ça rend le code plus long, moins clair, plus crade et plus fragile

Mauvais bouquin, changer bouquin

huhu.

Il peut donner le nom du bouquin ?

Phpdoctrine est très interessant comme ORM.. vous devriez tester.
 
Chez moi, ca donne ca (en fait, y'a de multiple façon de le faire)

Je l'attendais celle là
 

Oui, il peut.
 
php|architect’s Guide to PHP Design Patterns
A Practical Approach to Design Patterns for the PHP 4 and PHP 5 Developer

Ouais DataMapper est un overkill sauf si vraiment tu px pas faire autrement.
Un truc essentiel ds les DP, c 'est l economie.

Bon, mon framework commence à rosker des ours. Je vois plein d'idée que j'ai implémenté depuis 6 mois fleurir dans des frameworks de renommées mondiales. J'vais essayer de poster quelques détails ici au courant de la semaine.

Et magne

Et tu le publis quand ton framework ?

Ch'ais pas, pour l'instant c'est closed-source et ça risque de durer...

Ca sert a quoi alors ?

Hein ?

Bah developper tout un Framework et dire que tu es content que les grand Framework réputé partent sur les meme idées que toi je ne vois pas trop l'interet si c'est pour le garder pour soi et quelques sites que tu feras.  
Apres ce n'est que mon avis, ce n'est pas une attaque

Ben c'est pour la frime

lol
Mais ca reste un gros boulot pour pas grand chose, apres t'as l'air d'etre passionné par cette technologique donc c cool.
Mais pourquoi t'as pas envie de le publier ?

Tout simple pasqu'il n'a pas envie de le publier maintenant. Mais plus tard oui.

Bon ok, je sors =>

C'est mon chef qui veut pas
 
Mais un framework, c'est la première chose qu'il faut faire lorsqu'on veut pouvoir faire plein de sites facilement et tout. Alors y'a évidemment plein de solution existantes, mais quand on a des contraintes spéciales c'est moins top.

Je sais pas si ça peut en aider certain mais : http://www.symfony-project.com/boo [...] ony-s-Code
C'est la page d'explication du MVC de symfony (un framework de ouf ).
Je trouve qu'ils présentent bien la chose

Ouais, c'est bien d'avoir expliqué la séparation de manière incrémentale

J'aime bien la partie "Constants" vers la fin :

 

 
Je préfère ne pas aller lire le reste.

Et bien ne lis pas

Je trouve que Symfony est un Framework PHP5 vraiment abouti. La documentation est très complète et se lit facilement. Symfony est difficile à prendre en main au départ du fait de l'utilisation intensive de fichiers de configuration en YAML, mais ça en vaut la peine vu le temps qu'on gagne par la suite.

J'ai testé un peu Symfony, pas eu beaucoup de temps pour approfondir mais y a effectivement de bonnes idées.

J'ai vu aussi que le zend framework allait bientôt sortir, quelqu'un s'est fait un peu la main dessus ?
(pour rester dans le MVC j'ai vu qu'il y a une classe controller et une classe view notamment) à titre perso je me suis à peine penché dessus encore.

Plop.
Perso j'utilise CodeIgniter grâce auquel je me suis lancé dans le PHP orienté objet et le MVC et ce framework rosque des nounours : léger, abordable, adaptable, bref le bien quoi
Après je ne dis pas que symfony est moins bien mais je trouve que symfony est seulement utilisable sur les gros gros projets "corporate"

PunkRod > J'ai comencé à l'utiliser mais pas pour la partie affichage. Il y a de bon trucs dedans mais il y a encore des manques dans les parties que j'ai utilisé. D'un autre côté, c'est pas encore sortie en version stable alors ca peu changer.