Reprise du message précédent :

Donc ton concept, c'est : plutôt que de guider au maximum de ce que je peux faire, je laisse tomber, je laisse l'anarchie s'installer ?
 
En plus pour résoudre pas mal des pb dont tu parles, il y a des solutions :
- tests unitaire & code coverge => si le mec veux pas factoriser, il va devoir se taper les tests de ses nouvelles fonctions déjà couverte, sinon tu le crames avec une diminution du code coverage
- non séparation MVC : une petite code review régulière et hop c'est cramé quand ça détonne "trop"
 
Enfin, ça pour le coup ça commence à être sortir l'artillerie lourde. Chose qui n'a pas trop de sens pour un petit projet perso, ou un petit site fait rapidos pour une boite qui se fiche de l'info.
Mais même dans ces cas, smarty ça n'handicap en rien (si, faut maitriser {if} et {foreach}), et ça évite de tomber soit même dans des solutions de facilités (qui seraient pénible pour qui reprend le projet, ou bien soit même après quelques mois)

On est complètement d'accord, ça va dans le même sens je trouve
 

Mon argument pour le copy/paste de template smarty, c'est que le language est très facile à prendre en main. Et c'est tout aussi valable pour PHP, je dis pas le contraire.
 
Par contre je ne suis pas d'accord quand tu dis que :
- "tu ajoute de la complexité" => niveau développement c'est transparent, niveau exécution aussi (si template compilé)
- "ça n'empêchera pas un développeur de faire de la merde" => bah si, ne pas avoir accès au namespace global c'est une première garantie. Ne pas pouvoir être tenté de définir une fonction entre dans lignes aussi.
- "Utiliser Smarty parce que les développeurs sont potentiellement ignorants, c'est pas une bonne idée", si, vu qu'au final l'approche est la même qu'un système qui valident le suivit des guideline ! C'est exactement la même approche : avoir des outils qui te garantissent de dévier le moins possible de l'architecture souhaitée

Non, c'est pas transparent. Tu ajoutes une lib à ton projet. Tu dois la configurer correctement et elle impacte le déploiement de ton application.
C'est de la complexité ajoutée.
 

Garantie de rien. T'as dit toi-même que ça pouvait se contourner.
 

Non, un outil de validation des guidelines n'ajoute pas de code, n'ajoute pas de dépendance à ton projet, ne change pas son déploiement.

Parceque tu n'utilises pas de lib pour gérer tes templates PHP ?
Tu fais un "include" direct ? Rien pour te gérer du cache ? Rien pour éviter d'avoir des conflits de noms ? Accès à "trop" de variables dans ton template ?
 

Pour le faire, c'est pas "naturel", faut le faire "exprès".
Le développeur qui n'est pas famillier avec la séparation "métier/vue" il sent que ya un problème s'il doit faire du php dans son template smarty. Par contre, dans un tempate PHP, c'est quoi le problème ?
 
Limite même tu peux aller virer la fonctionnalité smarty {php] et hop, là t'as la garantie
 

Ouai donc c'est une super chose.
Ce qui n'enlève rien aux avantage d'un moteur de template rigoureux

 
Non non, tu as bien compris, MVC + Smarty.
Le controller envoie les données à la view qui elle les envoie à la template

Ya qu'à pas utiliser PHP, et ya pas besoin de se poser ce genre de questions

 
Ca c'est la réponse facile
De toute façon après que les projets php soient arrivés à "maturité", ils passaient tout en java

Non, des guidelines, de la revue de code comme tu dis plus bas. Mais pas une solution en lib toute figée et restreignante (?) comme Smarty. Parce que ok Smarty ça dissuade faire qq grosses conneries, mais du même coup ça enlève beaucoup de possibilité de personnalisation, de réutilisation et compagnie (j'ai un souvenir horrible de Smarty, utilisé par moi tout seul alors que ce n'était pas nécessaire).

Et surtout, un dev qui n'a pas bien intégré la différence entre métier et affichage (c'est quand même basique), il est pas embauché à la base. Il galèrera bien trop sur tout le reste. Et un stagiaire, j'en ai pas, et sinon je lui apprendrais

Après, si t'as régulièrement des collègues qui gèrent pas trop, effectivement, soyons pragmatique, Smarty peut être un flic sympa

A ce propos, je veux bien de vos conseils sur ce qu'il faut faire pour présenter un projet existant à un nouveau développeur

Bah pour le moment, après 1 an et demi sur le projet, où 3 dev bossent à plein temps, 3 autres interviennent à l'occasion, et 5 ou 6  clients interviennent sur leur version, ya pas de bloquage.
Ya bien eu réflexion pour savoir comment gérer un cas ou deux (qu'on gérait traditionnellement à l'arrache), et au final ça nous a forcé à poser le problème, et a trouver une approche "clean" qui colle vraiment à la logique MVC... Donc contrainte "bénéfique" au final.
 
Après on passe peut-être à côté de certains trucs, mais là comme ça je vois pas trop bien en quoi ça gène la personnalisation, la réutilisation ou autre
 

C'est renier le problème, c'est pas bon ça
 

Collègue, ou bien client...
Et même si t'es seul sur ton projet, que tout gère nikel, si tu pars en vacances (chose qui arrive des fois ) et que ya un bug, bah c'est un collègue qui va devoir s'y coller, donc faut quand même prévoir qu'une personne non impliquée dans le projet puisse faire des intervention occasionnellement (donc grosse probabilité d'avoir un code moins clean que d'habitude)
 

"Et surtout, que je te vois pas coder en php dans les fichiers de template php ! "

C'est toujours sport, ça. J'imagine que le gars a au moins une vague notion de ce dont il s'agit ? (domaine, but du projet, etc...)
Bref, dans l'ordre je ferais :

• si c'est une appli ou un site Web (par opposition avec une couche de services, par exemple), tu lances le truc direct.
• pendant que ça charge, tu récapitules ce que fait le truc : "nos clients veulent ci et ça, alors notre outil permet ceci et cela"
• une fois l'appli up, tu fais une pétÿte démo, histoire de se mettre dans la peau du client.
• ensuite, schéma d'archi du bordel. Si possible, lier avec une démo à l'écran ("tel composant est lié avec çui-ci", etc...).
• puis, tu lui montres ton env de dev : IDE, outil de versioning, fenêtres de console (si y a), les fenêtres dont tu as régulièrement besoin, etc...
• le code : comment il est organisé dans le versioning, comment c'est structuré, les conventions de code, les tests, etc...
• la doc : si vous avez un wiki ou un intranet ou quoi que ce soit de semblable, tu lui files en lui disant quels sont les points que tu consultes le plus souvent.

Et une fois tout ça fini, tu lui files toutes ces infos par écrit C'est donc une bonne idée de faire tout ça avant que le gars arrive Mention spéciale si tu rajoutes des screenshots pour les points importants

Syntaxe nouvelle yes, a base de {if} et {foreach}, prise en main : 5 minutes chrono comme je disais plus haut
 
 
Ok, t'as redéveloppé un moteur de template de ton côté en fait
Moi j'ai juste téléchargé Smarty
 
Au final tu vas y trouver les fonctionnalité poussées dont tu as besoin, vu que tu va le développer pour toi le moteur, mais pour quelqu'un qui n'a pas besoin de fonctionnalité poussées comme celle là, tu conseillerais quoi ?
Développer son propre moteur PHP ou reprendre un moteur existant, type Smarty ?
 
 
Tes clients ont des accès... FTP ?
 
 
Oué, dont on est tout les deux a fond pour que sur toutes les choses qu'on peut brider, on bride, pour avoir la garantie sur l'idéal "MVC"
 
Après si ton moteur de template il est méga rapide, tout ça, c'est parfait.
La question : pourquoi avoir tout redéveloppé from scratch, et pas utilisé un moteur existant, et le tweaker ?
Au final, un template smarty compilé ça te fait un fichier PHP, et là on revient exactement au même niveau que là où tu pars, au niveau instrumentation du template PHP, non ?

ben tiens en parlant de versionning, y'aurait pas un petit tuto qui traine pour s'y mettre sans trop de soucis, j'ai jamais fait de versionning, et je crois que ça me manque cruellement

Je ne me pose pas des problèmes qui n'existent pas
 
Le prochain dev, faudra qu'il connaisse symfony à la base, donc il maitrisera forcément tout ça

Mais comme je disais, ya plein de situation où tu ne maitrise pas ce qui va passer sur le code :
- vacances / maladie & bugs urgent => hop le premier couillon venu va devoir s'y coller
- tu couche avec la fille du patron => t'es viré => remplacement dans l'urgence => le mec embauché n'est pas trop con mais ne maitrise peut être pas aussi bien que tout l'archi globale dans un premier temps
- stagiaire (si t'en veux pas, on va dire que le fils du patron doit faire un stage alors ), qui y va a taton, il découvre et testouille tranquillou
 
Enfin sauf si le truc sur lequel tu bosse n'a pas de bugs et n'a pas besoin d'évolution, et est voué a mourrir rapidement, avant que de nouvelles version php & mysql soient mis en prod, ce qui pourrait provoquer une incompatiblité et demander un peu de maintenance sur le projet pour réparer des trucs

Bah s'pas très difficile le versioning
 
Le tutorial mercurial est acceptable, et hg est très bien.

La réflexion était plutôt sur le mode de communication avec le client : FTP vs SVN ou autre système de versionning quoi
 
 
Bah oué idem en fait
Et les templates gérés par smarty c'est clairement pas un truc problématique côté perf en fait, c'est peanuts quoi
 
 
Si c'est pas de l'argument d'autorité ça...
 
Et il bloque les accès directs aux données, la possibilité de définir des fonctions & co ?
Si non, c'est certe fonctionnel mais pas ultime, vu qu'on peut très facilement se retrouver à quitter le modèle MVC, là où un framework se devrait l'interdire par définition non ?

Dans la mesure où ce n'est pas possible (au mieux en limitant sa flexibilité il peut partiellement restreindre les dégats que tu fais), où la majorité des gens ne savent de toute façon pas ce qu'est le MVC (ça inclut 99% des gens qui utilisent le terme btw, moi compris) et où la majorité des frameworks MVC ne sont pas vraiment MVC (partiellement une conséquence du point 2)… non

Il peut suggérer un chemin dans la facilité qu'il donne à faire telle ou telle chose, mais une propriété intrinsèque du développement c'est que tu peux toujours passer outre les suggestions (ou contraintes) de l'outil d'une manière ou d'une autre.

Cool j'ai gagné
 
Smarty wins!

 
Tiens tiens

http://groups.google.com/group/pro [...] 7873?pli=1

C'est surtout que Propel est totalement useless depuis l'arrivée de Doctrine  

Bof, sur l'appli que je fait en ce moment, les perfs sont vraiment très correctes avec Smarty, la prise en main a été hyper rapide et le système de cache est vraiment pas mal foutu

Non, mais smarty/php brut c'est comme amd/intel, hein, ya ni bonne réponse ni discussion rationnelle sur la question.

De toute façon intel caÿ mieux ça accélère internet

Intel Web Outfitter FTW

Je comprend plus rien à Firebug il se désactive dès que je recharge la page

edit : ah nan c'est bon, faut juste pas cocher "désactiver pour toutes les pages"

Sinon, pourquoi il est obligatoire d'avoir au moins un <li> dans un <ul> ? Les listes vides ça existe pas ?

Ca sert à rien, c'est comme les paragraphes vides  

Et les divs vides ?

Là j'ai du javascript, la liste se remplit au fur et à mesure, donc elle peut être vide au départ, ou à n'importe quel moment, tout en servant à quelque chose.

En même temps c'est le validateur qui gueule, après que ta liste ou ton div soit vide / pas 100% W3C compliant je pense qu'il s'en fiche

Il s'en fiche mais il gueule ?

Hep les cadors,
 
j'ai créé une popup à l'aide d'un div et d'un peu de jQuery, ça marche très bien et tout.
 
Maintenant j'ai un comportement que j'aimerais bien changer: quand je redimensionne la fenêtre de mon navigateur, l'interface sous le popup bouge un peu, mais j'aimerais que le popup se relocalise au même endroit relatif de l'interface (j'imagine que là je me suis répondu à moitié).
 
J'ai essayé le position: relative mais ça fout la popup dans le flow du document qui du coup, glisse vers le bas, sous la popup (et non derrière la popup).
 
Ya moyen d'arranger ça en CSS?
 
Le style actuel:
 

div.popup {
    display:none;
    position: fixed;
    background:#FFFFFF;
    border:2px solid #cecece;
    z-index:2;
}

+1 Pas portable

<select name="classifieds_categories_id">
    <option value="0" selected="selected">Select a Category</option>
    {foreach from=$ensCC->getTab() item="cc"}
        <option value="{$cc->getId()}"{if $smarty.request.classifieds_categories_id|default:$c->getClassifieds_categories_id() == $cc->getId()} selected="selected"{/if}>
            {$cc->getLabel_()|af}
        </option>
        {assign var="ensCC2" value=$cc->getClassifieds_categories_childs()}
        {foreach from=$ensCC2->getTab() item="cc2"}
            <option value="{$cc2->getId()}"{if $smarty.request.classifieds_categories_id|default:$c->getClassifieds_categories_id() == $cc2->getId()} selected="selected"{/if}>
                {$cc->getLabel_()|af} &gt; {$cc2->getLabel_()|af}
            </option>
            {assign var="ensCC3" value=$cc2->getClassifieds_categories_childs()}
            {foreach from=$ensCC3->getTab() item="cc3"}
                <option value="{$cc3->getId()}"{if $smarty.request.classifieds_categories_id|default:$c->getClassifieds_categories_id() == $cc3->getId()} selected="selected"{/if}>
                    {$cc->getLabel_()|af} &gt; {$cc2->getLabel_()|af} &gt; {$cc3->getLabel_()|af}
                </option>
                {assign var="ensCC4" value=$cc3->getClassifieds_categories_childs()}
                {foreach from=$ensCC4->getTab() item="cc4"}
                    <option value="{$cc4->getId()}"{if $smarty.request.classifieds_categories_id|default:$c->getClassifieds_categories_id() == $cc4->getId()} selected="selected"{/if}>
                        {$cc->getLabel_()|af} &gt; {$cc2->getLabel_()|af} &gt; {$cc3->getLabel_()|af} &gt; {$cc4->getLabel_()|af}
                    </option>
                {/foreach}
            {/foreach}
        {/foreach}
    {/foreach}
</select>

Sous symfony on a des helpers pour faire ce genre de chose (et depuis le passage à sfForm c'est géré directement quand on render un sfForm).

Meuh non faut passer sous symfony
Chapitre sur la couche vue :
http://www.symfony-project.org/boo [...] View-Layer

Non il bloque pas et c'est très pratique parfois. Exemple chez nous (où on fait désormais que du symfony). On a fait un très gros projets de migration de nos applis PHP4 vers symfony 1.2. Les applis en PHP4 étaient un peu cracra (1 url 1 page enfin vous devez voir de quoi je parle ).
Lors de la première itération on est passé sous symfony mais avec dans les templates des requêtes SQL. Et les applis "symfonysées" fonctionnaient parfaitement.
Lors de la seconde itération on a viré le SQL des vues pour le mettre côté modèle.
Lors de la troisième itération on a passé toutes les éléments des vues sous forme de composant symfony réutilisables ce qui nous a permis de facilement faire une appli type netvibes avec nos composants    

Nous on a forké Propel

div.popup {
    display:none;
    position: fixed;
    background:#FFFFFF;
    border:2px solid #cecece;
    z-index:2;
}

 
Mets ton popup en position absolute et son conteneur en position relative.
 

 
Pas portable, pas portable... Soit tu maitrises l'environnement sur lequel tu bosses, et donc pas de problème.
 
Soit tu dois déployer sur un environnement que tu ne maitrises pas, et t'utilise un des très nombreux éditeurs qui fait un S&R de <?= par <?php echo dans tous tes fichiers... Ça prend 5 secondes.

Tu appelles ça une solution? Non. Tu oublies les shorttags et ton problème est résolu dans TOUS les environnements.

Je vais voir ça