Reprise du message précédent :
Jme suis planchié de topic en fait, mais merci
Je vais me pencher sur toussa, ça a l'air bien.

En symfony < 1.2 (et donc propel 1.2) pour les arbres faut utiliser ça : http://www.symfony-project.org/plu [...] viorPlugin
Pour symfony 1.2 (et donc propel 1.3) c'est natif dans propel, tu déclares les infos au niveau du schema
 
Pour les trads :  
sf 1.0 : http://www.symfony-project.org/boo [...] n-and-L10n
sf 1.1 : http://www.symfony-project.org/boo [...] n-and-L10n
sf 1.2 : http://www.symfony-project.org/boo [...] n-and-L10n

Pourquoi pas mal de gens (même ici) conseillent de passer à Doctrine et de lâcher Propel ?

http://trac.symfony-project.org/wi [...] ndDoctrine ?

Ah cool thx.

C'est moitié foireux les NestedSets de Propel ou c'est encore moi qu'aie pas de bol ?

edit : nan faut juste faire hyper gaffe à rentrer des données valides (style clé unique) en BDD, sinon il incrémente quand même le parent sans rajouter le noeud et fait péter le truc.

En meme temps c'est un peu son role de gueuler si tu rentres des données invalides

Sauf qu'il se contente pas de gueuler, mais aussi de quand même casser l'intégrité des données au passage

"Péter le truc" = "Péter la base"

Ca change rien, s'il gueule sans pour autant arréter l'operation y'a un soucis. C'est comme si quand tu voulais déplacer un fichier en utilisation dans windows il te gueulait dessus et corrompait le fichier.

Ben donc on est d'accord nan

Non, je sais pas encore de quoi tu te plains, plains toi donc correctement

Je me plait qu'il a tout pété mon arborescence, tout en me gueulant dessus pour une autre raison
On balaie devant sa porte avant de me repprocher des choses, messieurs Propel et Mysql

En fait :
1) je crée un champ avec un "token" égal à "childdd" (ce champ "token" étant unique, et "childdd" étant déja pris)
2) je lui donne "root" comme parent
3) je sauve()
4) il modifie "root" pour accueillir son nouveau marmot
5) il se rend compte que ce marmot est impropre à la commercialisation
6) il gueule.

résultat :
- "root" est modifié
- le môme n'est pas ajouté
- c'est la merde.

Tables MyISAM?

nan nan Innodb

Alors effectivement plugin de merde, tu devrais ptet aller ouvrir un bug

C'est gênant de faire une boucle dans une vue ?

c'est une question piège?

 
C'est qu'actuellement dans mes vues j'ai tendance à ne faire aucun traitement  

C'est pas vraiùent un traitement, tu traite pas tes données , tu ne fais que les parser pour les afficher.
Donc non je vois pas ce qu'il y a d'anormal .
 

Poste ton code

 
Un simple foreach.

on veut du code mvc quand meme

Pourquoi n'aurait-tu pas le droit à du foreach dans une view S'il faut itérer sur des enregistrements pour les afficher par exemple

 
Moi c'est du 4 couches
 

 
Je posais juste une question

T'as même le droit aux fonctions/méthodes, tant qu'elles font de l'affichage.

Hey,

Théoriquement, le modèle ne doit jamais faire appel activement à l'extérieur si je ne m'abuse.

Seulement voilà je suis sur un e-commerce (multi-shops), et tous les calculs de prix dépendent de l'utilisateur en cours, toutes les insertions dépendent du shop en cours etc...

Autant d'élements qui dépendent de l'extérieur. C'est quoi la bonne pratique pour ce genre de cas ?

Passer les valeurs au modèle d'une façon ou d'une autre, au plus tôt dans la vie du script ?

Les modèles peuvent interagir entre-eux. Tu peux très bien filer une instance d'un modèle "shop" au modèle "produits."

Oui, mais c'est la couche controlleur (c'est à peu près ce que j'entendais par "extérieur" ) qui décide quel est le shop en cours. Donc soit je passe le shop en argument aux modèles à 150 endroits différents, soit une seule fois, je ne sais où au début de l'exec... soit c'est le modèle qui appelle le controlleur quand il veut, tranquillou

Soit j'utilise la super solution qui a fait ses preuves et que vous allez me donner

File le shop en argument ouais. Pour éviter les 150 endroits différents, fait-toi un contrôleur abstrait par exemple qui fait ça.

Mouais Pas compris l'histoire du contrôleur abstrait par contre

Toute ta couche contrôleur a besoin de configurer un modèle avec le nom du shop.
 
Genre t'as des contrôleurs :

• ajout-produit
• lister-produits
• calculer-prix

Tous on besoin du modèle produits, configurés avec le nom du shop. Alors tu peux très bien te faire une classe mère qui initialise le modèle tout seul :

abstract class ProduitController extends Controller
{
 
  protected $produitModel;
 
  public function init()
  {
     $this->produitModel = new produit_model($_GET['shop']);
  }
 
}

 
Et après tes autres contrôleurs en héritent :

class AjoutProduitController extends ProduitController
{
   
   public function init()
   {
      parent::init();
      // autres init ici
   }
 
    public function httpPost()
    {
       $this->produitModel->insert($_POST);
    }
}

Dac, donc ça se rapproche plus de la solution "une seule fois, je ne sais où au début de l'exec"
 
Sachant qu'il n'y a pas que le modèle produit qui soit attaché au shop, mais aussi une vingtaine d'autres.

Issue du bouquin: Apress, Holub on Patterns

Je code en Ruby on Rails et j'aurais tendance à être d'accord avec lui. Combien de fois mes pages ont pété parce que j'ai changé un truc dans le model et oublié de modifier la view. J'écris des tests automatisés avec Test::Unit, mais c'est pénible, il faut aussi les maintenir, et je trouve que c'est plus une rustine qu'autre chose.
 
MVC c'est cool, mais pas la silver bullet.    
 
EDIT: une fois j'avais discuté de la possibilité de mettre du code initialement dans une view dans un model, comme ça les choses pètent à un seul endroit, mais on m'a répondu 'hmm, view code that creeps into business logic is bad blabla' alors j'avais pas plus approfondit mais je sens que que je vais m'y repencher.
 
PS: désolé j'ai pas lu l'intégralité du topic.

Je bosse sur une grosse appli qui utilise MVC et Smarty, alors oui, c'est contraignant de devoir faire des modifs sur 2 voire 3 couches à la fois, mais c'est vachement plus propre et compréhensible.

Exemple ?

Un truc bête. J'ai un objet User qui auparavant avait les attributs: firstname, middlename, surname. Je me suis rendu compte que quasiment personne ne tapait middlename ni surname. Alors j'ai remplacé ces 3 attributs par un seul: name.
 
Manque de bol l'objet User est utilisé dans une chiée de views, donc je dois faire les modifications à la main pour virer les anciens attributs et mettre name à la place. Les test automatisés m'ont bien aidé, mais c'est chiant à taper quand même.
 
Alors que l'idée d'Holub, c'est de créer une méthode: User#print_name qui encapsule prénom, nom, etc. Bien évidemment il faut se forcer à créer une API durable, et pas changer sur un coup de tête: print_name en render_name, parce que là ça sert à rien.
 
Et sinon ceux qui ont codé le passage à l'euro ça s'est bien passé? Ca me fait penser que mon support des devises est un peu crade aussi, c'est un mélange de code placé dans le model (et oui les prix sont stockés en centimes), views et helper.
 
Sinon j'ai aussi eu à ajouter (ça ça va encore), modifier (aïe) des attributs pour des paiments Paypal, parce que c'est un sacré foutoir. Le plus drôle c'est quand je me suis rendu compte que le champs mc_gross (ou je sais plus lequel) était le montant payé par un client diminué de la commission paypal qui était stockée dans un autre champs avec un nom à dormir debout. Là aussi recoder les views pour corriger les erreurs de calcul ça a été vachement drôle. Alors que si dès le départ ça se passait dans le model et avec une méthode amount avec tout ce qui va avec j'aurais pas eu à recoder.
 
Un bel exemple qu'il donne:

Ca va dans le sens où le model doit avoir du code qui sera injecté dans les views, ou

 
Mais c'est sûr que le MVC c'est mieux que d'y aller freestyle avec du code dans tous les sens, mais je pense que le model doit contenir du code qui initialement serait dans la view. Enfin y'a des trucs à adapter.
 
 
EDIT: bon je vais pas poster tout le livre mais merde il était sur ma TOREAD list depuis un moment et c'est seulement aujourd'hui que je vois ça:

Il expose exactement mot pour mot, les problèmes que j'ai rencontré.
 
 
EDIT: assez radical quand même là, voir trollesque dans ce topic, mais bon il n'a pas totalement tord non plus.

M'enfin je vais pas réécrire entièrement mes applis RoR  

Alors là comme ça à première vue, je vois pas en quoi c'est intrinsèquement de la faute du MVC.

La plupart de ces exemples semblent être des problèmes de factorisation dans la View

Pourquoi print_name(), ou drawItYourself() n'appartiendrait pas à la vue, toujours sous forme de méthodes, par exemple sur une classe UserUI, RoadUI ?

Cela dit pour print_name(), à par le nom je vois pas pourquoi elle ne devrait pas être dans le modèle. Tu l'appelles get_name() et c'est parti

C'est un des problèmes que j'ai sur le plugin RSS de Symfony : par commodité, quand tu veux facilement rajouter des champs (forcément mis en forme), faut rajouter une méthode correspondante dans le modèle. Je trouve ça à chier, ils pouvaient faire la même chose avec des "partials" (mini-templates). Par contre là à la limite ce serait un peu lourd niveau perfs. Il manque des classes xxxUI - correspondant à un modèle ou pas - dans lesquelles pourrait rajouter en 5 sec des méthodes destinées à l'affichage. Pourquoi pas wrappant le modèle au lieu d'utiliser dirctement le modèle dans la vue...
C'est ptet pareil dans Rails, vu que symfony a piqué pas mal dessus ?

Et pour paypal, pourquoi n'y a-t-il pas une seule méthode qui s'occupe de lire la commande et de la transcrire en champs Paypal (+ une autre à côté pour le retour) ? J'ai l'impression que chez toi c'est découpé en 73...

Il fait la même chose dans l'autre sens, les modèles doivent connaître la manière dont il seront affichés (et donc dans le cadre de quel média ils seront affichés), c'est pas mieux

Et c'est inutilisable dans le cadre d'une app avec GUI

D'ailleurs en parlant d'apps avec GUI, Cocoa sur mac a tendance à violement forcer le MVC, et peu s'en plaignent. Le problème c'est aussi que MVC a justement été créé dans le cadre du codage d'apps desktop (en Smalltalk), les interactions comme les outils ne sont pas les mêmes.

Tu as raison, dans Rails il y a un helper pour chaque Model où on a accès aux méthodes pour la view, visiblement je ne l'utilise pas suffisamment ou mal    (ça pourrait être le inner-class dont il parle par exemple).
 
Pour Paypal ça remonte à un bout de temps donc je sais plus trop, mais je me souviens d'avoir dégusté. Un truc chiant avec paypal c'est que les montants sont sous la forme "15.00" (un string quoi) et ça avait du me péter à la figure quand dans mes views c'était un int qui était attendu (j'utilise d'autres paiements en ligne qui travaillent en centimes).

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