Reprise du message précédent :

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.

c'est pas seulement 3 classes, mais 3 groupes de classes, hein...
...et bien entendu à-coté de ça tu as des libs ou des classes "utilitaires"...

J'vois toujours pas comment je vais architecturer le bousin.
Une vue différente par type de XML généré (une pour Netvibes, une pour iGoogle, etc) ?
J'utilise une factory pour aiguiller mes vues ? Si oui où est-ce que je fou la factory ?

Si t'as plusieurs vues, dans le contrôleurs, tu choisis seulement la vue qui va bien en fonction du contexte.
 

Effectivement, tu peux avoir des machins à côté. Ça m'arrive d'en faire

 
Ne nous excitons pas, on va d'abord attendre qu'il sorte

Ca y est on peut ?
http://symfony.com/

Nan c'est toujours une bêta

certain ont ils bénéficié de formatin par sensio labs ? elles valent le cout ?

Bonsoir tout le monde (ou bonjour)

Est-ce qu'il y en a qui touchent leur bille en zend framework sur ce topic? J'ai un petit soucis et plutôt que de faire un topic je demande direct ici desfois que quelqu'un aurait déjà eu à faire la même chose.

En fait j'aimerais afficher des images qui ne sont pas dans le dossier public, mais dans un autre dossier, inaccessible aux internautes.

Après une petite recherche sur internet 'ai fait une methode dans mon controller pour lire le fichier et l'envoyer à la vue qui semble correspondre à ce qu'il faudrait faire à priori:
(a chaque fois j'ai mis les url en absolu, c'est juste pour l'essai là)

public function readpicAction()
    {
        $this->_helper->layout->disableLayout();
        $this->_helper->ViewRenderer->setNoRender();
 
        $file = "http://localhost/monsite/files/pics/15/mini/167126_mini.jpg";
 
        $info = getimagesize($file);
        $mimeType = $info['mime'];
 
        $size = filesize($file);
 
        $data = file_get_contents($file);
 
        $response = $this->getResponse();
        $response->setHeader('Content-Type', $mimeType, true);
        $response->setHeader('Content-Length', $size, true);
        $response->setBody($data);
        $response->sendResponse();
        die();
    }

et dans ma vue j'insere le lien de la methode qui lit l'image dans le code html comme ceci:

<img src="localhost/monsite/public/index/readpic" />

Ce qui ne fonctionne pas. Maintenant si ça se trouve, c'est pas un problème de zend framework mais une erreur plus fondamentale dans mon PHP tout simplement, je vois pas ce que ça peut être... ou plutôt je ne vois pas trop comment faire...

Bon finalement j'ai réussi, il est tard j'ai pas les yeux en face des trous, déjà filesize passait pas avec l'url tel que j'ai mis, http://localhost/etc... il fallait utiliser le realpath, en suite le die() était de trop, je l'avais vu dans un exemple sur le net je l'ai mis sans trop savoir pourquoi il était là, pas très malin de ma part.  Et j'arrivais pas à débuguer mes variables parce que j'avais oublié de faire une vue readpic.phtml, ce que j'ai fait juste pour tester mes variables. Maintenant ça marche C'est pas une bonne heure pour coder en fait  

C'est un bon début, mais si tu ne veux pas plomber les perfs, il faut rajouter la gestion des headers HTTP pour la mise en cache dans la navigateur, cf : (et je pense que c'est pas encore parfait, car je ne gère pas le "If-Modified-Since" )
 

Pourquoi vous servez pas vos fichiers statiques via un serveur HTTP fait pour, genre Apache ou NGinx directement sans passer par PHP

A priori on a ce genre de cas quand c'est un fichier temporaire qui n'est pas dans l'arbo. publique de l'application.

le fichier est statique, mais il peut avoir des meta data issues de la bdd, ne serait ce que les droits d'accès

Merci MEI pour la suggestion, c'est l'occasion de faire du cache, c'est une partie de php à laquelle je n'ai jamais touché. Tiens je vais essayer de le faire en utilisant zend_cache tant qu'à faire.
 
Alors en fait ce sont des photos statiques, et non temporaires, ce seront des avatars et des photos des utilisateurs (site communautaire). Si je les met pas dans le public, c'est pour des raisons de sécurité, j'ai cru comprendre que c'était dangereux de laisser un accès direct aux photos aux internautes, et aussi ça empêche de faire des liens qui pointent directement vers les photos .
 
Par contre je pense qu'il me manque un élément théorique pour comprendre la remarque de Masklinn, mon php tourne bien sous apache, comment est-ce que je pourrais faire sans passer par le php tout en ayant mes photos en dehors du dossier public ?

Tu peux avoir des rules un peu moins drastiques pour le .htaccess.
 
Sinon Zend_Cache ne sert à rien ici si c'est un fichier sur le disque (sauf si ton cache est un Memcached et que t'as de la RAM à perdre pour ça).
Ici je parlais vraiment du mécanisme de cache du browser. Et aussi pouvoir ne pas envoyer le fichier si ce n'est pas utile (et donc économiser de la bande passante de ton côté).

ok, j'ai pas trop regardé ce qu'il faisait encore, j'ai juste vu ça dans ma librairie, faudra que je regarde ça de plus près

 
X-Accel-Redirect/X-Sendfile

est-ce que c'est courant qu'il soit dispo sur les configs des hebergeurs le module x-sendfile?

 
Same question here.

Je vois pas trop en quoi c'est dangereux (du moment que tu te fais pas injecter du code dans tes images que les utilisateurs uploadent), à la limite pour limiter le hotlink, et encore, là PHP va se faire chier à faire un readfile à chaque fois..

Ben c'est pour éviter ça en fait.

Mais ça change rien, tu fais un file get contents de toute façon.

Supposons que ton image soit "infectée " alors oui elle n'est pas accessible en public mais sera quand meme affichée ("copiée" en public et toujours infectée donc...) quand on consulte les pages grace a ton script,

Dans les deux cas il faut que tu t'assures que l'image soit safe, alors pourquoi ne pas faire un script plus classique qui s'assure que c'est le cas avant de valider l'upload... Et qu'on accède directement aux images "publiquement"

Tu gagneras en perf et ce sera plus sécurisé que ton truc qui ne filtre... Rien.

Et ça n'a pas grand chose a faire sur ce topic

En cours on est en train de voir du "MVC" pour Java, mais cette pattern me perturbe vraiment et je maintiens que ce n'est pas du MVC :

entity -> session bean -> model -> controler -> view

Pour mon prof il y a du MVC dans du MVC :

entity -> session bean -> view (qui comprend model -> controler -> view).

wtf

 
 
Yep, l'un de mes ex-boss m'a inscrit à une formation Sensio Labs à 1600 € sur trois jours (repas light du midi compris).
 
Tu arrives, tu lookes le public qui se présente :
- Des Symfony fanboys (avec un Mac, sinon t'es un looser)
- Des chomeurs en recherche de valorisation de leur CV au pôle emploi
- Des mecs qui viennent du monde Cobol/AS400 et qui bittent rien au PHP
 
Hµg0 H4m0n te file des bouts de code, et au bout des trois jours il t'annonce fièrement que tu vois, avec Symfony, tu peux faire un site e-commerce en trois jours et commencer à engranger de la maille.    
 
Outre les mégas aneries que j'ai pu entendre (style SELECT * c'est mal, il vaut mieux faire SELECT tousleschampsdelatable), j'ai été plus que circonspect sur le framework en lui-même. Probablement parce que moi, je suis éduqué, j'ai une certification PHP5 (pas comme son public habituel), et que du coup, mon esprit critique m'empêche d’acquiescer sans réfléchir. Par contre les autres ils étaient super impressionnés et écoutaient la bouche béate... l'auditoire de béotiens idéal !  
 
Bref, le point positif, c'est que je me suis tapé trois jours de fou rire non stop, obligé de sortir de la salle tellement je rigolais. J'avais pas rigolé comme ça depuis 10 ans. Merci Sensio Labs pour ce moment humoristique !  

En quoi c'est mal

• T'as quasiment jamais besoin de tous les champs de ta table donc tu récupères (beaucoup) plus de données que ce dont tu as besoin, et si t'as des join ça fait une explosion de caca
• Ça rend ajouter des champs à une table dangereux: si tu récupères tes valeurs par position et que le nouveau champ n'est pas inséré en dernier tous tes offsets sont pêtés et tu récupères les mauvaises données
• Ça diminue la quantité de données envoyées ("*" vs la liste de champs) mais ça augmente le travail de la db (il faut qu'elle étende * en une liste de champs)

donc s't'à éviter dans une appli. Et en debug aussi quand t'as des tables merdiques avec 40 colonnes ou des colonnes TEXT.

Ah non merde excusez-moi, j'ai compris l'inverse (SELECT * c'est bien, pas l'autre) Je vous rassure, je n'ai pas de SELECT * dans mon logiciel

Et sinon, pour ma question ?

 
J'ai finalement suivi la formation aussi ( niveau 2  sur 2 j)  
 
le public était un peu plus diversifié que ça quand même , mais a priori j'étais le seul a déjà gagner ma vie avec php  
les principaux reproches : formation sur un FW non stabilisés et tu le découvres au début de la formation ( après avoir payé ) : c'est sf 2.1 qui aura le support à long terme ( et la version finale de la gestion de la sécurité, et le choix de l'orm supporté)
Le formateur insiste plus sur ce qui a été compliqué a mettre en place ( la génération de fragments et leur mise en cache, l'injection de dépendance) que sur ce qui est compliqué à utiliser : formulaires un peu funky par exemple
Pas de projet type : donc on perd du temps a mettre en place des trucs basiques, temps qui manque pour la partie avancée par la suite. Il aurai mieux valu distribuer un projet type  
 
les avantages : ça m'a quand meme fait faire un bon tour d'horizons des fonctionnalités.  

 
Pas convaincu. C'est vraiment trop court, et le niveau des intervenants très varié qui fait que ça n'avance pas optimalement.
 

 
la mesure hfr  

J'aimerai beaucoup avoir plus d'explication sur les mots suivants :
 

Le déterrage de topic. :-P
 
Dans l'absolue Symfony est vraiment bon depuis Symfony 2.1.

oui mes excuses pour le déterrage
 
symfony j'ai pas encore un super feeling, car j'ai totalement débuté le php objet (et sf2 avec) en récupérant un projet énorme et bâclé, autant dire que c'était pas une mince affaire. C'est surtout l'intégration de doctrine qui change la vie je trouve.

J'avais fait du Zend Framework 1 avant donc forcement la plupart des concepts était là.
 
Mais bon pas de Doctrine ici, tout passe par des web services proprio.

Hello,
Je me suis mis à Symfony 2.
 
J'ai une question à propos des relations bidirectionnelles :
http://fr.openclassrooms.com/infor [...] tionnelles
 

 
Je m'étais dit que j'allais choisir de mettre le "bon setter" du côté propriétaire de la relation.
Mais ça me semble un peu casse gueule de se satisfaire d'une telle promesse, surtout si le code est repris par d'autres ensuite.
Est-ce que vous auriez une astuce pour empêcher de se tromper ? Proprement ?
 
 
En truc pas propre, j'avais pensé à créer 2 setters du côté A :
- un setEntityNBD() (pour Non Bi Dir)
- un setEntity() qui fait un bête die() / throw une exception, histoire de voir son erreur tout de suite ...      
(sa présence est nécessaire pour éviter qu'un setEntity() classique soit régénéré lors d'un doctrine:generate:entities)
 
Et dans le setter du côté B : on call le setEntityNBD de A
On utilise le setEntityNBD nulle part ailleurs, mais comme le nom est suffixé NBD, c'est moins casse gueule.
 
Ca a l'air de marcher en l'état, mais je crains que le A::setEntity() soit utilisée automatiquement par Symfony dans une autre situation, et donc problème  
 
Votre avis sur le sujet ?

C'est plus du Doctrine que du Symfony 2 là.
Dès qu'on utilise un ORM, si on ne connais pas son fonctionnement, on risque de se tromper.
 
Après, ici ça semble logique, c'est toujours le conteneur qui maintient la cohérences des liens et pas le contenu (logique car le fonctionnement est toujours valable que l'on soit en relation 1-1, n-1 ou n-n).
 
Mais le mieux c'est de documenter son projet avec des règles de codages et des "recettes" de base dans un Wiki pour que chaque développeurs (surtout les nouveaux arrivants) puisse avoir un endroit de référence pour savoir ce qu'il faut faire et ne pas faire.
 
Et après, bas, tests unitaires de ce que l'on code hein, comme ça pas de doute sur ce que l'on livre.