Reprise du message précédent :

 
Model et Netvibes dans le même nom de classe, ça sent la séparation des couches de qualité.

Elle n'existe tellement pas qu'elle est fortement recommandée par Matthew Weier O'Phinney.

ça me fait une belle jambe. Ici on parle de MVC, pas de Zend.

Parle-t-on encore de MVC dans ce cas ?

edit :

Et je balance pas le XML à un WS au fait, l'user doit lui même enregistrer le XML et l'importer dans iGoogle

Si c'est de la sérialisation c'est dans ton modèle que tu ajoute une méthode qui fait la sérialisation.
 
Et le contrôleur utilisera ces méthodes.

Non mais tu lis ce qu'il écrit? Le produit final que l'utilisateur de son machin va VOIR c'est le xml. Générer le xml en question à-partir des données, c'est le boulot de la VUE.

Ahhh, alors c'est la view ça
 
edit:  

Vous êtes en train de dire que je fou tout le code ci-dessous dans ma vue ?

public static void generateXML(Long projectId) {
    // Getting all the modules related to the project
    models.Project project = models.Project.find("byId", projectId).first();
    JPAQuery query = project.find("SELECT modules FROM Project" );        
    List<models.Module> modules = query.fetch();
    
    // generating the iGoogle XML file
    try {
        // creating the document
        DocumentBuilderFactory dbfac = DocumentBuilderFactory.newInstance();
        DocumentBuilder docBuilder = dbfac.newDocumentBuilder();
        Document doc = docBuilder.newDocument();
 
        //Creating the XML tree
 
        //create the root element and add it to the document
        Element root = doc.createElement("GadgetTabML" );
        root.setAttribute("version", "1.0" );
        doc.appendChild(root);
 
        //create child element, add an attribute, and add to root
        Element tab = doc.createElement("Tab" );
        tab.setAttribute("title", project.name);
        root.appendChild(tab);
        
        // and so on
        Element layout = doc.createElement("Layout" );
        layout.setAttribute("spec", "THREE_COL_LAYOUT_1" );
        tab.appendChild(layout);
 
        Element section = doc.createElement("Section" );
        tab.appendChild(section);
        
        Element module, userPref, modulePrefs;
        // iterate over all the modules
        for (models.Module m : modules) {
             module = doc.createElement("Module" );
             module.setAttribute("type", "RSS" );
             section.appendChild(module);
             
             userPref = doc.createElement("UserPref" );
             userPref.setAttribute("name", "numItems" );
             userPref.setAttribute("value", "3" );
             module.appendChild(userPref);
             
             // TODO only works if the module has an URL field atm
             Class c = m.getClass();
             Field url = c.getField("url" );
             
             modulePrefs = doc.createElement("ModulePrefs" );
             modulePrefs.setAttribute("xmlUrl", url.get(m).toString());
             module.appendChild(modulePrefs);
        }
        
        // generating the XML
        renderXml(doc);
 
    } catch (Exception e) {
        System.out.println(e);
    }
}

oui, a part le select au début qui doit etre dans un modèle ( Module::findAll() par exemple)

Pourquoi pas ?
 
MVC n'indique pas comment est générée la View. Ça peut être des templates, ou comme dans ton cas l'utilisation d'une API spécifique.

Je crains fort que ce bout de code ne puisse pas être entièrement dans une seule couche...je vois au moins  un bout de modèle (une requête SQL) et un bout de vue (la création du document attendu en sortie à-partir des données).

La vue sont boulot c'est de présenter ça.
Parce que si un jour tu veux présenter ça dans une autre vue, par exemple destiné a une version mobile du site, tu ne va pas dupliquer le code de génération du XML.
 

...tu es désespérant.
 Pour son problème, le format XML en question EST de la présentation.

 
Apparemment les gens qui utilisent Play et Hibernate foutent ces findAll dans les controlleurs.
En toute logique c'est sensé aller dans une couche supplémentaire (que nous on appelle fabrique en cours, du coup je sais pas comment ça s'appelle réellement), mais vu que c'est du MVC...
Et pareil, dilemme, un modèle représente un objet, foutre un findAll dans un objet n'a pas trop de sens.

Quel est le problème avec une classe du modèle avec une méthode statique findall qui te retourne un tableau d'instances de cette classe?

Si c'est du Web, à priori il ne va pas balancer le XML as is, mais dans un page pour que l'utilisateur puisse au moins le copier/coller facilement.
 
Donc si le XML n'est qu'une partie du contenu de la page, y'a pas de raison que ce soit fait par la vue, alors que spécifiquement cette partie pourrais être réutilisable pour une autre utilisation.
 
Les contrôleurs et vues de 30 kms de long c'est juste le mal.

Si. Il veut sortir plusieurs formes de XML en fonction du service ciblé. Les données sont les mêmes, seule la manière dont elles sont présentées diffèrent. Ce n'est pas du modèle mais de la vue, point barre.

en static , çane me semble pas mal  
plutot que de faire une classique «fabrique» avec juste ça

Sauf que ta vue est censée aussi être réutilisable.
 
T'as une view qui génère une représentation des données pour l'utilisateur. Que ces données soient ensuite embedded dans une page, ou directement proposées en téléchargement, ça change que tchouf, c'est d'la vue.
 
T'as d'un côté le modèle qui se charge de stocker les données (ici apparemment ça va être la liste des modules choisis, et leur config peut-être), stockage dont les autres couches s'en foutent (ça peut être dans une BDD, un fichier XML, ou du .ini). Et de l'autre côté la représentation de ces mêmes-données.  
 
 
Faut bien faire la différence entre stockage, et représentation

Ah okay, parce que vous êtes en MVC, pour vous un modèle c'est juste une structure quoi...

Le modèle s'occupe de modéliser l'application sous forme d'objets métiers et offre une manière d'assurer leur persistence. La structure après tu choisis ce que tu préfères (genre ActiveRecord, etc.).

Je parlais structure au sens programmation du terme.
 
Parce que s'il n'y a aucune méthode métier dessus, ça ne sert juste à rien...

 
Bon allez, un lien, histoire de te montrer qu'on te raconte des choses généralement admises..même si c'est pas la première fois que tu montres une compréhension toute personnelle de ce qu'est MVC...
http://fr.wikipedia.org/wiki/Mod%C [...] od.C3.A8le
 

Donc tu met où la sérialisation/désérialisation si ce n’est pas dans le modèle ?
 
Exemple typique, j'ai un modèle Client, sa persistance est assuré par un ORM dans un SGBD, jusque là ça va. Mais bien sur, pour une communication B2B on utilise des WS SOAP en mode document... Forcement je vais avoir besoin d'une sérialisation XML dans ce format là...
 
Et pour moi un appel WS ce n'est pas une vue...

Vue = output. Donc si, la sortie d'un service SOAP est une vue. Idem quand tu fais un appel AJAX pour recevoir un bout de XML qui va te permettre de rafraîchir ta page. Le problème du modèle est de maintenir des données, pas de les formater pour être lisibles par un système externe.

C'est ballot, parce-que ça fait effectivement partie de la vue.
TIP : Si c'est lié à un accès ne venant pas de ton appli, c'est de la vue.

Ah ça pour citer machinbidule qu'est trop une méga pointure de la mort ça y va, mais alors quand il s'agit de comprendre la base de la base ya plus grand monde...

Je parlais du cas où mon application appelais un Web Service.

dans ce cas c'est évidemment du modèle, mais si tu ne vois pas la différence entre ça et le cas exposé par kozkoz, au-secours.

Pour moi c'est pareil, c'est sérialiser un objet dans un format définis par une personne tiers et dont on a pas le contrôle.
 

C'est pas parce que c'est la même chose que ça doit obligatoirement être au même endroit

Non. Dans un cas il s'agit d'accéder à une source de données. Dans l'autre il s'agit de présenter des données à l'utilisateur.
C'est pas parce-que tu utilises une fonction utilitaire dans une couche qu'elle ne peut pas être utilisée dans une autre couche pour faire autre chose.

Alors sous prétexte que, pour le moment, il ne prévois pas de communiquer avec son application avec un WS iGoogle ou NetVibes il va mettre son code dans une vue.
 
Alors qu'on sait que c'est un cas qui pourrais arriver tôt ou tard...
Et que si il le met dans le modèle, la personne qui un jour devras ajouter la fonctionnalité d'appel au WS trouvera très rapidement le code en question et n'aura pas a faire de refactoring avec tout les soucis que ça pose - refaire des tests de la fonctionnalité en question en plus de devoir faire les tests de la nouvelle fonctionnalité.

 
Putain mais t'es bouché toi hein...
Ce n'est pas lui qui irait lire iGoogle ou netvibes, c'est l'inverse!

Un WS tu sais, ça permet aussi d'envoyer des données... (si si je te jure, ça ne sert pas qu'à récupérer des données).
 
Genre il pourrais imaginer, via un appel WS à iGoogle, envoyer le document XML qu'il a généré, afin que son utilisateur n'ai pas à faire de copier/coller pour paramétrer sa page d'accueil.

Bah dans ce cas tu sais quoi? C'est de la vue!

En quoi c'est plus rapide à trouver de mettre dans le modèle plutôt que dans la view

Et quels refactoring ? Si le code est bien fait, la view est appelable par n'importe qui !

 
Ouais par contre ça si je fais un excès de zèle c'est imaginable.

 
J'ai du mal à voir pourquoi ici l'utilisation du static est bien.
 
C'est pas préférable d'écrire ça :

public List<Module> findAllModules(Long projectId) {        
    JPAQuery query = this.find("SELECT modules FROM Project" );        
    return query.fetch();
}

 
Plutôt que ça :

public static List<Module> findAllModules(Long projectId) {
    models.Project project = models.Project.find("byId", projectId).first();
    JPAQuery query = project.find("SELECT modules FROM Project" );        
    return query.fetch();
}

public static void generateXML(Long projectId) {
    // Getting all the modules related to the project
    models.Project project = models.Project.find("byId", projectId).first();
    JPAQuery query = project.find("SELECT modules FROM Project" );        
    List<models.Module> modules = query.fetch();
    
    // generating the iGoogle XML file
    try {
        // creating the document
        DocumentBuilderFactory dbfac = DocumentBuilderFactory.newInstance();
        DocumentBuilder docBuilder = dbfac.newDocumentBuilder();
        Document doc = docBuilder.newDocument();
 
        //Creating the XML tree
 
        //create the root element and add it to the document
        Element root = doc.createElement("GadgetTabML" );
        root.setAttribute("version", "1.0" );
        doc.appendChild(root);
 
        //create child element, add an attribute, and add to root
        Element tab = doc.createElement("Tab" );
        tab.setAttribute("title", project.name);
        root.appendChild(tab);
        
        // and so on
        Element layout = doc.createElement("Layout" );
        layout.setAttribute("spec", "THREE_COL_LAYOUT_1" );
        tab.appendChild(layout);
 
        Element section = doc.createElement("Section" );
        tab.appendChild(section);
        
        Element module, userPref, modulePrefs;
        // iterate over all the modules
        for (models.Module m : modules) {
             module = doc.createElement("Module" );
             module.setAttribute("type", "RSS" );
             section.appendChild(module);
             
             userPref = doc.createElement("UserPref" );
             userPref.setAttribute("name", "numItems" );
             userPref.setAttribute("value", "3" );
             module.appendChild(userPref);
             
             // TODO only works if the module has an URL field atm
             Class c = m.getClass();
             Field url = c.getField("url" );
             
             modulePrefs = doc.createElement("ModulePrefs" );
             modulePrefs.setAttribute("xmlUrl", url.get(m).toString());
             module.appendChild(modulePrefs);
        }
        
        // generating the XML
        renderXml(doc);
 
    } catch (Exception e) {
        System.out.println(e);
    }
}

 
Euh, j'arrive comme un cheveux sur la soupe, mais pour vous le code il va forcément dans une des 3 classes ? Ça vous arrive jamais de faire des classes utilitaires, du genre disons XmlModelSerializer, qui peut se réutiliser, se tester, avoir des options, etc... OU un XmlSerializer générique, qui doit déjà exister, et auquel il suffit de passer des données bien structurées, sans ces miyyards d'appels de fonction.