Reprise du message précédent :

 
J'allais me moquer du nerd de l'annee qui s'etonne qu'un jeu sorti en 2004 tourne bien sur son pc et la j'ai clique sur son profil materiel

je te suggère de re-vérifier plusieurs fois le système de tranches de l'IR, t'as du louper un truc

you've been pwnd

(et la partie sur ma config était bien sûr une plaisanterie légère)

 
oranger  

ZOMG

bon je crois que je suis en train de remettre en cause le fondement de mon framework là
 
Je fais pas avancer très fort le milieu sportif mais je crois que le design en java ça va bouger
 
C'est dommage de mourir de faim avec des idées aussi pures

Si tu fais bouger les frameworks java, il serait possible que tu crées un composant style newforms de django
 
Non parce que la gestion des forms à la mano PHP-style ça va bien 30 secondes.

Faudrait voir à pas ternir l'image des patrons de france

je viens de regarder vite fait, y'a un objet qui représente les données du form c'est ça ?
y'a un truc comme ça dans struts2, je déclare des propriétés sur l'action et elles sont appelées en lecture ou en écriture par le bouzin toutes seules.

Après un coup d'oeil rapide, newforms ça a l'air assez proche du système de gestion de formulaires proposé par symfony 1.1, qui est en PHP

vous êtes morts les cons ?
 
'tain je me rends compte que dans Struts2/Spring et leurs amis, tout passe par des hashmaps dans tous les sens. En fait je comprends mieux cette histoire de combat java/Ruby, parce que quitte à tout foutre dans des paires clef/valeurs où les clef sont des Strings, alors autant virer tous les types et faire directement du ruby. Surtout que tes perfs liés à la JVM dans se contexte, tu te touches avec.

Tu va décider de reswaper vers ruby ou tu acceptes calmement les défauts de java pour pouvoir avancer ?

non, j'vais rester en java. En fait j'ai légèrement du mal à prendre un certain nombre d'arguments des gens de ruby. Je faisais du smalltalk bien longtemps avant que la plupart des bloggeurs ne découvrent Ruby et je suis légèrement revenu des trucs non structurés.

 
60 ans. Alcoolisme et mauvaise santé + refus total de toute activité + refus total de voir un médecin.
On s'y attendait au final, même si c'est toujours trop tôt.
 
Merci pour tous les messages de condoléance, même sur un forum c'est toujours sympa.
 
</MyLife>

Preums du dimanche, bande de paresseux !!!!

prems

Toutes mes condoléances

Condoléances

D'une partie d'un formulaire HTML en fait (sachant que cette partie peut être l'intégralité du formulaire HTML, mais on peut aussi combiner plusieurs Forms django pour avoir un Form HTML).
 
Ce qu'il y a de sympa, c'est que cet objet représente l'intégralité de ses données, sait les valider, et sait se représenter (en HTML, mais c'est extensible), et bien sûr la validation est fine ou grossière, etc... Et chaque champ dans le formulaire sait naturellement se valider tout seul (sans compter la validation custom qui fait partie du Form) et se représenter en HTML. Donc un Form isole totalement le concept de formulaire (et tout ce qui en dépend donc, mapping entre les données HTML brutes et les données métier, validation, représentation html, ...) du reste du système
 
Enfin, un truc marrant c'est que pour le CRUD il y a des fonctions et classes Django permettant de transformer directement un Model en Form (enfin de wrapper un Form autour d'un Model), donc quand on veut récup des données qui vont être directement stockées dans un Model au final on a pas besoin de s'emmerder (et ça ajoute une méthode save() sur le Form qui va sauvegarder le Model se trouvant derrière)

Stripes est pareil, mais justement je trouve ça super dégueu parce qu'on mixe la gestion & validation des données avec les actions/controlling (dans Stripes, la déclaration des champs, les annotations de validation et les méthodes de validation custom font toutes partie des ActionBeans).
 
En bonus (ce qui me lourde le plus dans stripes), si tu te retrouves avec 2 ou 3 actions/urls utilisant le même formulaire, soit tu dupliques soit tu crées des arbres d'héritage qui n'ont ni sens ni intérêt, et si un de tes AB doit utiliser un autre bout de form utilisé dans encore un autre AB, ben grâce à l'héritage simple tu l'as dans l'os

C'est planqué où? Parce que dans la doc symphony j'ai trouvé que http://www.symfony-project.org/book/1_1/10-Forms qui n'a aucun rapport avec les newforms

 
J'aurais fait ça une seule fois à ma copine, j'aurais pas eu l'occasion de le faire une 2eme...

Toutes mes condoléances
 

Django-tagging 0.2

hg qimport + hg qfold + hg qrm = rulz

figure 1 : Masklinn, nerd de l'année 2007

figure 2 : Masklinn, nerd de l'année 2008

Nan, mais cette histoire d'Action c'est pas possible ça marche pas quoi
 
je peux pas m'amuser à faire faire le même boulot préparatoire au système que le client fasse un get ou un post . Et si je mets le bon code dans la méthode du get, je perds tout ce que le framework était sensé faire à ma place.

et finally ?

D'ailleurs comment tu détermines que la requête est arrivée par un post ou un get dans ton action?

y'a bien longtemps que je lui ai fait la bite à la tronçonneuse à l'ActionMapper ...
 
si tu est en get c'est index() qui est appelé, si tu es en post, c'est create(). D'ailleur je pense que ça va finir en get() et post() (et fuck l'histoire des actions qui savent pas qu'elles sont en HTTP), parce qu'il est pas question de toutes façons d'appeler un create() en post et pour l'instant, y'a une annotation @PostOnly, mais c'est pas super-cohérent en fait .

En fait mon message plus haut était motivé par le fait que après un POST en général on fait un 302 vers un GET (parce qu'en web 2.0 y'a toujours un truc à rafraichir sur une page), donc pas la peine d'aller chercher le contenu de la page en base dans le POST, ça sera fait après le 302 dans le GET.

En fait c'était plus pour savoir comment checker ça dans Stripes dans le futur, parce qu'apparement pour le créateur du truc la distinction entre POST et GET n'a aucune importance et ne mérite pas de s'arrêter dessus (), donc j'ai vu aucune annotation et aucun moyen de savoir si on est en post ou get dans le truc

Sur mon projet actuel je m'en fous (c'est du wap/mobiles, donc les utilisateurs passent obligatoirement par une gateway à la con qui mangle les urls, le risque que quelqu'un joue avec est limité) (et pas mon problème, aussi), mais dans le futur ça pourrait servir

Dans Struts2 tu as le marteau :  
ServletActionContext.getRequest()  
 
une superbe méthode statique qui te renvoie la HttpServletRequest courante ....

Ah bordel, j'avais regardé dans HttpServletRequest, et pas vu qu'il y avait bien un #getMethod dedans

Ca me rappelle mon framework Je pouvais découper en action, indépendante de la méthode HTTP. J'ai tout balancé, et maintenant la méthode appellée correspond à la méthode Http : httpGet(), httpPost()

yo, on peut detruire les fichiers dans /var/tmp/ sans se poser de questions ou bien?  
 
 on dirait que j'ai une appli ui devrait utilise /tmp mais preferes /var/tmp et c'est chiant

[root@pouet tmp]# rm -f *.vec
bash: /bin/rm: Argument list too long
 
 
 

Elle doit utiliser la valeur du champ P_tmpdir (dans stdio.h, via la fonction tmpnam). Et en parfaite application unix, le répertoire tmp à utiliser est défini ... lors de la compilation.
 
Donc oui, tu peux faire du ménage dans /var/tmp...
 

ça y est, la machine respire enfin...

 
et puis tmpnam est devenue interdite, maintenant on doit créer le fichier par un appel système en une seule transaction.

 
Super
 
Tu lui mettras du sable dans la culotte à la récré ?

Toutes mes condoléances