Il s’avère que Django a une particularité. Il optimise les fichiers statiques (JS, CSS, HTML, images?) avec un outil écrit en java. Il faut java pour faire tourner une application Django avec de bonne performances.
Cette dépendance n'est pas intrinsèque à Django, mais à CremeCRM. Pour info, nous utilisions une app externe 'mediagenerator' bien avant que Django ait sa gestion actuelle des assets, mais comme sont développement a été stoppée (elle n'est plus compatible depuis longtemps avec les versions récentes de Django) j'ai intégré cette app à notre code, j'ai enlevé la plupart des trucs inutiles pour nous, et porté vers les versions récentes de Django puis Python 3.
Il est tout à fait possible de se passer de Java avec la bonne configuration, mais le JS et le CSS ne sont alors plus minifiés.
Et oui les images subissent un traitement: les assets finaux sont renommés et contiennent un hash dans leur nom (le nom change donc si ont modifie l'image), ce qui permet de dire au navigateur de garder les images en cache aussi longtemps que possible.
Quand j'aurai le temps (spoileur: pas une priorité du tout) je regarderai si les minifieurs JS/CSS écrits en Python donnent de bons résultats histoire de pouvoir enlever Java des dépendances de base.
Il s’avère que Django a une deuxième particularité. Il dépend de Pillow, une bibliothèque logicielle de manipulation d’images. Et Pillow doit se compiler sur la machine lors de son installation.
Il s'agit là encore d'une dépendance de Creme, pas de Django. On s'en sert de manière très légère certes, mais si on s'en sert (cherche des from PIL).
J'espère que CremeCRM vous satisfera (même si effectivement on ne conseille pas spécialement SQLite pour autre chose que le développement, voire une utilisation locale mono-utilisateur).
# Quelques précisions
Posté par GuieA_7 (site web personnel) . En réponse au journal Ça passe crème. Évalué à 10.
[je suis le développeur principal de CremeCRM]
Bonsoir,
Cette dépendance n'est pas intrinsèque à Django, mais à CremeCRM. Pour info, nous utilisions une app externe 'mediagenerator' bien avant que Django ait sa gestion actuelle des assets, mais comme sont développement a été stoppée (elle n'est plus compatible depuis longtemps avec les versions récentes de Django) j'ai intégré cette app à notre code, j'ai enlevé la plupart des trucs inutiles pour nous, et porté vers les versions récentes de Django puis Python 3.
Il est tout à fait possible de se passer de Java avec la bonne configuration, mais le JS et le CSS ne sont alors plus minifiés.
Et oui les images subissent un traitement: les assets finaux sont renommés et contiennent un hash dans leur nom (le nom change donc si ont modifie l'image), ce qui permet de dire au navigateur de garder les images en cache aussi longtemps que possible.
Quand j'aurai le temps (spoileur: pas une priorité du tout) je regarderai si les minifieurs JS/CSS écrits en Python donnent de bons résultats histoire de pouvoir enlever Java des dépendances de base.
Il s'agit là encore d'une dépendance de Creme, pas de Django. On s'en sert de manière très légère certes, mais si on s'en sert (cherche des
from PIL).J'espère que CremeCRM vous satisfera (même si effectivement on ne conseille pas spécialement SQLite pour autre chose que le développement, voire une utilisation locale mono-utilisateur).