Nautilebleu
Plongez dans mon univers
Plongez dans mon univers
Bien que je n’ai pas posté de message, je ne suis pas resté inactif ses derniers jours. Je travaille sur l’interface. Je prend mon temps, pour peaufiner, ce qui est un véritable plaisir, trop rare en production. En outre, cela m’amène à certaines réflexions sur le code sous-jacent.
Normalement, la logique du code aurait dû être issue des uses-cases. Cependant, étant donné la nature très expérimentale (pour moi) de ce projet, il était assez difficile de concevoir toute l’architecture du code et l’interface correspondante avant de me plonger dans le code. En fait, avant de commencer, je n’étais pas sûr d’arriver à lister le contenu d’un repository Mercurial dans django, et je n’imaginais pas vraiment faire l’authentification par django ! Ce projet est donc allé beaucoup plus loin que je ne le pensais, ce qui explique que le code soit amené à évoluer.
Bref, je me suis rendu compte que django_hg avait 3 niveaux (entre parenthèses, le nom de la vue correspondante dans django_hg) :
list) ;browse), lister les révisions (changesets), afficher une révision (changeset) et afficher un aperçu général (overview)filelog), afficher du code source ou d’un aperçu pour les images et les pdfs (filerev), les différences entre 2 révisions (filediff, très loin encore d’être opérationnel)Du point de vue de l’interface, ces trois types de fichiers utilisent des templates différents. Mais je suis en train de me dire que je pourrais refactoriser mon code pour qu’il n’ait que 3 vues, avec pour certains, plusieurs cas de figure.
Cela ne vas toutefois pas être pour tout de suite, car je voudrais avancer sur les considérations graphiques avant. À ce propos, quelles sont les bonnes pratiques pour distribuer des ressources graphiques (images, css, …) pour une application réutilisable ?
Although I didn’t post any message, I did not stay off these last days. I work on django_hg UI. I take my time, to refine, which is a real pleasure too rare in production. In addition, this leads me to some reflections on the underlying code.
Normally, the code logic should have been based on uses cases. However, given the highly experimental kind of this project (for me), it was quite difficult to conceive any architecture code and the corresponding UI before me diving into the code. In fact, before I start, I was not sure to be able to list the contents of a Mercurial repository in django, and I did not really dream up doing the authentication by django! This project is going much further than I thought, which explains that the code will have to evolve.
In short, I realized that had 3 levels django_hg (between parentheses, the name of the corresponding django_hg):
list); browse), list revisions (Changesets), display a revision (Changeset) and view an overview (Overview) filelog), display the source code or a preview for images and pdfs (filerev), diff between 2 revisions (filediff, very far to be operational yet) From the viewpoint of the interface, these three types of files use different templates. But I’m currently thinking that I should refactor my code so that it has only 3 views, with cases for some of them.
This does not however going to be right away, because I would move the graphic considerations. Speaking about that, what is the good practice to distribute graphics (images, css, …) for a reusable application?
