DjangoCMS, qui comme son nom l'indique est un CMS en Django, avec une capacité à utiliser des plugins tout faits ou à développer et dont l'édition des pages se fait en frontend avec une interface plutôt "Wysiwyg et drag & drop".
Tu peux l'installer toi même ou bien profiter de leur plateforme Aldryn sur leur serveur (avec tout plein d'options payantes évidemment).
C'est peut être un peu poussif parfois, mais globalement c'est fonctionnel et accessible (en terme d'utilisation).
De ce que je vois sur le site de Bootstrap: http://getbootstrap.com/getting-started/#download la version SASS qui est livré utilise Ruby pour te démarrer un projet Boostrap, mais dans les sources livrés il n'y a que des sources "partials" donc rien d'éligible à la compilation, j'imagine que leur script en Ruby doit te créer un fichier SASS éligible (genre un app.scss) qui importe leur librairie. Tu dois pouvoir créer ce fichier toi même qui contiendrait juste quelque chose comme:
@import "bootstrap";
Evidemment dans ta config Boussole, il faut lui configurer une entrée pour qu'il importe la libraire Bootstrap que tu aura incluse.
erreur sur >> @import "compass": oui c'est normal, vu que ça fait référence au "framework" SASS que Compass embarque, ce n'est pas explicité dans la documentation de Boussole par contre j'avais averti rapidement dans mon journal :) En règle général, beaucoup d'usage de la lib SASS de Compass sont pour avoir des vendor prefixes qui ne sont plus vraiment d'actualité, personnellement j'embarque la lib Bourbon pour remplacer les mixins que j'utilisais avec Compass avant;
Je n'ai jamais utilisé la lib SASS de Bootstrap mais il n'y a pas de raison que ça compile pas si y'a au moins un fichier SASS éligible (c'est à dire pas un "partial"), ça peut dépendre aussi de ta config boussole qui pointe pas sur le bon répertoire des sources;
Ben Mr.Bob ou cookiecutter c'est un peu pareil, il faut au préalable installer l'outil qui permet d'utiliser les templates.
Mais effectivement, tu es obligé de suivre les éventuelles mises à jour et les appliquer toi même, mais dans le cadre de sites vitrines qui ont un cycle de vie de quelques années, en général tu te positionnes sur un Django 'LTS'.
Par contre j'ai regardé un peu ton dépôt, je n'ai rien vu qui suggérait la possibilité qu'il permette d'être mis auto-magiquement à jour, j'imagine que tu te reposes sur l'utilisation de Git pour ça ? Mais dans la réalité c'est peut être un peu plus compliqué de gérer quelques lignes de conflits de merge à résoudre.
Pour le déploiement je me suis fourvoyé effectivement parce que j'intègre toujours un buildout dans mes templates de projets.
Bref en tout cas dans le cadre d'une webagency qui produit près d'une dizaine de projet toute les deux semaines, un outil comme Mr.bob ou cookiecutter est vraiment efficace en pratique, par exemple https://github.com/emencia/cookiecutter-djangocms3-buildout qui te produit rapidement un projet django-cms + foundation avec des possiblités d'options.
Cela te permet d'avoir un dépôt avec un gabarit de projet prêt à démarrer/déployer avec un minimum de choses à modifier à chaque fois. Et si tu veux automatiser encore plus le déploiement pour en faire le moins possible tu peux intégrer Buildout.
Je fais du Django depuis la 0.95, j'ai commencé avec Django principalement parce que les autres frameworks de l'époque ne me plaisaient pas, globalement je les trouvaient beaucoup plus compliqué à utiliser pour mettre en oeuvre des choses assez simples. L'API de Django me semblaient plus souple et plus "évidente".
Au fil du temps je n'ai pas vu grand chose de plus engageant chez les autres frameworks web Python, à part depuis 1 ou deux ans avec des projets comme Pyramid. Et puis la communauté et les applications Django ont tellement bien évolués que je trouve peu d'intérêts à passer à un autre framework web Python.
J'ai fait pas mal de sites "vitrines", mais aussi des grosses usines à gaz comme une plateforme de médias, un site communautaire-social-machin, une plateforme de dossiers de financements, etc.. Et j'ai eu peu de gros soucis techniques sur lesquels me prendre la tête, à part le fameux modèle utilisateur et profile, ainsi qu'un truc plus pointu avec les uploads de très très gros fichiers. Bref au final, j'ai rarement eu à me prendre la tête à savoir si je pourrais faire telle ou telle chose avec Django, uniquement le "plaisir" de le modéliser.
Pour ce qui est du côté portable de ce que produit son ORM, je suis toujours parti du principe "d'embrasser" le principe de l'ORM au maximum, pour les scripts CRON tu peux facilement leur faire accéder à l'API et ton environnement Django. Je me doute que c'est pas aussi léger que certains pourrait le souhaiter, pour des modèles de données relativement simples tu peux facilement les porter pour SQLAlchemy, ensuite pour des choses plus évolués c'est évidemment moins simples.
Est-ce que vous codez du SQL en dur si vous en avez besoin ?
Je faisais ça dans certains cas jusque dans la version 1.1 où l'ORM s'est vachement arrangé, ensuite j'ai totalement abandonné le principe, c'est trop lourd à maintenir je trouve.
Est-ce que tout tourne sur un serveur web - quel genre d'infra vous utilisez ?
Depuis 2/3 ans je crois qu'il doit y avoir vraiment très peu de services que tu ne puisses pas monter avec Django. Personellement j'aime bien la simplicité de monter sa webapp avec Apache+fcgi, mais dans ma boîte c'est que du nginx et c'est très satisfaisant, j'ai pas connaissances de crash ou de gros problèmes de charges anormales.
Ah oui je me suis mal relu, je me suis trompé sur Il n'y a pas de réelle validation dans les formulaires sinon ceux des champs de ton modèle je voulais parler de la validation dans les modèles.
Mais quand il t'arrive d'avoir besoin de forcer une validation au niveau du modèle je produis un dérivé d'un champ de base (si je ne l'ai pas déjà dans une librairie tierce) que j'utilise directement dans le modèle, tu peux y redéfinir la validation du champ, son Widget par défaut, etc.. une fois implémenté au niveau du modèle en général tu n'a pas besoin de le remonter dans les formulaires de tes vues. Ce n'est pas ce que tu veux ?
Je veux faire une validation au niveau d'un champ de formulaire en fonction de l'utilisateur identifié […]
Je pense que ton soucis de passer le request.user en argument à ton contrôleur de formulaire avec les vues génériques doit pouvoir être simplifié avec l'arrivée des Class Based Views, qui te permettent d'étendre facilement les vues génériques une fois pour toute dans ton projet ou une librairie et ensuite les utiliser directement sans avoir à redéfinir des méthodes et hack un peu partout.
Et c'est plus pour l'aspect cosmétique mais l'utilisation des formulaires devient encore plus sympa avec l'utilisation de django-crispy-forms, ça forme directement un joli layout de ton formulaire, layout que tu peux customiser facilement, voir réutiliser dans tes autres formulaires, et qui permet de plus avoir à gérer champ par champ toute les variations d'aspect que tu peux avoir parfois.
Les validations dans les formulaires peuvent être différentes de celles dans les modèles, et c'est trop souvent le cas […]
Il n'y a pas de réelle validation dans les formulaires sinon ceux des champs de ton modèle, mais c'est plutôt de la validation de type, pas de logique de ton formulaire. Si tu a de la validation à faire lors de l'enregistrement d'une entrée au niveau de l'API, le plus souple est de le faire dans un manager où tu peux lever des exceptions cohérentes si besoin. Puis si besoin tu peux même le lier après au ModelAdmin de ton modèle pour que ça fonctionne aussi dans l'administration de Django.
Mais devant la loooooongue attente pour résoudre ces problèmes, et voyant que Django 1.4 n'allait rien arranger […]
Les releases de Django essayent en général de temporiser entre les gros changements ou ajouts, la 1.3 c'était l'arrivée Class Based Views, la 1.4 laisse un peu le temps aux développeurs pour les implémenter vu que les function views seront deprecated à partir de la 1.5.
C'était probablement au temps de Django 0.9.x, car de la version 1.0 à la 1.1 il y a eu un énorme boulot pour nettoyer toute la magie, il n'y en a plus vraiment maintenant parce que le peu qu'il doit rester est largement documenté dans ses comportements.
Je cherche en ce moment une "linux-box" fanless qui pourrait faire office de console de salon dédié à l'émulation (essentiellement les 8/16 bits de sega/nintendo) et je me demandais si un linutop4 aurait les capacités pour me le permettre ?
J'ai comme référence la Caanoo qui émule parfaitement jusqu'à la PS1.
Vous pourriez aussi utiliser haXe comme base de développement, ce dernier permettant une compilation vers de multiples plateformes cibles tel que Flash, Javascript, etc..
À savoir que haXe a été développé par le créateur de mxmlc pour se dédouaner d'ActionScript vers un language plus typé. Et c'est un language assez proche de ActionScript dans sa syntaxe, le portage d'applications ActionScript est d'autant plus simple.
# DjangoCMS
Posté par David Thenon (site web personnel) . En réponse au journal Site web : Wysiwyg et drag & drop. Évalué à 2.
DjangoCMS, qui comme son nom l'indique est un CMS en Django, avec une capacité à utiliser des plugins tout faits ou à développer et dont l'édition des pages se fait en frontend avec une interface plutôt "Wysiwyg et drag & drop".
Tu peux l'installer toi même ou bien profiter de leur plateforme Aldryn sur leur serveur (avec tout plein d'options payantes évidemment).
C'est peut être un peu poussif parfois, mais globalement c'est fonctionnel et accessible (en terme d'utilisation).
[^] # Re: Un petit retour de test
Posté par David Thenon (site web personnel) . En réponse au journal Boussole, une interface de compilation pour libsass-python. Évalué à 0.
De ce que je vois sur le site de Bootstrap: http://getbootstrap.com/getting-started/#download la version SASS qui est livré utilise Ruby pour te démarrer un projet Boostrap, mais dans les sources livrés il n'y a que des sources "partials" donc rien d'éligible à la compilation, j'imagine que leur script en Ruby doit te créer un fichier SASS éligible (genre un
app.scss) qui importe leur librairie. Tu dois pouvoir créer ce fichier toi même qui contiendrait juste quelque chose comme:@import "bootstrap";
Evidemment dans ta config Boussole, il faut lui configurer une entrée pour qu'il importe la libraire Bootstrap que tu aura incluse.
[^] # Re: Un petit retour de test
Posté par David Thenon (site web personnel) . En réponse au journal Boussole, une interface de compilation pour libsass-python. Évalué à 1.
Salut,
erreur sur >> @import "compass": oui c'est normal, vu que ça fait référence au "framework" SASS que Compass embarque, ce n'est pas explicité dans la documentation de Boussole par contre j'avais averti rapidement dans mon journal :) En règle général, beaucoup d'usage de la lib SASS de Compass sont pour avoir des vendor prefixes qui ne sont plus vraiment d'actualité, personnellement j'embarque la lib Bourbon pour remplacer les mixins que j'utilisais avec Compass avant;Je n'ai jamais utilisé la lib SASS de Bootstrap mais il n'y a pas de raison que ça compile pas si y'a au moins un fichier SASS éligible (c'est à dire pas un "partial"), ça peut dépendre aussi de ta config boussole qui pointe pas sur le bon répertoire des sources;
[^] # Re: Gabarits de démarrage/déploiement de projet
Posté par David Thenon (site web personnel) . En réponse au journal DjangoFloor. Évalué à 0.
Et pourquoi tu n'a pas essayé d'intégrer django-configurations ?
[^] # Re: Gabarits de démarrage/déploiement de projet
Posté par David Thenon (site web personnel) . En réponse au journal DjangoFloor. Évalué à 1.
Ben Mr.Bob ou cookiecutter c'est un peu pareil, il faut au préalable installer l'outil qui permet d'utiliser les templates.
Mais effectivement, tu es obligé de suivre les éventuelles mises à jour et les appliquer toi même, mais dans le cadre de sites vitrines qui ont un cycle de vie de quelques années, en général tu te positionnes sur un Django 'LTS'.
Par contre j'ai regardé un peu ton dépôt, je n'ai rien vu qui suggérait la possibilité qu'il permette d'être mis auto-magiquement à jour, j'imagine que tu te reposes sur l'utilisation de Git pour ça ? Mais dans la réalité c'est peut être un peu plus compliqué de gérer quelques lignes de conflits de merge à résoudre.
Pour le déploiement je me suis fourvoyé effectivement parce que j'intègre toujours un buildout dans mes templates de projets.
Bref en tout cas dans le cadre d'une webagency qui produit près d'une dizaine de projet toute les deux semaines, un outil comme Mr.bob ou cookiecutter est vraiment efficace en pratique, par exemple https://github.com/emencia/cookiecutter-djangocms3-buildout qui te produit rapidement un projet django-cms + foundation avec des possiblités d'options.
# Gabarits de démarrage/déploiement de projet
Posté par David Thenon (site web personnel) . En réponse au journal DjangoFloor. Évalué à 1.
Alors pour rester dans la modernité, maintenant on a des outils de démarrage/déploiement de projets tel que :
Cela te permet d'avoir un dépôt avec un gabarit de projet prêt à démarrer/déployer avec un minimum de choses à modifier à chaque fois. Et si tu veux automatiser encore plus le déploiement pour en faire le moins possible tu peux intégrer Buildout.
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par David Thenon (site web personnel) . En réponse à la dépêche Retour sur Django 1.5. Évalué à 3.
Je fais du Django depuis la 0.95, j'ai commencé avec Django principalement parce que les autres frameworks de l'époque ne me plaisaient pas, globalement je les trouvaient beaucoup plus compliqué à utiliser pour mettre en oeuvre des choses assez simples. L'API de Django me semblaient plus souple et plus "évidente".
Au fil du temps je n'ai pas vu grand chose de plus engageant chez les autres frameworks web Python, à part depuis 1 ou deux ans avec des projets comme Pyramid. Et puis la communauté et les applications Django ont tellement bien évolués que je trouve peu d'intérêts à passer à un autre framework web Python.
J'ai fait pas mal de sites "vitrines", mais aussi des grosses usines à gaz comme une plateforme de médias, un site communautaire-social-machin, une plateforme de dossiers de financements, etc.. Et j'ai eu peu de gros soucis techniques sur lesquels me prendre la tête, à part le fameux modèle utilisateur et profile, ainsi qu'un truc plus pointu avec les uploads de très très gros fichiers. Bref au final, j'ai rarement eu à me prendre la tête à savoir si je pourrais faire telle ou telle chose avec Django, uniquement le "plaisir" de le modéliser.
Pour ce qui est du côté portable de ce que produit son ORM, je suis toujours parti du principe "d'embrasser" le principe de l'ORM au maximum, pour les scripts CRON tu peux facilement leur faire accéder à l'API et ton environnement Django. Je me doute que c'est pas aussi léger que certains pourrait le souhaiter, pour des modèles de données relativement simples tu peux facilement les porter pour SQLAlchemy, ensuite pour des choses plus évolués c'est évidemment moins simples.
Je faisais ça dans certains cas jusque dans la version 1.1 où l'ORM s'est vachement arrangé, ensuite j'ai totalement abandonné le principe, c'est trop lourd à maintenir je trouve.
Depuis 2/3 ans je crois qu'il doit y avoir vraiment très peu de services que tu ne puisses pas monter avec Django. Personellement j'aime bien la simplicité de monter sa webapp avec Apache+fcgi, mais dans ma boîte c'est que du nginx et c'est très satisfaisant, j'ai pas connaissances de crash ou de gros problèmes de charges anormales.
[^] # Re: Mangez-en, c'est bon !
Posté par David Thenon (site web personnel) . En réponse à la dépêche Sortie de Django 1.4. Évalué à 1.
Ah oui je me suis mal relu, je me suis trompé sur Il n'y a pas de réelle validation dans les formulaires sinon ceux des champs de ton modèle je voulais parler de la validation dans les modèles.
Mais quand il t'arrive d'avoir besoin de forcer une validation au niveau du modèle je produis un dérivé d'un champ de base (si je ne l'ai pas déjà dans une librairie tierce) que j'utilise directement dans le modèle, tu peux y redéfinir la validation du champ, son Widget par défaut, etc.. une fois implémenté au niveau du modèle en général tu n'a pas besoin de le remonter dans les formulaires de tes vues. Ce n'est pas ce que tu veux ?
[^] # Re: Mangez-en, c'est bon !
Posté par David Thenon (site web personnel) . En réponse à la dépêche Sortie de Django 1.4. Évalué à 3.
Je pense que ton soucis de passer le
request.useren argument à ton contrôleur de formulaire avec les vues génériques doit pouvoir être simplifié avec l'arrivée des Class Based Views, qui te permettent d'étendre facilement les vues génériques une fois pour toute dans ton projet ou une librairie et ensuite les utiliser directement sans avoir à redéfinir des méthodes et hack un peu partout.Et c'est plus pour l'aspect cosmétique mais l'utilisation des formulaires devient encore plus sympa avec l'utilisation de django-crispy-forms, ça forme directement un joli layout de ton formulaire, layout que tu peux customiser facilement, voir réutiliser dans tes autres formulaires, et qui permet de plus avoir à gérer champ par champ toute les variations d'aspect que tu peux avoir parfois.
Il n'y a pas de réelle validation dans les formulaires sinon ceux des champs de ton modèle, mais c'est plutôt de la validation de type, pas de logique de ton formulaire. Si tu a de la validation à faire lors de l'enregistrement d'une entrée au niveau de l'API, le plus souple est de le faire dans un manager où tu peux lever des exceptions cohérentes si besoin. Puis si besoin tu peux même le lier après au ModelAdmin de ton modèle pour que ça fonctionne aussi dans l'administration de Django.
Les releases de Django essayent en général de temporiser entre les gros changements ou ajouts, la 1.3 c'était l'arrivée Class Based Views, la 1.4 laisse un peu le temps aux développeurs pour les implémenter vu que les function views seront deprecated à partir de la 1.5.
[^] # Re: Explicit is better than implicit
Posté par David Thenon (site web personnel) . En réponse à la dépêche Sortie de Django 1.4. Évalué à 3.
C'était probablement au temps de Django 0.9.x, car de la version 1.0 à la 1.1 il y a eu un énorme boulot pour nettoyer toute la magie, il n'y en a plus vraiment maintenant parce que le peu qu'il doit rester est largement documenté dans ses comportements.
# Utilisation en "console de salon" ?
Posté par David Thenon (site web personnel) . En réponse à la dépêche Nouveau Linutop OS basé sous Ubuntu Lucid. Évalué à 2.
Je cherche en ce moment une "linux-box" fanless qui pourrait faire office de console de salon dédié à l'émulation (essentiellement les 8/16 bits de sega/nintendo) et je me demandais si un linutop4 aurait les capacités pour me le permettre ?
J'ai comme référence la Caanoo qui émule parfaitement jusqu'à la PS1.
[^] # Re: Flash
Posté par David Thenon (site web personnel) . En réponse à la dépêche « Images Actives » un logiciel pour des images interactives. Évalué à 1.
Vous pourriez aussi utiliser haXe comme base de développement, ce dernier permettant une compilation vers de multiples plateformes cibles tel que Flash, Javascript, etc..
À savoir que haXe a été développé par le créateur de mxmlc pour se dédouaner d'ActionScript vers un language plus typé. Et c'est un language assez proche de ActionScript dans sa syntaxe, le portage d'applications ActionScript est d'autant plus simple.