Reprise du message précédent :
http://dev.rubyonrails.org/ticket/2600
mais qu'est-ce que j'ai été foutre dans cette galère ?

Je fais comment en CSS pour faire descendre une colonne au même niveau qu'une autre ?
 
En gros j'ai un site avec une structure basique à trois colonnes.
 
Une petite à gauche, une petite à droite, et le contenu dans une grosse au milieu.
 
Lorsque la colonne du milieu est trop grande, les petites ne suivent pas, et inversement.
 
Merci

T'es à nouveau retourné sur RoR toi?

Non mais il a choisi scriptaculous pour son framework JS

Hello, vous avez des adresse de bon sites proposant des kits de design gratuit ou payant.

Genre http://www.kits-gratuits.net/site/

ou http://www.oswd.org/

Oui ou oswd.org

 
Je bookmarke, tiens.

+10 000

http://www.kitgraphique.net en payant (pas cher)

Salut les gros
Je m'intéresse de plus près à la validation de formulaire avec du JS unobtrusive (la VF c'est quoi, non-intrusif ?) pour éviter de soumettre un truc où i manque des champs ou quand le format n'est pas bon.
J'ai vu qu'il existait différentes méthodes, telles l'utilisation de inputs en hidden ou via des classes CSS qui vont bien voire en utilisant une DTD custo et en foutant des attributs persos aux inputs.
Qu'est-ce que vous utilisez ou utiliseriez ? Perso, l'utilisation de classes CSS me semble plus adapté et moins "bidouillesque" mais chu pas un expert

heu ... la validation des données avant envoi à pour but de vérifier que tout est bon (vérifications à refaire quand même sur le serveur)
Le fait de masquer des éléments d'un formulaire n'a, à mes yeux, aucun rapport avec un système de validation à moins de coder les tests comme un goret.

Je comprends pas vraiment la question non plus.

Les input hiddens j'aime pas du tout, les attibuts custom je suis fan (c'est puissant et extrèmement flexible) mais ça flingue la validation (sauf à créer une DTD custom au lieu de faire un ajout informel, effectivement), les classes c'est pas mal mais c'est plus chiant à extraire & parser (genre stocker une regexp dans un attribut custom c'est trivial, dans une classe custom c'est vachement plus tendu), un peu moins flexible (certains caractères ne sont pas authorisés, donc là encore pour pouvoir valider contre une regexp...). Par contre ça permet de garder la validation.

Au final, je dirais que si tes méthodes de validation sont relativement standard (required, une certaine longueur mini, etc...) et que tu peux créer des "classes de validation" immutables et standard pour tous les champs les classes c'est bien, si t'as besoin de validateurs très customisés (genre pouvoir valider contre une regexp fournie en même temps que le champ) les attributs sont largement supérieurs.

edit: après, il y a aussi le passage à la vitesse supérieure de faire des appels XMLHttpRequest, et le serveur renvoie le résultat de la validation. Comme ça, il est possible de valider chaque champ en direct, par contre ça tape plus violement sur le serveur si on utilise pas un truc genre Comet.

Masklinn > Et générer (dynamiquement si besoin) un bout de javascript (inclus à la page) qui permet d'indiquer les tests à faire au moment de valider, c'est pas suffisant? Ca évite de casser la validation w3c, de se baser sur des nom de classe quand on a besoin de validation par regexp ou de rajouter des inputs bidon.

Un bout de javascript unique? Ou un bout de javascript pour chaque champs?

Si c'est le cas 1, ça veut dire qu'il faut se taper l'écriture de routines javascript custom pour toutes les pages contenant des éléments de formulaires (), si c'est le cas 2 c'est moche, ça rend plus difficile le testing et le débugging, et ça a 9 chances sur 10 de pêter si le code (y compris les éléments de formulaires) n'est pas généré via une lib spécifique (un truc genre newforms django, la lib de forms réimplémentée par Symphony 1.1). Et ça augmente le poids des pages, aussi.

J'avais pensé à utiliser un truc à la netvibes, à mettre dans le head. Par contre j'ai pas vraiment étudié la question, quid la maintenance, l'intégration etc...
 
Après les attributs perso, c'est une excellente solution et à ce niveau, la valid on s'en branle, le but c'est que ce soit flexible.

Je vous renvoie à http://particletree.com/features/a [...] alidation/
L'idée est de mettre dans un input hidden le type de validation pour un élément donné. Une sorte de référence, quoi. Le truc c'est que si le JS est unobtrusive, le code HTML ne l'est plus (créer des éléments spécifiques pour la validation... bofbof, autant foutre un onsubmit()).

La validation (si tu parles bien de validation XHTML), j'en ai pas grand-chose à faire ; l'idée est que mon site tourne sur les principaux navigateurs (dont IE 6 ), mais je ne vois pas très bien ce que peut m'apporter la validation dans ce cas-là. J'y connais rien en DTD custo mais c'est l'occasion d'apprendre
Les classes me semblent là aussi une bonne alternative dans le sens où je vois pas très bien pourquoi je voudrais stocker une regexp dedans La regexp elle va être côté JS et je dirai à mon inptu class="email" ou class="date", une connerie du style. Non ?

A priori, ce serait quelque chose d'assez standard et simple, mes formulaires étant assez basiques (upload, moteur de recherche avec des text et des select, inscription), donc je ne suis pas sûr d'avoir besoin de passer une regexp pour chaque champ. A vérifier, par contre.

Ouais, j'avais pensé à faire un brin d'Ajax là-dedans mais j'ai aussi pensé au trafic réseau et j'ai complètement mis l'idée de côté Pas de Comet en vue pour l'instant.

Masklinn > Je pensais au cas 1 en utilisant une librairie (perso ou récupéré ailleurs) qui génère le code javascript qui va bien.
Côté poid, je suis pas sur qu'un tel javascript prennent plus de place (certe ça dépend du code à générer et donc des librairies utilisés) que des input invisible ('<input type="hidden" value="">' = 30 caractères).
 
EDIT : J'avais pas vu ton edit sur XMLHttpRequest qui est une autre solution si le serveur et les liaisons réseau/internet sont assez puissant pour tenir la charge.

L'avantage de la validation, c'est de chopper des erreurs genre typo dans un tag, tag mal fermé, ... Ca donne une "baseline" garantissant un comportement sinon correct au moins pas trop mauvais (et je parle uniquement de validation HTML ou XHTML via http://validator.w3.org )

Ben ça dépend, si tes besoins se limitent à ça c'est très bien, si t'as besoin de validations plus complexes t'es fucké, c'est d'ailleurs exactement ce que je dis dans ce que tu quotes en dessous

La potentialité de regexp (ou autre, ça peut être une range min-max, ...) n'est pas nécessairement pour chaque champ, mais si tu en as besoin dans certains champs ben faut l'inclure un jour ou l'autre. Après, il faut voir si tu fais du "pur" class-based (dans ce cas t'es fucké), du "pur" attributs (jamais de problème de flexibilité mais tu perds la validation et pour les validateurs un peu standards c'est un peu plus chiant à écrire) ou hybride (class-based en général, mais avec possibilité d'avoir des attributs custom pour les validations les plus complexes)

Et donc un gros pâté de js custom dans chaque page contenant des formulaires \o/

Si une ligne de js par élément à tester = gros pâté, alors oui.

Donc oui.

 
Perso j'ai fais avec des attributs perso ou alors carrément des tags perso pour + de souplesse

On peut récupérer facilement les commentaires html en javascript par DOM ou alors t'analyses le code html de la page?

Bon ba j'pense je vais partir sur des classes ; si je tombe sur des trucs plus cotons, soit je mettrai tout en attributs custos (si chu pas trop avancé dans le bordel), soit je ferai un machin hybride.
Merci les gros

J'vois pas quel intérêt ça a sur les attributs customs, à part être plus chiant à parser

Ca valide

Gnégnial

Il est vrai

Mais c'est vachement plus chiant à parser, faut extraire les données à la main et faut jouer avec previousSibling et nextSibling dans le dom pour savoir à quoi ça correspond

edit: ohshit, i:toto ça veut dire que ça valide le truc d'id toto, j'avais pas vu

C'est complètement beurk (et ça force à avoir un id spécialement pour la validation, avec classes ou attributs custom pas besoin )

(et avec classe ou attributs custom, on peut utiliser les sélecteurs xpath ou getElementsByClassName modernes pour fetcher tous les trucs à valider rapidement )

Tu énumère le commentaires, et avec le i:toto tu ajoute les propriétés contenues dedans au dom node correspondant à l'id spécifié, pas besoin de siblinger de partout.
( Mais ouais, c'est pas plus simple que les cust-attr, par contre, faut namespacer les attributs persos si on veut pas être un connard anti-future-proof )

Et sinon, vous gérez comment la cohérence entre les vérifs coté client et coté serveur ?

edit (post-ton-edit):
de toute façon faut des id pour les labels

Oui, j'ai vu ça après

On peut même dire que c'est plus complexe

J'les gère pas, mais si je voulais les gérer je pense que j'ajouterais le générateur de validation à newforms (si django) => les validations sont spécifiées quand l'objet formulaire est créé, et les champs sont générés via l'objet formulaire, donc la validation serveur et la validation client sont toutes deux générées par la lib et restent cohérentes (sans une lib type newforms, j'en créerais une, paske c'est le bieng)

Sinon, le seul moyen que je vois c'est que la validation client soit faite en XHR et tape dans la validation serveur.

Btw. le principe de l'utilisation des id pour les label/input c'est absolument merdique niveau composabilité du code

M'en fous moi de la validation :

Je peux associer autant de validator que je veux sur un champ donc c'est super pratique.

Vous avez que ça, les solutions moches et chiantes?
(nb: et j'vois pas l'intérêt d'avoir un élément maximisé vide, le xml ça se minimise)

Je veux bien des arguments

C'est long à écrire, c'est merdique à garder en synch avec la validation côté serveur (et si la validation côté serveur est gérée par ce truc, je vote la mort pour son créateur), faut le typer manuellement puisque c'est du XML.
 
Et j'voudrais voir ce que ça génère, aussi

Ouch, le nombre d'arguments, j'imagine que y'a rien d'optionel la dedans
 
De plus, tu sais que tu peux écrire <tag/> ?

 
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.