Damien Szczyt a écrit 38 commentaires

The closing ?> tag MUST be omitted from files containing only PHP.

je trouve ça totalement incroyable de promouvoir de telles choses !!! Et on appelle ça des bonnes pratiques … on ne doit pas avoir les mêmes!

C'est certainement pour éviter les caractères morts en fin de fichiers, qu'on pourrait retrouver un peu partout sur la page générée. Mais c'est évident que c'est ignoble ! PHP, quoi…

Parce qu'en faisant ça, tu lances 2 fois la commande save() sur ton objet : une fois avec obj.save() et une fois avec super(…).form_valid(form). Ce n'est pas optimal, et donc pas acceptable pour un usage intensif.

Ce système de formulaires doit être très bien pour l'aspect cosmétique, ou l'écriture du code HTML. Je ne vois rien (je ne connais pas bien ce projet, je me trompe peut-être) pour résoudre la problématique des formsets, et encore moins l'idée des formulaires imbriqués.

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 […]

Oui, mais ça ne résout absolument pas le problème des validations, elles auraient besoin du request quand même ! Et les avoir dans le init empêche l'écriture correcte des validations, sauf si on met l'objet request dans l'instance de l'objet. Je trouve pas ça top.

Et c'est plus pour l'aspect cosmétique

Rien à dire au niveau de l'écriture des templates, tout est faisable, sauf dans des cas particuliers où l'écriture d'un tag ou d'un filtre peut s'avérer… fastidieuse (ex : j'ai prévu une méthode dans mon objet pour faire de l'affichage. Cette méthode prend un paramètre : l'utilisateur actuellement identifié. Je ne peux pas l'appeler directement, je dois exécuter cette méthode pour le passer dans le contexte au niveau de la vue, ce qui n'est pas faisable dans le cas de l'affichage d'une liste d'objets, donc je dois écrire un tag…)

Il n'y a pas de réelle validation dans les formulaires sinon ceux des champs de ton modèle

Pas d'accord : il y a toute une page sur la validation des champs de formulaire… D'ailleurs, tous les champs de formulaire ne sont pas nécessairement associés à un champ de modèle. Et justement, cette validation fait double emploi, à mon sens, avec les validateurs qui, eux, agissent au niveau du modèle.

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.

Et alors ? Le temps n'a rien à voir avec le numéro de version. Je trouve leur timeline mal fichue, et des fonctionnalités (je veux dire des outils qui apportent un réel plus au développeur, comme des travaux sur les formulaires) se font, à mon sens, attendre. Je parle par exemple d'outils pour une meilleure gestion des fichiers statiques (pour faire du less, ou pour compresser le JS, ou encore créer automatiquement des sprites), ou bien un outil intégré pour faire les migrations, … Alors oui, on va me dire qu'il existe des outils externes (j'en utilise plein), mais j'ose la comparaison avec rails (que je ne maîtrise absolument pas pour l'instant, je suis encore en phase de découverte du produit) et quel bonheur de se retrouver avec plein d'outils qui simplifient la vie dès le début du projet !
Je crois que je pourrais encore bcp critiquer Django, et pourtant je l'utilise tous les jours pour un projet relativement vaste. Ça me fait mal de dénigrer ce projet, car Django m'a sauvé la vie plus d'une fois et m'a fait apprécier le développement web. La version 1.4 m'a déçu parce qu'elle a été longue à arriver pour aucune nouveauté apparente. Dire que ZE big news est la gestion des dates après 1 an de développement, je reste un peu sur ma faim…

J'ai beaucoup travaillé avec Django, et ce depuis la version 0.91. C'est un framework formidable. Le seul défaut que je lui trouve se situe au niveau des formulaires. Cette version 1.4 arrive bien longtemps après la version 1.3, et elle n'apporte pas de grosses nouveautés. La seule chose intéressante que je trouve dans le changelog est le prefetch_related, qui remplace le select_related, qui peut améliorer beaucoup de choses au niveau des performances SQL. LA grosse nouveauté étant un meilleur support des fuseaux horaires \o/ Bref, j'attendais beaucoup au niveau des formulaires, et y'a pas ce que je veux… Je m'explique :

• Je veux faire une validation au niveau d'un champ de formulaire en fonction de l'utilisateur identifié. Pour cela, il me faut accéder au request.user dans l'objet Form. Et là, pas possible directement ! Je dois redéfinir la méthode init avec un nouveau paramètre request, ce qui rend l'instanciation incompatible avec les vues génériques. Le moyen le plus pratique que j'ai trouvé est de déclarer la classe dans une méthode qui prend en paramètre ce paramètre request, ce qui me donne très peu de code à réécrire au niveau de la vue. Mais niveau performance, ce n'est pas bon du tout, sans parler de l'élégance ! Je me retrouve avec quasiment chacun de mes formulaires encapsulés dans une méthode.
• Les Formsets sont lourds à implémenter quand on veut faire quelque chose d'un peu plus poussé qu'une simple liste de formulaires. Par exemple, pour des formulaires imbriqués. J'ai développé un petit outil pour simplifier la chose.
• Les Formsets (encore eux) ne sont pas fiables (en tous cas pour la version 1.3). Un simple exemple dans une page d'admin de django, en activant l'édition inline dans les listes, en modifiant le code html du management_form à la main avant soumission (en augmentant le champ INITIAL_FORMS), on se retrouve avec une jolie erreur 500. Je vais tester avec django 1.4, mais je me pose de plus en plus de questions sur la fiabilité de la mise en production des formulaires tels qu'ils sont implémentés dans django.
• Les validations dans les formulaires peuvent être différentes de celles dans les modèles, et c'est trop souvent le cas. C'est un désastre pour la cohérence de la base de données quand on utilise le shell python pour manipuler les objets, même si ça peut apporter un intérêt dans certains cas.
• Je n'aimais pas rails à ses débuts, c'est pour ça que j'avais choisi django à cette époque. Mais devant la loooooongue attente pour résoudre ces problèmes, et voyant que django 1.4 n'allait rien arranger, je me suis penché sur la version 3.1 de rails, qui supporte les nested forms (depuis la version 3), qui me permet d'assigner le propriétaire lors de la création d'un objet dans un formulaire automatiquement, … Et il n'y a pas cette notion de formulaire, entre le contrôleur et la vue, chose qui me pose problème dans django, justement !!! Alors, non, je dis Django n'est pas un framework MTV, mais un framework MTFV (Modèle Template Formulaire View, ou VTFM, vas te fa… mett.. si tu veux qqch de plus avancé…), tant cette notion de formulaire est importante et contraignante dans django !

Avez-vous déjà eu ce genre de problèmes ? Avez-vous des réponses à m'apporter ? Est-ce que django n'est pas adapté à ce que je voudrais en faire ?

Il existe des outils tout faits pour générer les graphes des modèles. En particulier dans Django Command Extensions : http://code.google.com/p/django-command-extensions/ . Il suffit de récupérer le svn, de le déclarer dans le settings.py et de taper ./manage.py graph_models [modèles], comme indiqué dans l'aide, ça génère un magnifique .dot à convertir en png, par exemple.

Maintenant que c'est fait, le carbone contenu dans le papier sera toujours ça en moins dans l'athmosphère... Voilà une bonne raison pour ne pas le brûler.

Ils s'occupent de corriger leur blob foireux en 2D, qui ne supportent pas EXA... (et donc kde4 est inaccessible aux possesseurs de cartes NVidia). Cette exprérience va peut-être leur permettre de se rendre compte que ce qui leur coûterait le moins cher serait de libérer les sources, permettant à la communauté d'y ajouter son grain de sel ?

le VLC nouveau sortira avec une interface qt4 : http://www.videolan.org/vlc/features.html . La dépendance Qt4 est déjà ajoutée... Et phonon est un projet inclu dans Qt4, et non KDE.

"We lost a few minutes of telemetry when the windows printer driver crashed, taking down the ground software."
Oui oui impressionnant....

hotmail ? :p

C'est même le principe de base d'internet, cf cette vidéo : http://www.fdn.fr/minitel.avi pour plus d'explications. Enfin, un petit groupe d'irréductibles petits hébergeurs résistent, et sont, pour la plupart, membres du RHIEN : http://www.rhien.org .
Quelques exemples :
http://www.e-ghosting.com
http://www.chezmeme.net
http://www.freezee.org

si !

Hélas, mon père doit faire ses évalucations CE1, le logiciel de saisie des résultats est propriétaire, livré sous forme d'exécutable windows. Lui qui est si content de sa distribution, il va être obligé de le quitter. Mais avant, on va tester une émulation du logiciel avec wine, ce qui n'est pas une solution à mon avis, juste une roue de secours à moitié crevée... Le pire dans tout ça est que le format de fichiers à envoyer à l'inspection est du xls. Avec la récente normalisation de l'OpenDocument, j'appelle ça de la moquerie.

Selon http://nouveau.freedesktop.org/wiki/Nouveau_Companion_24-fr :

Darktama n'a pas chômé lui non plus : il a fusionné les branches nv50 et randr-1.2 dans le dépôt git du DDX, et donc il n'a plus besoin de synchroniser son code sur 2 branches (randr-1.2 et master). Ainsi, si vous voulez tester avec une carte NV5x/G8x, utilisez la branche randr-1.2, nv50 est obsolète.

Donc c'est déjà fait !!!

"Même si les logiciels concurrents parviennent à implémenter le format Open XML ils ne pourront lire les documents exigeants une clé de libération et les utilisateurs continueront donc à utiliser les produits Microsoft. Le plus beau c'est évidemment que même la simple tentative de retrouver les clés est dorénavant interdite par la loi !"
Le problème n'est pas l'open-xml en lui-même, mais ce qu'il y a autour. Je ne pense pas que microsoft se soit donné la peine d'investir dans un nouveau format semblable à celui qui est libre sans avoir une idée qui leur permette de continuer à gagner des $$$.

Je ne connaissais pas, mais déjà plus exploitable que le combo HTML/CSS/ECMA ! Très joli web desktop. Rapide, etc etc. Je trouve ça bien plus réussi que YouOS ou EyeOS !

Quand je disais de "matériel", je parlais du processeur (c'est lui qui gère, la plupart du temps, les processus/threads), la mémoire (à priori, les accès la la ram se font au niveau matériel également), la gestion des disques, ou autres. L'intérêt d'un OS, c'est de faire l'interface entre l'utilisateur et le matériel. Je ne vois aucune possibilité de gérer mon matériel, ou celui du serveur, ou bien les droits de mes données par l'intermédiaire de ce desktop. C'est vrai que je ne l'ai pas exploré à fond, donc si quelqu'un a trouvé, je suis curieux de voir. De toutes façons, il n'y a aucun moyen de gérer le matériel du client, et donc ça n'est pas prêt d'être quelque chose d'intallé seul sur ma machine (sauf si un jour, quelqu'un sort un processeur qui sait interpréter l'ecmascript au niveau hard).

Tu peux voir les processus dans une appli KDE... Or, les processus ne sont pas gérés par KDE ! Il semblerait que ça soit la même chose pour YouOS. La gestion de la mémoire ne se fait pas par YouOS non plus : c'est le serveur web qui s'en occupe par l'intermédiaire des bibliothèques fournies par le système d'exploitation hôte. Pour le système de fichiers, il faut voir à quoi correspond YouFS : est-ce implémenté au niveau de l'OS hôte (ex : driver linux) ? Idem pour les droits, c'est d'ailleurs très proche du système de fichiers pour l'accès aux données.

Ceci dit, tu as parfaitement raison : c'est intéressant de voir que c'est possible, c'est une très bonne démo (qui a déjà été lancée par EyeOS, d'ailleurs évoqué dans cette même page), mais ça reste inexploitable dans cet état.

Il y a pas si longtemps, il fallait éviter le JS dans nos applis web pour améliorer, entr'autres, l'accessibilité de nos chères pages web. Aujourd'hui, 2 news sur des applis JS dans LinuxFR... Les temps changent ! Certains qui critiquaient le langage se trouve même une excuse en disant que ce n'est pas du javascript, mais de l'ECMAScript. Je suis d'accord qu'il faille évoluer dans nos pensées, mais quand je pense qu'il a fallu qu'on nomme cette méthode de programmation du JS comme la marque du nettoyant pour sols que vous aurez tous reconnu pour qu'on le présente d'une manière positive, je trouve ça un peu dommage. Maintenant que tout le monde connaît ce nom, on l'utilise à toutes les sauces, même quand on en a pas besoin... c'est dommage également.

Ceci dit, j'ai testé cet "OS" (sous firefox 1.5.0.4) : c'est lent, ça buggue pas mal, c pas du tout exploitable pour le grand public. Je trouve que ceci est plus une démonstration des possibilités offertes par le langage qu'autre chose...
Le problème également est que les fichiers enregistrés dans cette application sont "perdus" quand on quitte le navigateur. Le jour où on a plus d'accès au net (je sais que dans le futur, on planifine l'accès à internet partout, sans fil, à haut débit, mais quand même), comment on fait pour lire son document ? Et puis le système de serveur/terminaux a été plus ou moins abandonné, du moins pour le grand public, au profit du stockage local, il semblerait qu'il y ait une raison ! L'idéal serait, je pense, de stocker à la fois sur le serveur et sur le disque local.

En revanche, cet exemple démontre parfaitement le besoin de plus en plus prononcé par les utilisateurs pour avoir un desktop orienté web. A la vue de cette application, on peut penser qu'on atteint les limites du HTML, et qu'il est trop fastidieux de développer quelque chose de compatible avec tous les interpréteurs, je parle ici des différents navigateurs. La raison me semble simple : il y a trop de langages (HTML, javascript, CSS) qui peuvent se mélanger de partout, et surtout qui ont des syntaxes complexes.
Au final, est-ce que le navigateur web est le meilleur exemple pour développer un desktop manager ? Ne serait-il pas temps de développer d'autres technologies permettant de réaliser ces mêmes tâches de manière plus efficace ? Imaginez qu'on fasse la même chose avec l'interpréteur basic de Ms Word ou encore de OOo.

Je pense également que nommer ce genre d'utilitaires "un système d'exploitation" est faux, il s'agirait juste un desktop manager, dans la mesure où ça ne gère pas le matériel. On dirait ici que KDE ou Gnome est un OS, et on se ferait flinguer...

Autre chose : en quoi consiste YouFS ? Pourquoi avoir développé un nouveau système de fichiers ?

Bien entendu ! Les femmes qui disent qu'elles vous aiment mentent !
Tout ce qui les intéresse, c'est le saiske...
En plus, on leur file 500¤ pour les voir rajouter des coeu-coeurs roses par défaut sur votre desktop gnome ! Bouargh !!!

Bon, va falloir faire travailler ma copine : 500¤, c'est pas rien ! Pour une fois qu'elle servirait à autre chose qu'à faire du ménage...

Bravo GNOME ! Excellente initiative !

je disais "joli" et "original" par rapport à d'autres jeux libres : il n'y en a pas beaucoup à part des solitaires, ... (je n'ai pas dit qu'il n'y en a pas, mais il y en a trop peu).

Je testerai peut-être prochainement cette lib avec SWIG. Je passerai vous voir pour avoir un peu d'aide.

En même temps, c'est une clio dans le jeu, ça correspond bien !

Est-ce que un portage de la bibliothèque raydium pour la langage python est envisagé ?

Le frein à main dans le jeu est-il prévu ? Un petit dérapage dans les virages, ça simplifierait les niveaux :)

Je termine en félicitant l'équipe qui a développé ce jeu génial ! Ca me fait penser à Stunts Cars, à l'époque, mais en beaucoup plus joli ! A quand la F1 sur ces circuits ? ;)

!!! Merci !!! de développer des jeux libres jolis, jouables, originaux, avec de la bonne musique, ... et simples à lancer !

http://www.freezee.org l'a fait !!!

Il y a ubuntu, qui justement, vient de sortir en version 5.10. Car quand même, il ne se passe plus un seul forum libre sans que j'entende parler de cette distribution qui a, amha, dépassé largement mandriva et debian pour une utilisation grand public. Avec la version serveur qui va débarquer prochainement, je crains un immense raz-de-marée de la même intensité que la version desktop !!!
Cette réaction de microsoft sonne comme une jalousie de cette réussite africaine... Ou une crainte de voir une partie de son marché s'évaporer ?

Non, mais avec hotwayd, on peut facilement récupérer ses mails sur hotmail sur un compte pop ;) (Peut-être vais-je proposer ce service sur Freezee bientôt). Ensuite, il suffit d'envoyer un e-mail avec ta nouvelle adresse, et pour te répondre, le correspondant clique sur répondre, et hop, il a ta nouvelle adresse... Magique !