Reprise du message précédent :

 
Si c'est pour avoir un metalanguage aussi verbeux autant avoir un:
<script>validator.push(['mon_champ', 'range', 0, 250]);</script>
C'est directement sous une forme traitable et ça dégrade proprement aussi.

En quoi c'est + merdique à garder en synch avec la validation coté serveur que d'utiliser des attributs custom ?
Et comment tu fais avec des attributs custom pour gérer plusieurs validation sur un seul champ ?
 
Sur mon appli actuelle pour l'instant à la validation du form (je peux le configurer pour être au onblur des champs à valider) ça fait un alert avec la première erreur rencontrée.
Sur un autre projet j'avais changé la méthode de render d'erreur pour afficher des div supplémentaires avec les messages d'erreur.

Résumé des derniers messages : comme pour beaucoup de choses, il y a 36 manières de faire un système de validation et les 36 façons sont utilisés.
 
Finalement, ça serait bien d'avoir un tableau sur les avantages et inconvénients de chaque méthode histoire de choisir en toute conscience.

Non, les deux sont merdiques pour ça, le seul truc potable étant l'autogénération. Donc c'est pas mieux que les attributs custom, et c'est moins lisible et plus long

Un attribut par type de validation. En gros, au lieu d'avoir ton élément <validation> t'as les attributs directement dans l'input ou le select, donc tu te débarasse au moins du for et de l'élément.

Configuration au niveau du formulaire, si absolument besoin ajouter un override au niveau champ.

Ca c'est un truc à implémenter dans la lib de validation, avec potentiellement une config au niveau du form (la validation se faisant en partant du form, qui décrit la manière dont il est validé)

Très mauvaise imagination
 
J'ai posté l'exemple avec le + d'attributs
Sinon j'ai ça comme validateurs :  

 
Sinon non je dois le fermer comme je l'ai fait sinon avec IE (de mémoire), j'arrivais pas à choper les tags en JS.

Ben l'autogénération je le ferais sans doute quand je passerais en symfony 1.1

Je faisais comme ça initialement
Quelle syntaxe tu utilises pour des validateurs complexes comme par exemple 2 validateurs compare qui compare la valeur de ton champ à comparer avec 2 autres champs de ton form ?
 

C'est le cas
 
Sinon à la base, le fait d'avoir 1 règle de validation => 1 tag validation c'était pour pouvoir poser des validateurs .NET dans Visual studio en mode graphique et que ça mette dans le code la correspondance au niveau technique. On travaillait à remplacer et à rendre unobtrusive le système de validation client-side de .NET

Un problème marrant que j'ai eu en validation :
"au moins un de ces 3 champs doit être remplis", vous le gérez comment avec vos différentes méthodes ?
 
( Et accessoirement, comment présenter ça à l'utilisateur de manière compréhensible tout en ne saccagant pas un design avec 3k de texte explicatif ? )

Sauf que vu que c'est porté de django, la validation client sera probablement pas prévue

Ca dépend, quand c'est trop custom faut créer une validation custom dans la page ou le form (une fonction js que tu enregistres), si ça l'est pas trop tu enregistres la relation au niveau du <form> (puisque la validation n'est en réalité pas sur le champ, mais sur la cohérence du formulaire). Je dois avouer que j'ai rarement eu de gros trus quand je jouais avec ça, la majorité des validations multi-champs c'était de type either/or.

Ok, je comprend mieux

Une liste de champs dans le <form> dans un attribut qui va bien (par contre obligé de sacrifier les ids pour reconnaître les fields ) comme je le dis au dessus, je vois cette contrainte comme portant sur le formulaire, pas sûr le champ.

Ca par contre c'est beaucoup plus chiant

Le contenu de ce message a été effacé par son auteur

Si tu veux pas mettre tes libs JS dans ton head html cette syntaxe là risque de poser des soucis d'intégration si tu mets tes appels de libs JS avant le </body>.
Ca romp le coté unobtrusive.

Non parceque j'ai bien pris soin de ne pas faire d'appel à la lib, je stocke des "pré-appels" dans validator, qui n'est qu'un tableau standard, la lib ira lire le tableau plus tard si elle a envie et si elle est chargée.
La seule contrainte c'est la création au préalable de ce tableau :
<script>validator = [];</script>
( en début de page ou j'ai deja 1-2 micro-broutilles dans une balise script )

Ils ont porté newforms de Django vers Symfony ?
 

Je me pose une question tout à coup. Est ce qu'il vaut mieux mettre les balises "<script>" de chargement d'un fichier "*.js" avant le "<body>" ou après le "</body>" ?

Ils ont réimplémenté les newforms dans Symfony 1.1 oui, c'est ratibus qui me l'a appris d'ailleurs

http://www.aide-de-camp.org/articl [...] attern-mvc

Putain mais comment on sait comment on installe un serveur SVN même la doc est pas claire sur les paramétrages en tous genre et tous les tutos trouvables ont une façon de faire différente

Tu as regardé le livre sur svn ? http://svnbook.red-bean.com/
 

Tout ça c'est fait, j'ai même activé les mdp dans svnserve.conf et modifié le fichier passwd.
Mais il ne voit pas de serveur, avec ou sans mdp.

vérifie que le processus est bien lancé.  
vérifie que les ports sont ouverts.
 
tu as essayé d'attaqué le serveur en localhost ?

Comment on fait déja ?

Comment on fait tout court ?

Genre "svn export svn://127.0.0.1/" ?

ps -edf | grep svnserve
 

euh, j'y connais que dalle avec les firewall mais un telnet sur le port te répondra (ou un netstat aussi je crois)

euhhhhh, j'aime pas trop ta commande là.
Tu as créé un repository déjà ?  
essaye plutôt un svn checkout svn://127.0.0.1 (et essaye un svn checkout file:///path/to/repository/  
ca ne va pas te dire si le daemon est en route, mais surtout si tu as fais un repository ou ...autre chose.
 

ps et edf, cool ça se retient

ill try

bah quoi elle est très bien ma commande, je veux exporter la dernière révision dans le dossier en cours

encore faut t'il que tu ais un dépot au bout ! (mais bon, je suis pas sûr du coup que checkout ça marcherais mieux que export mais bon )

J'en ai un merci

gecko sux

bande le lopettes, j'vais vous apprendre le web, moi, vous allez voir : http://www.dossard.com/

 
C'est peut être le moment de faire un petit break avec le web

 
svn info
 
De rien

Potentiel de win: http://intertwingly.net/blog/2008/ [...] uirks-Mode
 
Ceux qui suivent un peu l'actualité ont probablement eu écho de IE8, et du meta utilisé pour switcher sur le moteur "super standard" (quirks restera en IE6, strict restera en IE7, et il faudra un header HTTP ou le meta équivalent pour avoir le vrai moteur IE8)
 
Apparement, le doctype HTML5 déclenchera automagiquement le mode le plus strict (moteur IE8)

Et c'est ça qu'ils appellent "respecter les normes" : rajouter une balise proprio quand on utilise un doctype correspondant aux normes stabilisé ou utiliser un futur doctype correspondant à une norme susceptible d'être modifié à tout moment car non finalisé.
 
Avec IE7, IE était remonté un petit peu dans mon estime ... avec IE8 il retombe aussi bas qu'avant.
 
PS : Qui n'en avait pas encore entendu parler?
 
PS2 : A ce qu'il parait, pour IE9, ils prévoient déjà d'utiliser encore une autre méthode d'activation pour pouvoir forcer l'utilisation du moteur spécifique à IE9 quelque soit le doctype utilisé. (sic)

justement c est pas prevu pour etre proprio mais opur etre utile a tous les browsers

Bin perso, j'avais compris d'après cet article que ça restait assez proprio.
Le côté "proprio" et le côté "utile à tous les browsers" ne sont pas mutuellement exclusifs et c'est d'ailleurs bien là-dessus que mise Microsoft ; "eh les gars, on fait une super balise/attribut de balise pour nous permettre de sortir de notre merdier mais ça sera utile pour tout le monde, regardez " C'est débile, même si ça part d'un bon sentiment (et encore, chu même pas sûr qu'il y ait du bon sentiment)
L'idée principale, selon moi, serait de faire comme pour leurs OS : arrêter le support au bout d'un moment. Genre IE 8 sort, bin stop le support d'IE 6 et des sites faits pour IE 6. C'est con et ça casse des trucs m'enfin faut arrêter de se traîner les vieilles casseroles.

Ca, c'est se couvrir le cul, rien de plus.
 
Voir http://ejohn.org/blog/meta-madness/ pour ce que j'en pense, au final, resig explique ça très bien. Mais ce dont voulais parler (parce que je pensais que tout le monde était déjà au courant pour ça ), c'était pas le meta tout pourri mais http://ejohn.org/blog/html5-doctype/  
 
Si IE8 (dans le moteur IE8 superstandard toussa) implémente le HTML5 et que le doctype HTML5 trigger automatiquement, on pourra dev des sites en HTML5 et être tranquilles \o/

être tranquilles uniquement à partir du moment ou IE6 et IE7 sont suffisement peu utilisés

http://en.wikipedia.org/wiki/Intranet

Non mais le truc que vous avez l'air de pas trop réaliser, c'est que MSIE est descendu à ~60-70% de marché sur le web "ouvert", mais en intranet il reste à 95%, et MS ne peut pas se permettre de pêter les intranets. Et ils ne peuvent pas non plus avoir 2 navigateurs côté à côte, parce que les utilisateurs n'auront pas envie de switcher, et ils auront donc soit IE6 (pour leur intranet, mais aussi pour le web) soit IE8 (et boum l'intranet)

Non, ça n'est pas con, que ça casse des trucs c'est un mal necessaire.
 

• IE6 était déja pété à la base, donc casser des trucs dessus revient à rendre standard l'application.
• Les futures versions d'IE devraient être plus respectueuses des recommandations
• La majorité des browsers sont mis à jour régulièrement, donc oui, il faut arreter de trimbaler de vieilles casseroles, ça fait chier tout le monde et ça n'avance à rien. (Imagine seulement le cout de dev que répresente IE6)

C'est vraiment ça le problème, tant si au lieu d'avoir un taux d'utilisation ridicule on se retrouve avec un césure de plus (dans l'hypothèse ou IE8 sera developpé comme IE7, c'est à dire solide state et de manière à moitié foireuse) bah je vais arreter de faire du front, ou même du web perso

Je te parle même pas des couts de dev dans le grand compte chez qui je bossais et dont les plateformes officielles sont Windows XP IE6 et Windows NT IE 5.0
Faire des JS et des CSS avancés pour IE5.0 c'est priceless

C'est bien ce que je dis, il faut dans leur cas suivre le modèle de support de leurs OS ; les mecs sur leurs Intranets ils sont pour la plupart sous XP (IE 6 donc) et donc quand ils arrêteront le support d'XP, les entrprises migreront sur la suite (Vista, Windows 7... va savoir) en majorité. Donc support d'IE 7 et donc arrêt d'IE 6.
En plus y a des intranets qui passent très bien sur Firefox donc "tout casser" me paraît un bien grand mot.

C'est ce que je voulais dire, ouais Le "c'est con" c'était pour genre "c'est ballot".

1. T'es au courant que l'Extended Support de Windows XP (le truc pour les boites, donc) ça se finit en Avril 2014?
2. Et accessoirement, les boites n'ont pas nécessairement le choix, quand les intranets dépendent de leurs applis d'intranets et que IE7 pète les dits intranets (ce qui est malheureusement arrivé), ben ils peuvent pas trop migrer

Bien sûr, mais pas la majorité.