> {% for POST in LISTPOSTS%}
>
> {{POST.post_content}}
> {{ POST.post_title}}
>
> ( Ce double post "POST.post_.." est dommage, mais c'est ce qu'il y a en bdd
> je pense )
On est sur du consensus lisibilité/quantité de code à
produire/satisfaction des users / satisfaction des plugineurs.
Après réflexion, je ne suis pas sûr d'exposer directement les colonnes
des records à twig, ne serait-ce qu'à cause par exemple d'un
p.post_password, il y aura très probablement un proxy sur les record.
Et puis le getXXX me paraît bien comme filtre, on peut donc partir sur
un p.content, qui semble contenter tout le monde. Il suffira
d'enrichir les $rs des méthodes qui manquent.
> Et sur la partie "Afficher uniquement les deux derniers billets"
> Je pense que ce serait plus lisible de séparer les deux version de twig,
> dans deux zones de code.
>
> --
>
> Pour plus de clarté, je pense que ce serait bien de faire indépendamment
> l'explication pour header et pour footer.
N'hésite surtout pas à retoucher les pages, c'est justement le but. On
peut en rediscuter sur la ml sur des sujets dédiés aussi.
> Ça me fait penser à un truc.
> La plupart du temps quand je cherche une info dans la doc en rapport avec
> les balises, je demande à google "<tpl:" et je tombe sur la doc.
> Ensuite je consulte la liste des balises pour trouver celle qui me conviens.
> (puis je grogne et j’installe expat :) )
Non ? Il y a des gens qui utilisent expat ? ;) Je suis bien heureux de
l'apprendre, finalement expat c'est un peu twig avant l'heure ;)
> Et une autre qui traitera ... de quoi ?
> La liste des objets a disposition dans chaque contexte/url
> et un morceau de doc de Twig ou un lien vers Twig ?
Grosso modo, ce sera ça.
Il faudra documenter :
* Les méthodes et attributs accessibles par les objets exposés (blog,
category, ...)
* Les fonctions et filtres définis par dc (car il y en aura, je vois
mal comment faire un tpl:EntryFirstImage en twig directement, quoique,
en méthode de $rsPost ...)
* Ce qui est par défaut dans le contexte d'une page donnée (et voir
niveau dev si on veut mettre des règles de nommage)
* Une vulgarisation de l'utilisation de twig, en renvoyant vers la doc
twig s'il faut
* Des règles de développement de templates, avec les blocks qu'il
faudra définir pour que les plugins puissent s'"incruster" proprement
* Une hiérarchie-type des templates
Et puis j'imposerais^W recommanderais bien fortement 2-3 templates de
base (surtout le single.html et le list.html), qui seront bien utiles
aux plugineurs.
--
Bruno
--
Dev mailing list - [email protected] - http://ml.dotclear.org/listinfo/dev
