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