Lost Edens

C’est de l’ordre du détail mais je me demandais pourquoi “fr-fr” et pas simplement “fr” comme j’ai pu le voir sur quasiment tous les sites que j’ai visités ?

Ca fait partie de la syntaxe d’une locale. Il est possible de donner un code secondaire après le code primaire utilisé pour le langage. En général, c’est utilisé pour spécifier un pays, et donc un dialecte. Le choix que tu peux faire là-dessus est entièrement subjectif. Vu que LE est majoritairement français, et que les dialectes des autres nationalités présentes parmis nos rédacteurs (suisse et belge) sont en fait assez similaires, j’ai jugé utile de le préciser. Mais ça change pas grand chose en pratique, tout le monde s’en fout de ce genre de détails, les moteurs de recherche les premiers.

Deux petites question à Tchyo à propos de Django :]

Peut-on cacher un champ d’un modèle dans la zone admin ? Je pense en l’occurence à mes SlugField ‘stripped_attr’ qui n’ont pas lieu d’apparaitre dans l’admin puisqu’ils sont rempli à partir du champ ‘attr’ correspondant (name => stripped_name, j’utilise prepolulate_from pour faire le boulot). C’est pas génant que ça apparaisse, mais si j’peux alleger le nombre de champ dans les formulaires d’admin ça serait pas plus mal.
=>edit: j’avais essayé le prepopulate_from + editable=False, mais ça ne semble pas marcher (le champ d’apparait plus, mais n’est pas rempli avec les bonnes valeurs).

Autre chose, je passe par apache et mod_python pour voir le résultat de ce que je fais, mais j’suis obligé de relancer apache à chaque fois que je fais une modif’ importante. Je pense que c’est normal (mod_python doit surement ne charger qu’une seule fois les classes et les conserver en mémoire tant que le processus apache existe), mais on peut pas changer ce comportement ? La aussi c’est pas bien grave, et surtout ça ne serait plus utile une fois le développement terminé, mais en attendant si j’peux me simplifier la vie… :]

Merci ^^

Ah cool, c’est quand même mieux de pouvoir testé sans avoir à rebooter apache toute les 2min

J’suis en train d’essayer de faire marcher ton slugify, pour l’instant je n’ai plus d’erreur, mais ya rien dans le champ
Pour mettre à jour django (j’étais sur la dernière release stable), j’ai supprimer le dossier python/Lib/site-package/django et j’ai pris celui du repository, ya rien d’autre à faire je pense ?
J’ai modifié mes méthodes str en unicode (Elles servent juste pour l’admin ces méthodes je crois, pour afficher les objets présent dans la base, tant qu’on a pas redéfinit le style d’affichage ?).

Tu l’as mis où le code de ta fonction slugify ? Ta créé un module à part que tu peux importer partout ? Pour l’instant je me suis pas cassé la tête, j’ai mis ça au début de mon fichier models.py

Ah bordel, mais comment c’est trop bon de développer avec Django en fait

On écrit pratiquement rien en code, et on a des composants fonctionnels en quelques minutes \o/

Un weblog avec commentaires ça doit pouvoir se faire en 5min chrono en connaissant bien chaque étape (perso j’suis encore accrocher aux tutos mais bon, j’arrive à adapter à ma sauce donc ça va

Plus jamais de site sans framework, c’est décidé.

Donc ça y est, tu comprends pourquoi j’ai décidé de faire un gros reset de la v3 il y a un peu plus d’un an ? :o Je trouve ça assez génial, supprimer le gros des aspects répétitifs (“SELECT * FROM…”) pour se concentrer sur la partie vraiment importante du travail. Et puis le Python est tellement plus agréable à utiliser. Plus qu’à trouver un boulot où le patron accepterait un « je peux pas dev en PHP, c’est contre ma religion. »

Ouep, en gros je me suis jamais dit “Comment je pourrais faire pour développer ça ?”, les questions que je me pose c’est plutot “Quelle fonctionnalités je pourrais bien ajouter ?”
C’est bien plus agréable de penser en terme de fonctionnalités quand même
(Mais je fais que des trucs simpliste pour l’instant, on verra si j’attaque des choses plus complexe comme la gestion des l’identification des User etc… ^^)

Tu peux remettre un peu en forme ta fonction (avec la balise bc[php] de Textile)? C’est illisible là, j’ai l’impression qu’il y a des catactères qui se balade dans le code, des morceaux coupés etc o_O

Le problème que je trouve à Smarty ou autre c’est la lourdeur qu’il apporte, que ce soit dans la mise en place ou dans le code après (même si il y a la compression, ca ralentis l’appli et franchement, pour les utilisations que j’en fais, je n’ai pas besoins de m’ajouter ce genre de contrainte ;)). C’est limite un autre langage à apprendre.
Pour ma part, j’utilise un système tout simple qui switch la css et le dossier du thème, rien de compliqué, très léger et facile à mettre en place.

Quand au fil, je vais voir pour faire quelque chose à la main alors. Parce qu’au final, faire un tableau c’est aussi chiant qu’un ajout manuel.
Par contre pour l’ajout manuel, tu stocks ça comment?

Bah il est vrai que c’est tentant d’avoir un moteur de template, mais bon, je me dis qu’à mon niveau je ne vois pas trop l’interêt.
D’autant que mon switcher de CSS me permet une séparation satisfaisante. Je n’ai qu’un fichier .php qui contient le template, mis en page en fonction de la css, et qui inclue au fur et à mesure les fonctions et classes dont j’ai besoins. Après je vois pas trop l’interet d’aller plus loin avec un template.html qui contient des trucs du style {MESSAGE} qui sera remplacé par du contenu, enfin à mon echelle.
Mais bon, comme je fais surtout du developpement et très très peu de production, ca reste du simple apprentissage donc pourquoi pas tester un peu tout. :3

C’est quoi cette synthaxe {% block ariane }, {{ forum.titre|escape }}{ endblock %} ?

(Sinon, tu penses quoi de TinybutStrong comme moteur de template?)

Bah il est vrai que c’est tentant d’avoir un moteur de template, mais bon, je me dis qu’à mon niveau je ne vois pas trop l’interêt.
D’autant que mon switcher de CSS me permet une séparation satisfaisante. Je n’ai qu’un fichier .php qui contient le template, mis en page en fonction de la css, et qui inclue au fur et à mesure les fonctions et classes dont j’ai besoins. Après je vois pas trop l’interet d’aller plus loin avec un template.html qui contient des trucs du style {MESSAGE} qui sera remplacé par du contenu, enfin à mon echelle.
Mais bon, comme je fais surtout du developpement et très très peu de production, ca reste du simple apprentissage donc pourquoi pas tester un peu tout. :3

Je le répète, mais le swap de CSS n’a rien à voir. Quand je parle de mise en page, c’est pas de savoir si ton titre sera en serif ou en sans-serif, mais simplement du code HTML en général. L’idée, c’est de séparer la partie du code où tu décides qu’il faut être identifié pour avoir accès à tel objet (la partie où réside la logique de l’application) de la partie où tu décides qu’un h3 sera plus approprié qu’un h4 pour son titre (la mise en page). L’intérêt, c’est la facilité à évoluer. Si tu décides de passer d’HTML à XHTML un jour (juste un exemple), tout le code qui a trait à ce problème est dans un seul endroit. L’autre intérêt, c’est qu’un bon moteur utilise une syntaxe plus clair, plus facile à entretenir.

Le problème, c’est qu’on touche ici à ce qui est (à mon avis) un problème dans le design de PHP. Le langage en lui-même est un moteur de template. Du coup les utilisateurs ont tendance à se demander l’intérêt d’en utiliser un autre vu que le langage s’en charge déjà. Seulement, PHP est un moteur beaucoup trop puissant à mon goût. Il est possible de l’utiliser raisonnablement, mais en pratique les gens font souvent n’importe quoi, et tu te retrouves avec des algorithmes et des requêtes SQL entre deux appels à echo. Et c’est vraiment spécifique à ce langage, même ASP qui faisait un peu pareil s’est débarrassé de ce foutoir avec le passage à .NET (même si je trouve ça laisse encore à désirer).

Sinon, je vois pas trop d’où sort l’excuse “je fait que du dev, pas de prod”. Je peux comprendre le sens même si c’est mal formulé (ce site est pas sorti de nulle part, il y a eu une phase de dev aussi ¬¬), mais je peux difficilement approuver. Moi aussi je fais pas mal de dev “pour du beurre”, j’ai réalisé des dizaines d’applications/sites/scripts dont la durée de vie va de “quelques mois en privé” à “jamais fini” en passant par “tué dans l’oeuf”. Mais ça ne m’empêche pas de faire des efforts pour produire quelque chose de bien conçu. Un design réussi ne permet pas seulement de faciliter la maintenance, mais aussi la production initiale du code, donc pourquoi se tirer dans le pied en faisant des décisions inefficaces ? Le but de ce genre de développement n’est-il pas de gagner des compétences pour les réutiliser dans des situations concrètes ? Pourquoi prendre des mauvaises habitudes alors ?

C’est quoi cette syntaxe {% block ariane }, {{ forum.titre|escape }}{ endblock %} ?

C’est celle du moteur de template utilisé sur ce site. Je te donne un exemple un peu plus poussé, la template de l’index du wiki.

{% extends "base_xhtml.html" %}


{% block titre %}Wiki{% endblock %}


{% block ariane %}<a href="/">Accueil</a> » Wiki{% endblock %}


{% block main %}
    <h2 class="titre-site"><img src="{{ media_url }}images/icones/fleche-titre.png" alt="" /> Wiki</h2>
    <div class="index-wiki">
        <h3 class="titre-site"><img src="{{ media_url }}images/icones/fleche-reponse.png" alt="" /> Liste des encyclopédies du wiki</h3>
        <ul id="encyclo-list">
        {% if object_list %}
        {% for e in object_list %}
            <li>
                <p><img src="{{ media_url }}images/icones/fleche-reponse.png" alt="" /> <a href="{{ e.get_absolute_url }}">{{ e.titre|escape }}</a> - {{ e.description|escape }}</p>
            </li>
        {% endfor %}
        {% else %}
            <p>Aucune encyclopédie dans la base de données.</p>
        {% endif %}
        </ul>
        <p>Un <a href="/atom/wiki/">flux de syndication général</a> <img src="{{ media_url }}images/icones/feed-index.png" alt="" /> (au format Atom) est disponible.</p>
    </div>
{% endblock %}

Les blocs sont des éléments définis dans la template de base (j’ai donné le bout de code correspondant plus haut), qui peuvent ensuite être ”écrasés” dans les templates qui en héritent. La syntaxe {{ }} permet d’afficher le contenu d’une variable. Pour le reste, je pense c’est suffisamment explicite. C’est pas très différent de Smarty, qui utilise {$mavariable} et {for}{/for}.

(Sinon, tu penses quoi de TinybutStrong comme moteur de template?)

Je connais de nom, j’ai jamais essayé. Comme je l’ai dit dans mon message précédent, c’est pas le choix qui manque dans ce domaine, le mieux est d’en choisir un à titre personnel et d’étudier les autres au cas par cas en fonction des besoins.
J’ai jeté un coup d’oeil vite fait, ça a l’air pas mal. Ils m’ont fait peur quand ils ont parlé de bases de données mais en fait c’est juste un joli nom pour parler d’itérations sur des ressources, donc des requêtes déjà faites. Bien sûr il a bien fallu qu’ils ajoutent la possibilité d’exécuter du code PHP arbitraire, mais personne n’est obligé d’utiliser ça. L’utilisation coté PHP est aussi un peu inutilement compliqué par moment (tous ces MergeBlock(), surtout).

Plus généralement, je suis peut-être pas la personne adaptée pour te donner un avis sur tous les modules PHP existants. J’ai abandonné ce langage pour tout mon dev personnel il y a déjà plus d’un an, et je ne l’ai pas regretté une seule seconde. Je l’utilises encore pour “payer les factures” mais idéalement, j’aimerais trouver un job qui me dispense de me rabaisser à ça quand j’aurais fini mes études.

Ça m’empêche pas de suivre l’évolution de loin, et franchement, s’ils continuent comme ça, je serais pas étonné que la maison s’écroule d’ici quelques années.

Angellore: Je te conseille de lire ce sujet, FlorentG y explique rapidement le concept de l’architecture MVC (utilisé ici) permettant le découpage en 3 couches. http://forum.hardware.fr/hfr/Programmation/PHP/model-controller-architecture-sujet_77425_1.htm

(encore que dans l’exemple il n’utilise pas de moteur de template ce qui rend les choses encore un peu trop bancale à mon gout, mais c’est voulu, c’est juste pour montrer le principe de base)