mirror of
https://github.com/ae-utbm/sith.git
synced 2025-11-10 05:53:06 +00:00
@@ -182,29 +182,19 @@ ainsi même que de l'héritage de templates.
|
||||
si on souhaite faire des modifications côté client,
|
||||
il faut utiliser du Javascript, rien ne change à ce niveau-là.
|
||||
|
||||
### jQuery
|
||||
### Typescript
|
||||
|
||||
[Site officiel](https://jquery.com/)
|
||||
[Site officiel](https://www.typescriptlang.org/)
|
||||
|
||||
jQuery est une bibliothèque JavaScript
|
||||
libre et multiplateforme créée pour faciliter
|
||||
l'écriture de scripts côté client
|
||||
dans le code HTML des pages web.
|
||||
La première version est lancée en janvier 2006 par John Resig.
|
||||
Pour rendre le site interactif, nous n'utilisons
|
||||
pas directement Javascript, mais Typescript.
|
||||
Il s'agit d'un langage construit par-dessus Javascript,
|
||||
en ajoutant un typage statique et des éléments de sucre syntaxique.
|
||||
Grâce au système de type, le code est plus lisible,
|
||||
à la fois par les humains et par l'IDE, et plus fiable.
|
||||
|
||||
C'est une vieille technologie et certains
|
||||
feront remarquer à juste titre que le Javascript
|
||||
moderne permet d'utiliser assez simplement
|
||||
la majorité de ce que fournit jQuery
|
||||
sans rien avoir à installer.
|
||||
Cependant, de nombreuses dépendances du projet
|
||||
utilisent encore jQuery qui est toujours
|
||||
très implanté aujourd'hui.
|
||||
Le sucre syntaxique qu'offre cette librairie
|
||||
reste très agréable à utiliser et économise
|
||||
parfois beaucoup de temps.
|
||||
Ça fonctionne et ça fonctionne très bien.
|
||||
C'est maintenu et pratique.
|
||||
Il faut parfois se battre un peu contre le système de types de Typescript,
|
||||
mais globalement Typescript est une alternative largement préférable à Javascript.
|
||||
|
||||
|
||||
### AlpineJS
|
||||
@@ -270,17 +260,6 @@ sur tous les navigateurs contrairement
|
||||
à un simple icône unicode qui s'affiche
|
||||
lui différemment selon la plate-forme.
|
||||
|
||||
!!!note
|
||||
|
||||
C'est une dépendance capricieuse qui évolue très vite
|
||||
et qu'il faut très souvent mettre à jour.
|
||||
|
||||
!!!warning
|
||||
|
||||
Il a été décidé de **ne pas utiliser**
|
||||
de CDN puisque le site ralentissait régulièrement.
|
||||
Il est préférable de fournir cette dépendance avec le site.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Git
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
L'ORM de Django est puissant, très puissant, non par parce qu'il
|
||||
L'ORM de Django est puissant, très puissant, non pas parce qu'il
|
||||
est performant (après tout, ce n'est qu'une interface, le gros du boulot,
|
||||
c'est la db qui le fait), mais parce qu'il permet d'écrire
|
||||
de manière relativement simple un grand panel de requêtes.
|
||||
|
||||
@@ -51,7 +51,7 @@ Pour accéder au fichier, il faut utiliser `static` comme pour le reste mais en
|
||||
Le bundler ne génère que des modules javascript.
|
||||
Ajouter `type="module"` n'est pas optionnel !
|
||||
|
||||
### Les imports au sein des fichiers des fichiers javascript bundlés
|
||||
### Les imports au sein des fichiers javascript bundlés
|
||||
|
||||
Pour importer au sein d'un fichier js bundlé, il faut préfixer ses imports de `#app:`.
|
||||
|
||||
|
||||
@@ -36,11 +36,4 @@ SITH_SUBSCRIPTIONS = {
|
||||
}
|
||||
```
|
||||
|
||||
Une fois ceci fait, il faut créer une nouvelle migration :
|
||||
|
||||
```bash
|
||||
python ./manage.py makemigrations subscription
|
||||
python ./manage.py migrate
|
||||
```
|
||||
|
||||
N'oubliez pas non plus les traductions (cf. [ici](./translation.md))
|
||||
Après ça, n'oubliez pas de gérer les traductions (cf. [ici](./translation.md))
|
||||
|
||||
@@ -157,16 +157,18 @@ que sont VsCode et Sublime Text.
|
||||
Si vous avez réussi à terminer l'installation, vous n'avez donc pas de configuration
|
||||
supplémentaire à effectuer.
|
||||
|
||||
Pour utiliser Biome, placez-vous à la racine du projet et lancer la commande suivante:
|
||||
Pour utiliser Biome, placez-vous à la racine du projet et lancez la commande suivante:
|
||||
|
||||
```bash
|
||||
npx @biomejs/biome check # Pour checker le code avec le linter et le formater
|
||||
npx @biomejs/biome check --write # Pour appliquer les changemnts
|
||||
npx @biomejs/biome check --write # Pour appliquer les changements
|
||||
```
|
||||
|
||||
Biome va alors faire son travail sur l'ensemble du projet puis vous dire
|
||||
si des documents ont été reformatés (si vous avez fait `npx @biomejs/biome format --write`)
|
||||
ou bien s'il y a des erreurs à réparer (si vous avez faire `npx @biomejs/biome lint`) ou les deux (si vous avez fait `npx @biomejs/biome check --write`).
|
||||
ou bien s'il y a des erreurs à réparer
|
||||
(si vous avez fait `npx @biomejs/biome lint`)
|
||||
ou les deux (si vous avez fait `npx @biomejs/biome check --write`).
|
||||
|
||||
Appeler Biome en ligne de commandes avant de pousser votre code sur Github
|
||||
est une technique qui marche très bien.
|
||||
|
||||
@@ -30,7 +30,7 @@ opérations, telles que la validation de formulaire.
|
||||
En effet, valider un formulaire demande beaucoup
|
||||
de travail de nettoyage des données et d'affichage
|
||||
des messages d'erreur appropriés.
|
||||
Or, tout ce travail existe déjà dans django.
|
||||
Or, tout ce travail existe déjà dans Django.
|
||||
|
||||
On veut donc, dans ces cas-là, ne pas demander
|
||||
toute une page HTML au serveur, mais uniquement
|
||||
@@ -84,7 +84,7 @@ Grâce à ça, on peut écrire des vues qui
|
||||
fonctionnent dans les deux contextes.
|
||||
|
||||
Par exemple, supposons que nous avons
|
||||
une `EditView` très simple, contenant
|
||||
une `UpdateView` très simple, contenant
|
||||
uniquement un formulaire.
|
||||
On peut écrire la vue et le template de la manière
|
||||
suivante :
|
||||
@@ -94,8 +94,10 @@ suivante :
|
||||
```python
|
||||
from django.views.generic import UpdateView
|
||||
|
||||
from core.views import AllowFragment
|
||||
|
||||
class FooUpdateView(UpdateView):
|
||||
|
||||
class FooUpdateView(AllowFragment, UpdateView):
|
||||
model = Foo
|
||||
fields = ["foo", "bar"]
|
||||
pk_url_kwarg = "foo_id"
|
||||
@@ -132,7 +134,7 @@ Dans ces situations, pouvoir décomposer une vue
|
||||
en plusieurs vues de fragment permet de ne plus
|
||||
raisonner en termes de condition, mais en termes
|
||||
de composition : on n'a pas un seul template
|
||||
qui peut changer les situations, on a plusieurs
|
||||
qui peut changer selon les situations, on a plusieurs
|
||||
templates que l'on injecte dans un template principal.
|
||||
|
||||
Supposons, par exemple, que nous n'avons plus un,
|
||||
@@ -238,10 +240,10 @@ qui se comportera alors comme une vue normale.
|
||||
|
||||
#### La méthode `as_fragment`
|
||||
|
||||
Il est à noter que l'instantiation d'un fragment
|
||||
Il est à noter que l'instanciation d'un fragment
|
||||
se fait en deux étapes :
|
||||
|
||||
- on commence par instantier la vue en tant que renderer.
|
||||
- on commence par instancier la vue en tant que renderer.
|
||||
- on appelle le renderer en lui-même
|
||||
|
||||
Ce qui donne la syntaxe `Fragment.as_fragment()()`.
|
||||
|
||||
@@ -76,7 +76,7 @@ cd /mnt/<la_lettre_du_disque>/vos/fichiers/comme/dhab
|
||||
```bash
|
||||
sudo pacman -Syu # on s'assure que les dépôts et le système sont à jour
|
||||
|
||||
sudo pacman -S uv gcc git gettext pkgconf npm redis
|
||||
sudo pacman -S uv gcc git gettext pkgconf npm valkey
|
||||
```
|
||||
|
||||
=== "macOS"
|
||||
|
||||
Reference in New Issue
Block a user