La question est centré sur la meilleur façon de gérer un catalague-caddie, pas sur la programmation direct de ce caddie, même si tout se tient
 
Bon, je me suis penché sur la mis en place d'un catalogue de produits avec gestion du caddie et des utilisateurs. Je vous fixe le contexte rapide mais bon, je pense pas que ce soit nécessaire.
Catalogue d'environ 15000 produits classé par marque > catégorie > sous-cat. En gros, on doit atteindre un maximum de 50 produits maximum pour une sous catégorie. Mon problème réside dans la manière d'ajouter les produits dans le caddie. Ce que je souhaite, c'est pouvoir ajouter plusieurs produits de la même sous catégorie en même temps.
J'avais utilisé un formulaire par ligne, créé dynamiquement, avec à chaque produit un "valider" plus un imput type text mais c'est crade et ca correspond pas à ce que je veux faire (obliger d'ajouter un produit à la fois et de revenir sur cette page pour en rajouter un autre si besoin est). Je ne souhaite pas non plus mettre une page par produit dans laquelle on ajouterais le produit, on en revient au même point et il n'y aucun interêt à faire une page supplémentaire (pas de description produit).
Bon, j'ai donc décidé de faire un gros formulaire incluant tout mon tableau avec un seul bouton valider à la fin. Chaque ligne possède un input type text où l'on rentre la quantité, mis de base à 0. je fais donc passer en paramètre la totalité des produits présents sur la page avec comme paramètre ref=qté. Reste plus qu'à traiter le tout derrière.
 
Ma question est: est-ce la bonne solution? ceci n'est-il pas trop lourd comme gestion? Je vois pas vraiment comment faire autrement, si certains on eu des expérience de ce type ou ont des idées sur le sujet, n'hésitez pas...
Désolé pour le pavé et merci à ceux qui auront pris la peine de me lire.

Tu as la liste de tes produits issu de la même catégorie  et tu veux proposer de placer tout ces produit en même temps dans le panié. Je pense que tu devrais faire une liste avec une case a cocher plus une case permettant de tous cocher ou de décocher. A partir de là tu fais un traitement en boucle et tu place tous dans le panié.
Si j'ai bien compris ton affaire.

oui mais non... d'une, je dois pouvoir mettre la quantité. J'ai donc remplacé la case à cohé par un imput type text limité à 2. A partir de là je passe tout les paramètres (c'est à dire tous les produits) en POST et je les traite (si tel paramètre != null et != 0, je l'intègre dans le panier)
La question est: est-ce le meilleur moyen sachant que je dois pouvoir modifier la quantité...

va sur le site ooshop et fait tes courses dessu sans acheter et regarde comment il gere les articles tu pourras t'inspirer de cela. concernant parametre!=O ... c'est ce que j'utilisais.

spa vraiment ce que je veux faire... tout géré en javascript, incompatible avec firefox
Pas de doctype déclaré et même pas l'encodage...

ca ne t aidera surement pas, mais essaye d aller faire un tour ici : http://developpeur.journaldunet.co [...] ie1b.shtml

benh c'est encore un par un... mais c'est pas un problème de programmation hein, c'est plutot au niveau de la conception de manière général

Imaginons qu'on clique sur le bouton valider, qu'est ce qui t'empêche d'avoir le script de validation/ajout au panier qui génère la même page (avec simplement "grisage" de tous les produits déjà ajoutés au panier ou remplacement du bouton valider/ajouter par supprimer/retirer)?

Une dropbox ne serait-elle pas plus efficace à la fois en terme d'accessibilité et de sécurité des saisies?
 
Et pour sélectionner les produits, une sorte de tickbox (sélection de tous les articles à ajouter au panier)?

Ce qui est pratique avec les cases à cocher, c'est que si c'est pas coché => c'est pas posté, donc pas autant de tests que de produits et un joli foreach à la place.
Comme ya la quantité, tu peux panacher les 2 : tu actives le input text qd la case est cochée.

Ceci en gardant comme système un formulaire par ligne, non? le problème est que j'ai pas evie d'avoir un bouton/lien 'ajouter' par ligne mais plutot un formulaire général.

Dropbox ok mais certains produits peuvent être commandé en grosse quantité (je peux pas vous en dire plus sur les produits en question, désolé)

case à coché je veux bien mais sans javascript, c'est pas gérable. Or, je souhaiterais éviter autant que faire se peut le javascript qui, amha, ne doit déterminer la gestion en elle même, ça doit simplement servir à agrémenter certaines fonctionnalité côté client et non devenir indispensable au bon fonctionnement d'un script php

Comment ça c'est pas gérable sans javascript les case à cocher ? tu peux mettre les champs de quantité pour tous, seuls ceux dont la case à côté est cochée seront pris compte.

oui mais non... sans javascript, les paramètres du champs quantité seront pris en compte
 
je crois que je vais rester sur mon idée de faire un traitement simplement avec les quantités en passant tous les paramètres en post et avec un gros traitement derrière, un peu lourd, un peu bourrin mais bon, pour ce que je veux faire, je vois pas trop d'autres solution

attends 2 sec je te fais le truc comme je le vois

Faux, ils seront transmis mais il suffit de faire un test binaire sur la tickbox et de ne gérer/traiter la dropbox correspondante qu'en cas de validité (box cochée) de la tick, c'est tout con

Voila, j'ai fait un morceau de formulaire dispo ici :
http://guillaume.burlet.free.fr/hfr/form.php
 
alors, 'oui' tous les champs qté sont postés mais 'non' ya pas de parcours bourrin derrière puisque grâce aux cases qui sont cochées tu sais directement quels qté il faut aller lire.

Coté technique y'a rien de trop difficile mais coté utilisation, je crois que ca va faire chier l'utilisateur non?
 
50 produits = 5 pages à défiler pour aller cocher le bouton "valider" meme si on n'a qu'un produit à mettre dans le pannier (vu le systeme, pas moyen de faire du multipages)
Je pense aussi que la meilleur solution et que le bouton valider appelle la meme page avec simplement un parametre "action=ajoutAuPannier" en url, ca ajoute au pannier mais ca raffiche la meme page et on peut continuer les achats dans la foulée (dans ce cas pourquoi pas faire un mini panier sur le coté pour que le client puisse voir grosse-modo où il en est dans les achats)

Exacte c'est pour cela que j'ai montré l'exemple du site ooshop c'est ce qu'il font.

   
c'est exactement ce a quoi je pensais
(note: on peut remplacer les textbox par des combo si la qtt max n'est pas trop grande, histoire de faciliter la vie de l'utilisateur )

Ca me convient ça... en fait je l'avais pas vu comme ça. Je comprend meiux ce que tu voulais dire. Je testerai ça ce soir mais ça m'a l'air excellent. Merci beaucoup

ouais moi je vois le truc pratique comme aspegic
tu fais un tableau catalogue avec comme avant derniere colonne un formulaire (input text + submit )comme derniere colonne le nombre d article ds le panier. Comme ca t ajoute un article, et tu reste sur la meme page. Dc niveau navigation c pas mal,  tu peux ajouter plein d articles rapidement ...

gubug >>
Ca marche pile poil comme je le voulais...
merci beaucoup à tous

heuu par contre mettre un champ text pour determiner la quantité n'est pas tres propre et pas tres reflexe utilisateur. Conseil c'est de mettre un + et - tu fais un javascript qui incremente ou décremente un champ caché (qui aura l'equivalent du champt text actuel pour le traitement)
Sinon excuse moi là ça fait bidon.
 
Que j'explique un peut. Dans ce genre de chose il faut faire en sorte que l'internaute ne puisse rien saisir mais juste cliquer pour les geste répéter.

je vais utiliser un combobox...
Tu me parles de propreté et tu propose de gérer un système avec du javascript. Le javascript ne doit pas être "essentiel" à un système de ce genre ...

 
Le javascript c'est propre, c'est pas parce que 90% savent pas coder aux normes qu'il faut dire le contraire  
Et l'argument du "le javascript est desactivable" ne tiens pas car à ce moment là on peut aussi virer les sites en flash, les applets java, etc...
 
ps: rien ne t'empeche de faire un champ texte ET des +/- !!!

ni l'un ni l'autre. Quand tu fais un site, ne le fait pas par rapport à toi mais par rapport au utilisateur. Les internautes ont des relfexes conditionnés face à un internet. PLus ca va moin les gens veulent taper de façon répéter donc le faite de placer la quantité à chaque fois finit par fatiguer l'internaute. De toute façon tu vas bien faire un contrôle pour savoir si la quantité est bien une valeur numérique en javascript et php tu peut l'éviter en faisant le + et - et le code en javascript est un script compatible tout navigateur

ca depent ce qu il propose sur son site ... si les gars commande un article voir qques uns ok mais si c est du genre une vingtaien d articles... la c pas top le + / -

Moins il y a de JS dans un site meilleure est la compatibilité globale

ComboBox

Et parce qu'IE ne possède pas de JavaScript aux normes également, peut être

et on devrait, il n'y a rien de plus chiant qu'un site tout en flash ou tout en applet, aucune fonction essentielle d'un site ne devrait être gérée par des fonctions non standards/désactivables

Par rapport à TOUS les utilisateurs.
 
Des liens/fonctions essentielles en javascript, ca veut dire que toute personne sur un vieux navigateur, toute personne en mode texte, toute personne ayant désactivé le javascript se retrouve totalement incapable d'utiliser le site, ca va a l'encontre de la philosophie de base du Web

Combobox

Hint: PHP se fout éperdument du navigateur et n'est pas soumis aux possibilités de le désactiver ou aux incompatibilités entre des versions différentes de langages identiques (Javascript / JScript)

et la encore pour les faibles-moyennes quantités la Combobox est standard, parfaitement adaptée et gérée par tous les navigateurs
 
A tous ceux qui ont recommandé l'usage du JS alors qu'il n'est en rien nécessaire, allez lire cet article (et tout le reste de la page)

On y trouve également un avis sympathique sur les liens en JS

 
Surtout qu'il a rien compris a ce que j'ai marqué.
 
- Personnellement, je comprend ceux qui se prenne la tête a faire un site compatible tous navigateur. Pour mes deux sites il y a que 5% d'autre navigateur différent de IE. Personnellement si je voulais faire un site compatible mes sites seraient moin beau. Perso je vais pas me faire chier pour 5%. Mais c'est mon avis personnelle.

benh j'ai compris pareil et au niveau du l'utilisation du javascript j'ai le même point de vu que lui

Je parlais du comportement des internautes face a un site et non pas du javascript.  
Le faite de saisir un quantité pour un site marchand n'est pas quelques chose naturel sur un site marchand

benh oui mais t'insiste pour le remplacer par un morceau de js alors qu'un combobox c'est suffisant

C'est ce que je dis plus haut. S'il veut faire un site pas tres attractif pour pas utiliser de js ben qu'il le fasse mais perso les gens préfère acheter des produits sur des sites attractif.

c'est exactement ce que j'avais compris: tu utilises des arguments (genre l'important c'est l'utilisateur) uniquement quand ca t'arrange

Si tes sites sont plus beaux/fonctionnels que Organic Desire, Zaurus,  Spring 04, Revealed ou Pushing the Limits, je m'inclinerais peut être
attention, ces sites utilisent des CSS complexes, il est fort possible qu'IE6 soit incapable de comprendre, mieux vaut utiliser Opera ou un Gecko browser:
Organic Desire -> IE6 est incapable de rendre le menu déroulant au sommet de la page (il rend un menu déployé et moche)
Zaurus -> pas de rendu du menu popup complexe, remplacé par un menu "classique" en bas de page
Spring -> le Hover menu (les 4 boutons en blanc sur vert a gauche sont des boutons de menu) ne fonctionne pas
Revealed -> les images sont censées être comme fixes, sous MSIE c'est franchement moche  (même si c'est lisible/compréhensible il manque des effets)
Pushing the Limits -> toujours pas de menu (rendu en bas), l'image ne fonctionne pas
(hint: ces 5 sites utilisent EXACTEMENT LE MÊME fichier *.html, seul le *.css change)
 
Pour tester j'ai voulu voir Killer Style, sous IE il est joli mais il ne fonctionne pas (la machette/couteau est censée descendre avec la page et trancher le texte en 2)
 
Si tu ne veux pas démordre d'IE, il ne te reste plus qu'a regarder Austrian's Darker Side, qui rend de manière (presque) identique sous IE et Firefox
 
 
Dans tous les cas, je n'ai pas vu le moindre JS, juste du XHTML et des CSS
 

C'est toi qui n'a rien compris, la Combobox fonctionne de manière parfaite, permet d'avoir un contrôle maximal sur les entrées utilisateurs et de se passer totalement de JS, de plus utiliser une combobox (2 clics pour sélectionner une valeur) est beaucoup plus rapide qu'un throbber (n/2 ou n/3 clics en moyenne avec n le nombre d'élements)

 
Quand je regarde mes state il y a 5% d'utilisateur utilisant un autre navigateur. Alors pourquoi devrais-je me prendre la tête a faire du CSS complexe pour 5% de mes visiteurs. Surtout quand j'ai un peut pret 900 000 visiteurs/ans pour les deux sites.

ce n'est pas le sujet, les sujets sont:
 
1- tu te fous de la gueule du monde (puisque tu prétends "penser à l'utilisateur avant tout" alors que tu ne penses qu'a ceux qui t'arrangent: ceux qui sont sous MSIE)
2- tu prétends que les sites sans JS/en CSS sont moins beaux que les sites avec JS, je te dis que c'est faux et j'apporte des preuves, tant que tu ne m'auras pas donné de contre argument tu n'auras aucune crédibilité
3- comment gérer correctement un l'apport de nouveaux éléments dans le caddie, le seul argument que tu as donné en faveur des throbbers par rapport aux dropboxes est au mieux spécieux (c'est plus joli ), ou alors tu n'as toujours pas compris que RiderCrazy n'as pas retenu les textareas qui n'étaient la que pour l'exemple

 
 
Heu je crois que tu t'emporte facilement mec

le rapport entre l'utilisateur et le site, quel est il quand il est impossible pour lui d'utiliser le site (parce que celui-ci est codé IE only, parce que l'utilisateur a désactivé le JS, ...)?
surtout quand des outils/fonctions standardisés disponibles sur toutes les plateformes sont capables de faire le boulot?

point 1: Tes sites JS seraient plus beaux que tes sites non JS. Pourquoi?
point 2: Si tu aimes autant ne pas utiliser de JS, pourquoi le faire quand il t'est possible de t'en passer (comme dans le cas présent)?

Il n'y a pas de problème de compatibilité (x)html si tu n'utilises pas le html pour mettre en forme (ce qui n'est pas son role)
Pour la compatibilité CSS (c'est à dire compatibilité de la mise en forme du site), va voir Austrian's Darker Side, il rendra correctement sur tous les navigateurs rendant les CSS1 (même MSIE)
Enfin utiliser du JS et des informations de mise en forme/style au sein du code html est la meilleure manière de provoquer des incompatibilités et des erreurs d'interprétations au niveau de certains browsers

j'ai pas eu de réponse à celle la

je ne me suis pas encore emporté sur ce topic
 

Quand je fais un site, je code le javascript aux normes (je teste avec firefox et netscape), ensuite je teste sur IE6, puis IE5.5, puis avant je testais sur IE5.0 mais j'ai arreté car c'est vraiment trop une daube y'a rien qui passe, tant pis pour ceux qui utilisent encore cette version, la mise à jour est gratuite ils n'ont qu'a la faire  
 
En ce qui concerne le javascript je ne l'utilise pas sur des applications "critiques", je ne lui délègue jamais la sécurité (par exemple les controles de formulaire sont recontrolés derriere par le php) ni la méthode de navigation (les liens en javascript: beurk!)
Par contre je n'hesite pas à l'utiliser pour un ptit peu de confort supplementaire, tout en m'assurant bien qu'il passe aussi bien sur gecko que ie

Tant qu'on peut utiliser la page sans javascript, ya pas de malaise