Site web de commande en ligne, réalisation?

Je dois réaliser un site de commandes en ligne, et il faudrait donc que la société soit informé "en direct" des commandes.

Les infos seront donc mise dans une base de donnée externe (genre ovh...). Il faudrait donc que la société soit à l'écoute de la base de donnée et que dès qu'il y ai une commande qui se réalise, que l'application detecte et affiche ces commandes.

Donc je vous demande comment feriez-vous pour tenir votre application "à jour" en fonction de la DB.

ps: Si certains ont déjà réaliser ce genre de chose, quel langage de prog avez-vous utilisez pour l'application en quesiton?

merci

il existe tjs des cms du genre joomla combiné avec une gestion de caddie, genre virtuemart

http://joomlasource.be

D'un côté le site. Je suppose que tu vas faire ça en PHP.

Tu pourrais avoir une "version" de ton site dédicacé à l'administration ... au back office comme on appelle ça. Donc tjs un site (dont l'accès est sécurisé par mot de passe par exemple) en PHP pour la visualisation des commandes en cours.

Pour être au courant ... tu peux travailler via:

* notification par email
* sms sur un gms
* une page qui se raffraichit à intervalle régulier et qui affiche la liste des commandes non traitées
* ... que sais-je ...

Good luck

nb: il existe des appli en PHP toute faite pour le commerce électronique. Des "sites" qu'il suffit d'installer. Même si ce n'est pas pour l'installer et l'utiliser, tu peux t'en inspirer au moins pour les principes. Tu auras peut-être les réponses à tes questions. Ex: Agora Shopping Cart, CubeCart, OS Commerce, Zen Cart, ...

ZorrObiwan a dit:

D'un côté le site. Je suppose que tu vas faire ça en PHP.

Tu pourrais avoir une "version" de ton site dédicacé à l'administration ... au back office comme on appelle ça. Donc tjs un site (dont l'accès est sécurisé par mot de passe par exemple) en PHP pour la visualisation des commandes en cours.

Pour être au courant ... tu peux travailler via:

* notification par email
* sms sur un gms
* une page qui se raffraichit à intervalle régulier et qui affiche la liste des commandes non traitées
* ... que sais-je ...

Good luck

nb: il existe des appli en PHP toute faite pour le commerce électronique. Des "sites" qu'il suffit d'installer. Même si ce n'est pas pour l'installer et l'utiliser, tu peux t'en inspirer au moins pour les principes. Tu auras peut-être les réponses à tes questions. Ex: Agora Shopping Cart, CubeCart, OS Commerce, Zen Cart, ...

Cliquez pour agrandir...

Oui, le site en php, l'administration du site se fera par le site également (maj des prix, ajout de produits etc).

Ce qui 'interesse justement, c'est "Pour être au courant"

-email bof bof ;
-sms sur un gms ??? ;
-j'avais pensé à la page qui se rafraichi à interval régulier, mais c'est pas tres optimal.

-je voudrais plutot cree une application qui detecte ces modifications de la db :-'

Je vais jetter un oeil sur ces sites

™ bak ™ a dit:

-je voudrais plutot cree une application qui detecte ces modifications de la db :-'

Cliquez pour agrandir...

c'est pas très compliqué à faire... et pas besoin d'un accès à la base de donnée à distance...

j'ai déjà fait ce genre de petit programme en Purebasic mais pour le langage que je pourrais te conseiller, je pencherais plutôt pour Python (ou Ruby).

Maintenant voila le principe :

- Une page php qui vérifie le dernier ID de la table commande. (juste l'id c'est suffisant pas besoin d'autres choses c pas indispensable)

- Le programme vérifie si il n'y a pas de nouvelle commande, donc il *va voir* la page php. Si il y a une nouvelle commande, il enregistre l'id de la dernière commande pour plus que cette commande soit considérée comme nouvelle.

Et au niveau de la sécurité c'est assez simple aussi, tu peux donner un nom d'User-Agent (si je me souviens bien, c'est ce qui identifie le navigateur) à ton programme. Et pour la page php qui vérifie si il y a une nouvelle commande, tu peux autoriser l'affichage que si c'est le programme qui se connecte a cette page.

Je t'ai donné le principe d'une version ultra simple mais tu peux voir + loin facilement... (récuperer complètement les commandes dans le programme, rajouter des produits, ....)

Pour info, c'est le système que Trackmania utilisait à ses débuts pour gérer les joueurs connectés ainsi que les serveurs donc il n'y a pas de problème de performance ni de problème de bande passante vu que ce n'est que quelques octets qui se transfère de temps à autres.

BaKa a dit:

c'est pas très compliqué à faire... et pas besoin d'un accès à la base de donnée à distance...

j'ai déjà fait ce genre de petit programme en Purebasic mais pour le langage que je pourrais te conseiller, je pencherais plutôt pour Python (ou Ruby).

Cliquez pour agrandir...

Je pensais justement le faire en python :-]

BaKa a dit:

Maintenant voila le principe :

- Une page php qui vérifie le dernier ID de la table commande. (juste l'id c'est suffisant pas besoin d'autres choses c pas indispensable)

- Le programme vérifie si il n'y a pas de nouvelle commande, donc il *va voir* la page php. Si il y a une nouvelle commande, il enregistre l'id de la dernière commande pour plus que cette commande soit considérée comme nouvelle.

Cliquez pour agrandir...

Ouep, mais donc faudrait que mon prog regarde chaque minutes par exemple si la derniere id est la meme que l'ancienne donc.
Moi j'avais plutot pensé a un detecteur d'evenement

BaKa a dit:

Et au niveau de la sécurité c'est assez simple aussi, tu peux donner un nom d'User-Agent (si je me souviens bien, c'est ce qui identifie le navigateur) à ton programme. Et pour la page php qui vérifie si il y a une nouvelle commande, tu peux autoriser l'affichage que si c'est le programme qui se connecte a cette page.

Cliquez pour agrandir...

je vais voir a ca

BaKa a dit:

Je t'ai donné le principe d'une version ultra simple mais tu peux voir + loin facilement... (récuperer complètement les commandes dans le programme, rajouter des produits, ....)

Pour info, c'est le système que Trackmania utilisait à ses débuts pour gérer les joueurs connectés ainsi que les serveurs donc il n'y a pas de problème de performance ni de problème de bande passante vu que ce n'est que quelques octets qui se transfère de temps à autres.

Cliquez pour agrandir...

Merci

™ bak ™ a dit:

Ouep, mais donc faudrait que mon prog regarde chaque minutes par exemple si la derniere id est la meme que l'ancienne donc.

Cliquez pour agrandir...

chaque minute, c'est trop... c'est largement suffisant toutes les 15 minutes (je ne pense pas que la société soit assez grosse pour avoir plus d'une commande par minute)

™ bak ™ a dit:

Moi j'avais plutot pensé a un detecteur d'evenement

Cliquez pour agrandir...

Donc tu veux que l'application reçoivent directement les données d'une commande quand elle est confirmée... Ca doit être possible en développant une application de type "serveur", je pense même que ça ne doit pas être très dur si tu t'y connais avec les sockets...

le principe est assez simple en tout cas, et je suppose que la plupart des hébergeurs payants acceptent l'utilisation des sockets en php...

- un champ "envoi_serveur" dans la table "commande" (1 si l'envoi est effectué, 0 si l'envoie n'a pas fonctionné)

- dans la page "commande confirmée", connection a l'application serveur et tentative de transmission de la commande au "serveur".

Je pense aussi que que le PC qui utilisera l'application n'aura pas une ip fixe donc il suffira que le programme transmette à la BDD MySQL la nouvelle ip à chaque ouverture du programme.

Ca me donne envie de me remettre un peu à la programmation tout ça.... :-D

EDIT: J'ai oublié un truc (suis crevé, nuit blanche lol)... Y a peut-être moyen de faire plus simple avec le SQL si tu peux accéder à distance à ta BDD mais j'suis pas trop doué en SQL mais si jamais qqn m'apprend qu'il y a un truc plus facile, je suis preneur pour ma connaissance personnelle

C'est du WebService ce que tu pense faire là

Un petit programme en .Net est tres facile à faire et permettera d'être notifié de nouvelles commandes


Le webService ira checker le nombre de nouvelles commandes toutes les 10 minutes ou quand l'utilisateur le veut, et ce webservice (facilement faisable en PHP (nuSOAP : librairie permettant de faire un serveur facilement)) proposera qques méthodes, du genre :

int nbNouvellesCommandes( $user ,$mdp )

Cliquez pour agrandir...

Comme ca le membre se "loggue" sur le programme comme s'il était sur le site (donc meme user que celui qui ira administrer le site, pas besoin de créer un user à un autre endroit), et le programme appellera le WebService à interval régulier et notifiera l'utilisateur dés qu'une ou plusieurs nouvelles commandes sont arrivées

(ps : je conseille de crypter le mot de passe en md5 avant de l'envoyer au serveur, on ne sait jamais...)

Il ne faut pas préciser qu'il faut implémenter ta DB de sorte que toute nouvelle commande est mise par défaut à non-traitée



j'ai fait un notificateur de messages pour un site, donc ca ressemble très fort à ce que tu veux faire (toi = commandes, moi = messages), n'hésite pas à me demander un peu d'aide si t'en a besoin, que ce soit pour le serveur en PHP qui proposera ce service de WebService, ou le client qui utilisera ce WebService. Bien sur, si tu choisis cette méthode que je viens de décrire C'est propre, c'est simple, et surtout efficace

C'est assez simple de faire un script PHP qui se met à jour des que la BD est mise à jour.
En fait tu stockes le nbre d'enregistrement dans une variable. Tu fais un script en AJAX qui s'exécute toute les secondes. Si le nombre d'enregistrement a changé alors tu rafraichis la page (en ajax cest encore plus propre) et tu stockes le nouveau nombre d'enregistrement.
Sinon tu fais rien.
J'avais fais ça pour un intranet et ça marchait plutot pas mal . La commande était affichée instantannément sans rechargement de page inutile, le seul "probleme" est que ça demande une requête par seconde. Faut voir si dans ton cas c'est un probleme ou non

Ez3kieL™ a dit:

C'est assez simple de faire un script PHP qui se met à jour des que la BD est mise à jour.
En fait tu stockes le nbre d'enregistrement dans une variable. Tu fais un script en AJAX qui s'exécute toute les secondes. Si le nombre d'enregistrement a changé alors tu rafraichis la page (en ajax cest encore plus propre) et tu stockes le nouveau nombre d'enregistrement.
Sinon tu fais rien.
J'avais fais ça pour un intranet et ça marchait plutot pas mal . La commande était affichée instantannément sans rechargement de page inutile, le seul "probleme" est que ça demande une requête par seconde. Faut voir si dans ton cas c'est un probleme ou non

Cliquez pour agrandir...

mmh, je sais pas, une requete par seconde c'est pas nécessaire, on va dire plutot chaque minutes voir chaque 3 minutes. Je connais pas encore toutes les possibilités d'AJAX si on sait configurer ca.

Mais je pense que je vais donc appliquer cette méthode (que le prog client initie les requetes et affiche le resultat des nouvelles commandes).

merci a vous

T'as plein de possibilités donc

n'aies pas peur du nouveau et de l'inconnu, c'est comme ca qu'on apprend

Il ne faut pas abuser de l'AJAX. L'utiliser pour un daemon est une solution assez bidon

Si on veux résumer tout ce qui s'est dit, c'est qu'il y a deux grandes architecture possibles (peut importe le langage ou les technologies que tu vas utiliser):

- le pull : traditionnel pour une application web, c'est le client qui va récupérer les données. Via un javascript ou un tag html dédié, tu fais rafraichir la page ou tu lances un bout de code (aussi en javascript) pour réexécuter la page entière ou récupérer les données pour les afficher. C'est traditionnel et simple à mettre en place (php, perl, python, jsp, ... combiné à du javascript si tu veux utiliser la technologie à la mode qu'est l'AJAX et ainsi ne mettre à jour qu'une partie de tes pages et non tout le contenu)

- le push : moins traditionnel dans le monde web (car par principe et par définition, l'utilisation du web n'est pas orienté session, càd que quand un client fait une demande, le serveur répond et oublie ce client. Tout mécanisme de session est simulé applicativement, mais n'est en rien un véritable mode "connecté"), c'est le serveur qui envoie les données à un client. Plusieurs manières de faire cela, la plus traditionnelle étant de créer un client lourd (application Java, .Net ou autre langage) qui va se connecter au serveur et "s'enregistrer" auprès de lui comme un "consommateur" d'évènements (ben oui, pour que le serveur puisse envoyer des données, il doit savoir qu'il y a un client qui écoute). Le serveur étant le producteur d'évènements.

Perso, à ta place, je ne m'embarquerais pas dans la seconde solution mais bien dans la première. Si ta préoccupation est la bande passante, tu peux soit réduire la fréquence de rafraîchissement, soit diminuer la quantité d'info transmisse à chaque fois en utilisant l'AJAX par exemple.

Good luck.

Y'a encore plus simple, le RSS :-9

Un RSS dynamique précisément.
Dès qu'une commande est validée, ça incrémente la table, le champs RSS se met à jour. Dès que la commande est réalisée, un bouton pour dire que la commande est accomplie, ou en cours, et là le message sur le RSS changera, tout simplement.

C'est une implémentation du pull, le client RSS va lire le feed régulièrement

ZorrObiwan a dit:

C'est une implémentation du pull, le client RSS va lire le feed régulièrement

Cliquez pour agrandir...

Disons que ma méthode est la plus simple, et ne limite pas les flux, c'est vrai. Faut voir le niveau de la personne qui va programmer tout ça.

Sinon il reste pour limiter un peu tout ça, les cronjob au niveau du serveur qui peuvent toujours être utilisé, toujours pour simplifier la programmation tout ça évidement.

Le but d'un informaticien, est tjs de faire au plus simple, le moins couteux possible, et là je pense qu'en heure de travail, avec ce genre de trucs, y'aura quasi rienà faire, à part le coté client.

Xyo_ a dit:

Disons que ma méthode est la plus simple, et ne limite pas les flux, c'est vrai. Faut voir le niveau de la personne qui va programmer tout ça.

Cliquez pour agrandir...

C'est tout de même une utilisation détournée car à priori, quand un feed est publié, il n'est pas modifié ou supprimé. Donc pas top.

Xyo_ a dit:

Le but d'un informaticien, est tjs de faire au plus simple, le moins couteux possible, et là je pense qu'en heure de travail, avec ce genre de trucs, y'aura quasi rienà faire, à part le coté client.

Cliquez pour agrandir...

Le but PREMIER d'un informaticien, c'est surtout de bien comprendre les besoins des utilisateurs, de montrer à ceux-ci qu'il les a bien compris et de fournir une solution qui répond effectivement à ces besoins.

Et si la solution qui correspond le mieux à ces besoins est de travailler avec une feuille de papier, c'est ça qu'il devra fournir, avec son mode opératoire ...

ZorrObiwan a dit:

C'est tout de même une utilisation détournée car à priori, quand un feed est publié, il n'est pas modifié ou supprimé. Donc pas top.

Cliquez pour agrandir...

Ce que je comprend pas dans son idée c'est surtout le fait de modifié le feed... Autant faire un bête flux rss avec la liste des commandes (donc un simple client rss ferait l'affaire pour vérifier les commandes)...

Maintenant faut voir si la société de bak veut que ça soit "fonctionnel" mais moins couteux ou si ils préfèrent quelque chose qui correspond totalement a leur besoin et personnalisé...

BaKa a dit:

Ce que je comprend pas dans son idée c'est surtout le fait de modifié le feed... Autant faire un bête flux rss avec la liste des commandes (donc un simple client rss ferait l'affaire pour vérifier les commandes)...

Cliquez pour agrandir...

Une commande, cela a un "état". Exemple: "en attente de traitement", "en cours de traitement", "traitée en cours d'expédition", "expédiée, en attente de paiement" et que sais-je.

Donc, j'ai le même problème que toi, pour moi le flux RSS n'est pas adapté pour "gérer des états"

Merci à tous pour vos idées, à la base de je voulais justement faire en sorte que le server informe le client, mais bon, je vais faire plus simple en faisant un refresh. Ajax rss, je verrai bien

un petit coeur à tous ceux qui m'ont répondu