django_hg UI
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):
- The list of repositories (
list); - Different views of a repository: Browse (
browse), list revisions (Changesets), display a revision (Changeset) and view an overview (Overview) - Different views of a file in a repository: the revisions experienced by this file (
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?
Quelques mots sur moi