Discussion :

[autran]

Bonjour à tous,

Je vous propose un article pour concevoir un panier en JavaScript. Il s'agit d'un cas d'école qui offre un aperçu de ce que l'on peut faire avec ce langage coté client de façon simple. Ce panier est testé dans une page HTML5.

Implémentation d'un panier en JavaScript et HTML5

Merci de laisser vos commentaires !



Tous les meilleurs cours et tutoriels pour apprendre Javascript
Tous les meilleurs cours et tutoriels pour apprendre le XHTML
Tous les meilleurs cours et tutoriels pour apprendre la programmation Web

[MichaelREMY]

merci pour cet article, il est très pédagogique.

j'ai qq questions :

JavaScript comme on l'aurait fait avec n'importe quel autre langage. Car aujourd'hui, JavaScript est un langage aussi noble que Java ou PHP, surtout depuis qu'il s'exécute dans des serveurs. D'ailleurs, dans un prochain tutoriel je montrerai comment faire tourner ce panier plus proprement côté serveur avec Node.js.

D'un je ne pense pas qu'il existe une mesure de la noblesse d'un langage, donc je pense que tu voulais juste une petite introduction sympa...

bref, dis-moi qu'entends-tu par "surtout depuis qu'il s'exécute dans des serveurs" ?
veux-tu juste dire que les librairies/bibliothèques sont sourcées depuis un serveur comme par exemple <link href=...etc ? (et donc ensuite stockées sur le client physiquement ou dans sa mémoire).
ou bien tu veux dire que la charge de calcul CPU et la charge d'occupation mémoire sont réellement effectuées/supportées par et sur le serveur lui-même (au lieu du client navigateur) ?
Je pose cette question "naïvement" ne connaissant pas node.js encore, car pour moi le javascript a toujours été un langage s'exécutant côté client (dépendant hélas de la version du navigateur).

Enfin une autre question : ne penses-tu pas qu'une gestion de panier devraint obligatoirement s'exécuter via un script serveur/ajax ?
Ne serait-ce que pour une question de sécurité (n'importe qui peut avoir un navigateur qui bidouille le JS pour tromper le panier) , ensuite pour une question de sauvegarde/réutilisation du panier, enfin pour une question de statistiques (pour étudier l'entrée/le changement de décisions des produits par l'acheteur potentiel).

merci pour vos réponses (car tout le monde peut répondre).

[autran]

Bonjour michael,

Comme je le précise en préambule dans l'article, l’intérêt de gérer un panier 100% coté navigateur est purement pédagogique. Cela permet d'illustrer le potentiel de JavaScript et HTML5.
Je ne me suis pas étendu sur les raisons pour lesquelles l'industrialisation d'une telle solution coté client serait une aberration, mais tu l'as parfaitement fait. Donc merci Michael pour cela.

En effet, lorsque je parle de JavaScript coté serveur je pense bien entendu à NodeJS que l'on pourrait alors voir comme une plate-forme comparable (en terme de service) à PHP, qui lui aussi s’exécute sur un serveur.
Je suis d'accord pour dire que le choix des produits (la navigation dans le catalogue) peut se faire via une technologie asynchrone (comme AJAX), en revanche le panier peut être gardé sur le client jusqu'à la validation. En effet une fois validé le panier devient une commande qui sera gérée coté serveur. Car lors de la validation le serveur ne recevra que les codeProduit et les quantités commandées, et il refera le calcul pour s'assurer que le prix total et juste.

Néanmoins il y a plusieurs écoles et il est toujours intéressant de confronter les avis, donc n'hésitez pas à réagir à ma réponse. Ce sera un dialogue enrichissant.

[Gnuum]

C'est un article intéressant mais dont l'objectif reste flou malgré le fait qu'il soit explicité.
En effet, si j'ai bien compris, le but est de réaliser un panier en javascript puis de le tester en l'intégrant dans une page HTML5 même si sa réelle exploitation devrait être faite côté serveur. En gros, cela veut dire que la partie HTML5 n'a pas d'autre intérêt que le fait d'être en HTML5; que la partie en javascript n'a pas d'autre intérêt que son détail d'implémentation, puisque le code final ne sera pas "vraiment" fonctionnel (pour une utilisation prod).

Ce qui fait que j'identifie les buts sous-jacents suivants:

• comprendre une implémentation simple et efficace d'un panier en javascript orienté objet.
• utiliser du HTML5 pour définir l'affichage du panier.

Cependant, tu donnes les prérequis pour comprendre ce tutoriel:

La connaissance du langage JavaScript « orienté objet » est indispensable à la compréhension de cet article. Le lecteur doit également maîtriser le HTML5 en général et plus particulièrement les formulaires et la navigation dans le DOM.

Ce qui me dérange, au final, c'est la faiblesse de l'objectif pédagogique réel. En gros si je corresponds à tes prérequis, il ne me reste pas grand chose à apprendre de ton tutoriel. Ton article pourrait toucher 10 fois plus de gens si tu oubliais tes prérequis et que tu commentais ton code précisément du genre "ici je défini un constructeur de classe javascript" ou "cette balise est une balise sémantique HTML5 qui sert à ..., voici un lien vers une explication du web sémantique".

Fais attention aux petites imprécisions également:

• Ces deux objets sont écrits à 100 % en JavaScript.

  ce ne sont pas des objets, ce sont des classes (en l'occurrence des constructeurs de classes).

• le HTML5 en général et plus particulièrement les formulaires et la navigation dans le DOM

  je ne crois pas que la navigation dans le DOM que tu utilises aie quoique ce soit à voir avec le HTML5.

Pour résumé, ton code est efficace car simple et le nommage des choses me semble correct (ce qui permet de le comprendre rapidement), mais je pense que tu aurais gagné en mettant plus de liens vers des ressources externes et en commentant ton code.
Pour ne donner qu'un exemple, ton implémentation en javascript orienté objet est ultra simple mais pas très pédagogique car elle ne reprend pas beaucoup de bonnes pratiques (qui même si elles rendent le code un brin plus compliqué sont intéressantes à connaître et sont facilement et rapidement explicables avec des commentaires):

• elle n'utilise pas la puissance du prototype (définition des méthodes publiques sur le prototype),
• elle ne restreint pas l'accès aux méthodes "privées",
• elle ne définit pas d'accesseurs systématiquement,
• ...

Pour respecter ce que je te dis, voici un petit lien a propos de la programmation orientée objet en javascript.

Je sais que mon commentaire paraît plutôt négatif, mais c'est simplement pour que tu améliores tes prochaines publications et que tu puisses toucher plus de monde. En tout cas, merci pour l'article et continue!

[autran]

Bonjour Thomas,

Merci pour cette intervention.
Je confirme qu'il faut corriger le tir en début de rédaction de l'article, sinon c'est irrécupérable
Je confirme également que seul un œil extérieur peut réaligner stratégiquement la rédaction de l'article.
Donc pour celui-là, c'est trop tard

En revanche, je viens de poster un draft pour un prochain article Ajax-Json ICI. Alors j'attends tes commentaires, je serais très heureux que tu y sois mon relecteur technique

à très bientôt sur le post de mon futur article ou par MP

PS : j'ai aussi dans les cartons un article sur Node.js dont j’apprécierais également de débattre avec toi compte tenu de la qualité de ton dernier article.

[Gnuum]

Pour la relecture, ce sera avec plaisir mais je n'ai pas les droits d'accès à ton draft:

Gnuum, vous n'avez pas la permission d'accéder à cette page.

En ce qui concerne l'article sur node.js, n'hésite pas. Je ne sais pas si je te serai d'une grande aide mais ça ne coûte rien de voir!
Merci d'avoir lu mon article.

[autran]

OK je regarde pour tes droits avec les responsables de rédaction et je te fais signe par MP
A+

[SylvainPV]

Etant relecteur technique sur cet article, je me permets de réagir à certains retours

cela veut dire que la partie HTML5 n'a pas d'autre intérêt que le fait d'être en HTML5; que la partie en javascript n'a pas d'autre intérêt que son détail d'implémentation, puisque le code final ne sera pas "vraiment" fonctionnel (pour une utilisation prod).

Le code final est "vraiment" fonctionnel, en production ou ailleurs. Ce n'est pas parce qu'il est impératif de gérer le panier côté serveur qu'il faut exclure une gestion côté client également. Gérer le panier côté client permet une navigation et des actions plus fluides, et c'est une condition nécessaire pour envisager un mode offline ou mieux supporter les pertes momentanées de connexion. Tout site de e-commerce moderne devrait avoir ce genre de fonctionnalités implémentées côté client selon moi. Et si Marc a mentionné nodeJS, c'est parce qu'on peut tout à fait envisager de partager le code de l'objet Panier côté client et serveur pour unifier les règles de gestion.

ce ne sont pas des objets, ce sont des classes (en l'occurrence des constructeurs de classes)

Je refuse de parler de classes en JavaScript ES5. S'il avait utilisé le mot "classe" c'est moi qui lui aurait dit à la relecture de renommer ça en objets. C'est une question de terminologie, et je sais que beaucoup utilisent le mot "classe" pour mentionner une fonction constructeur appelée via l'opérateur new. Mais c'est là que se trouve l'imprécision, car il ne s'agit pas de classes au même sens que dans les langages de classes usuels. En JavaScript, il n'y a pas de classes, il n'y a que des objets. Voilà un article du MDN, pour reprendre tes sources, qui illustre bien ces différences : https://developer.mozilla.org/fr/doc...n_d%C3%A9tails

[Gnuum]

Classe vs Objet
Le mot classe/objet est toujours un débat compliqué en javascript.
Personnellement, dans ce cas je préfère parler de classe car, même si bien sûr ce n'est pas une classe comme on l'entend dans la plupart des langages objets, ce mécanisme est censé "simuler" une déclaration de classe pour le langage prototypé qu'est javascript. De plus parler d'objet, pour moi dans ce cas, prête à confusion car c'est le résultat de l'"instanciation" avec new qui donnera l'"objet" comme on l'entend en programmation orientée objet classique. D'un point de vue pédagogique et clarté, je pense donc qu'il est plus intéressant de parler de classe qui n'est finalement qu'un mot qui sert à représenter un comportement plutôt que d'objet qui sert à représenter un mécanisme sous-jacent.
Cependant, je tiens à redonner certainement la meilleure et plus concise définition d'un prototype qu'il m'ait été donné de lire, qui a été écrite par quelqu'un que tu connais bien Sylvain et qui je pense explique ton point de vue:

Le concept de prototype en JS est très simple: tout est objet, tout objet a un prototype, tout objet peut être le prototype d'un autre objet. Les objets héritent des propriétés de leur prototype, et peuvent les surcharger. Il n'y a donc qu'un seul concept, l'objet prototypé, contrairement à la POOC qui distingue classes et instances. L'héritage devient lui-aussi plus simple : j'ai deux objets A et B, je veux que B hérite de A, donc j'assigne A comme prototype de B. C'est tout !

Juste pour revenir sur l'aspect ES5: je ne pense pas que l'on puisse plus parler de classe en ES6 qu'en ES5 car, pour moi, le fonctionnement reste le même (à un micro chouilla prêt disons) malgré le mot clé class qui n'est qu'un bon gros sucre syntaxique. Je me permets de donner le lien vers le sujet de forum (d'où j'ai extrait la précédente citation notamment) et dont l'article en relation donne un point de vue très intéressant sur l'évolution de l'orienté objet en javascript.

Fonctionnel
Après sur l'aspect "fonctionnel" de ce code, je fais partie de l'ancienne école encore (pour combien de temps!) qui a tendance à développer son code serveur comme si le javascript côté client n'existait pas (ça m'aide pour le bookmarquing et à rationaliser ma façon de coder le javascript côté client), puis je rajoute ma couche de javascript côté client pour rendre le tout plus dynamique (je ne sais pas si ça peut aider à comprendre ce que je viens de dire mais voici un lien vers la documentation (en anglais) pour voir comment j'ai traduit ça dans un fonctionnement ajax par exemple dans mon framework node.js). Ce qui fait que j'ai un peu de mal à resituer ce code dans cette façon de coder.

En gros, pour résumé rapidement mon point de vue sur le sujet:

on peut tout à fait envisager de partager le code de l'objet Panier côté client et serveur pour unifier les règles de gestion.

Oui, mais il y a beaucoup de choses à faire pour y arriver et donc je pense que l'intérêt pédagogique est principalement dans le code lui-même et non dans la fonctionnalité.


Après, je ne dis pas, bien sûr, que ce que je dis est la vérité, ce n'est que mon point de vue à la lecture de cet article et sur ce que je m'attendais à y trouver ou à ce que j'aurais aimé trouver si j'avais été un plus jeune développeur javascript.
Et tout ça n'enlève rien à la qualité globale de l'article (et de sa relecture donc)!

[scoubi77]

Bonjour,
Merci pour cet excellent tutoriel, étant novice j’ai donc essayé de suivre pas à pas et j’ai réussi à le réaliser.
J’ai une question, une fois le panier constitué comment récupérer les données et passer au mode de payement ?
Avez vous fait un tutoriel pour la suite ?
Merci beaucoup