Version imprimable
[EDIT 3DArchi] : fork de la discussion Le langage D sur cet aspect particulier : Le C++ est-il adapté pour le WEB ? [/EDIT -EDArchi]
Enfin c'est vrai que le gros manque (enfin perso ça me manque pas du tout ^^) de C++ face à java et C# c'est qu'il est pas du tout tournée vers le développement web, or c'est vrai que tout tends vers ça aujourd'hui... (même les jeux justement, comme quake par exemple).
En quoi le C++ n'est-il pas tourné vers le Web ?Citation:
Envoyé par Goten
C'est plus un problème de bibliothèque que de langage, non ?
Merci pour vos réactions, c'est intéressant ;).
Le C et le C++ ne sont pas trop tournés vers l'interface, le web en est un aspect...
Francois
Moi je parlais en comparaison de asp ou autre techno web du framework .NET ;).
A part deux ou trois librairies CGI il faut bien reconnaître que le C++ n'offre pas grand chose dans le développement web si on le compare par exemple à Java ou .Net qui proposent des frameworks à base de composants gérant la majeure partie des problèmes liés au session et à AJAX.Citation:
Envoyé par Florian Goo
Est-ce que c'est juste une histoire de biliothèque? Pas à 100% car la majorité des frameworks de présentation à base de MVC utilisent la réflexion qui n'est pas facilement disponible en C++, je dis pas qu'il est impossible de s'y prendre autrement mais c'est un élément, tout comme la capacité d'un serveur d'application écrit en java à charger dynamiquement, de façon sûre et aisée une autre application java pour servir des requêtes sans laisser les éventuels fautes de celle-ci le faire tomber.
Je dirai qu'en général, le C++ n'était pas vraiment idéal pour tout ce qui est application de gestion en fait, vous connaissez beaucoup d'ORM digne de ce nom en c++? Non? Peut être encore une fois l'absence de la réflexion dans le langage?
Il y a-t-il besoin d'avoir 50 frameworks ? Le nombre important n'est-il pas le signe qu'aucun n'en vaille la peine ?
Accessoirement, il est à noter les existences de :
- Wt: http://www.webtoolkit.eu/wt
- Cpp CMS: http://cppcms.sourceforge.net/wikipp/en/page/main
Quant au MVC, dans certains frameworks chez les voisins qui on le vent en poupe comme GXT, je le cherche toujours.
Dans GXT, les bindings des champs d'un modèle sont d'ailleurs ... écrit à la main. Besoin de la réflexivité ? Bouaif. Rien qu'un script perl et un petit DESL ne puisse résoudre.
Non ça c'est un hideux foutoir et je préfère 1500 fois l'approche .Net avec tout qui tourne autour d'ASP.net.Citation:
Envoyé par Luc Hermitte
Mais ça prouve que le langage est populaire pour ce type de projet.
Je dis pas que ce n'est pas possible mais que l'offre est très limitée.Citation:
Quant au MVC, dans certains frameworks chez les voisins qui on le vent en poupe comme GXT, je le cherche toujours.
Dans GXT, les bindings des champs d'un modèle sont d'ailleurs ... écrit à la main. Besoin de la réflexivité ? Bouaif. Rien qu'un script perl et un petit DESL ne puisse résoudre.
Histoire d'être clair, je vais commencer par une critique (parce que j'aime bien critiquer) et je terminerais par quelques arguments sur le sujet principal.
Bon, dans un premier temps : est-ce qu'un ORM est vraiment une bonne chose ? Dans ma vision (peut être un peu limitée), les ORM ne sont pas vraiment la panacée - ils offrent au programme la possibilité d'attaquer le modèle physique de la base de donnée. Or ce modèle physique est peut être très bon pour une base de donnée, mais nettement moins bon dès lors qu'on parle de conception orientée objet. Je ne vois pas pourquoi je devrais continuer à manipuler une notion de table dans mon code C++ (ou C#, ou Java). Dans mon esprit, les ORM répondent mal à une question qui ne se pose pas. Et visiblement, je ne suis pas le seul à avoir des problèmes relationnels avec les ORM.Citation:
Envoyé par _skip
Dans un second temps : LiteSQL, DTL et OpenORM sont des ORM C++. Donc : ça existe, même si certains (notamment OpenORM) ressemble à s'y méprendre à des usine à gaz inutilisable (mais bon, c'est aussi le cas de certains ORM Java, et pas des moindres...). Dans le domaine, celui qui me semble le plus probant reste LiteSQL.
C'est vrai que le C++ est le parent pauvre du développement web. Pour moi, la principale raison est purement historique, et pas du tout technique. Java n'est pas plus adapté que le C++ au développement d'applications coté serveur, alors pourquoi Java est plus employé ? La question de l'hétérogénéité des architecture ne se pose pas vraiment : en fait, les architecture sont souvent tellement hétérogène qu'il arrive que deux versions de Java tournant sur des serveurs différents utilisé dans la même application n'offre pas les même fonctionnalités et soient sur certains points incompatibles (vu avec GNU vs Sun). Je ne pense pas non plus que le problème soit lié aux fonctionnalités du langage : dans le cadre d'une architecture objet propre, la réflexion n'est pas un outil à utiliser (son utilisation suppose que le comportement de l'application change selon les caractéristiques physiques d'un objet, ce qui contrevient aux principes OCP et LSP). J'ai même l'intuition (mais ça n'est hélas qu'une intuition; pas de preuve formelle, pas d'arguments à opposer, ...) que la réflexion est un outil dont la puissance est directement liée à sa non-utilisation ;) Les programmeurs ont très bien vécu sans réflexion pendant des dizaines d'années, et ont résolu les problèmes que cette absence leur posait de manière élégante. Et sii on enlève la réflexion, Java devient relativement limité (en termes syntaxiques) par rapport au C++. Donc exit le problème de fonctionnalités liées au langage.
Alors pourquoi y a t-il plus de framework web Java que de framework web C++ ?
Rappelez vous les débuts de Java. Sa première utilisation grand publique a été de permettre le développement d'applets qui s'exécutaient sur le poste client. Vous vous en souvenez ? A l'époque, la génération dynamique de pages (donc coté serveur), c'était des scripts perl, shell ou des programmes compilés utilisant le protocol CGI. D'ailleurs, à cette époque, la plupart des pages servies étaient statiques, l'interactivité étant résolument coté client - pour le meilleur ou pour le pire. Etre programmeur web, cela signifiait donc :
- être capable de "programmer" en HTML
- connaître un poil de JavaScript
- être capable de réaliser des applets Java.
Un peu court... Le fait est que les programmeurs web étaient plutôt mal considérés. En 1996, les gens haut placé se demandaient pourquoi on formait des ingénieurs au métier du web - ça n'avait pas de sens, tant on avait dans l'idée que les métiers du web étaient simplistes (après tout HTML, c'est pas ce qu'on a fait de plus complexe...)
Alors que moi j'engloutissais du C et du C++, mes collègues en promo Metiers du Web (qui, pour beaucoup, n'aiment pas la programmation et avait espéré s'en tirer à bon compte en choisissant cette spé) apprenaient donc HTML, JavaScript et Java.
Fast forward (quelques années plus tard) : le web explose. De nouvelles technologies sont nécessaires pour stocker et traiter de nouvelles informations. Le futur n'est plus au pages web statiques, mais aux sites entièrement générés dynamiquement. Il faut que les technologies évoluent.
Les gens en place dans le métier sont ces ingénieurs formés quelques années plus tôt. Pour eux, Java est un choix naturel - on leur a confirmé pendant des années que c'était un langage simple. Depuis 96, le langage a fait des progrès et a démontré sa versatilité. Et puis, dans le domaine du Web, Java est un langage nettement plus utilisé que les autres langages de programmation (a cette époque, la très grande majorité des fanboys Java sont des programmeurs Web ; on appelle ça la dissonance cognitive...). Avec un gros vivier de programmeur Java qui (étrangement) ne se sont jamais intéressé à d'autres langages que Java, il n'est pas illogique que rapidement, on voie fleurir des outils permettant de programmer coté serveur en Java. Au niveau technique, Java n'est pourtant pas (à l'époque) ce qui se fait de mieux en termes de rapidité de traitements. D'ailleurs, les moteurs de recherche de l'époque sont généralement basés sur des CGI.
Mais ça y est : les graines sont semées. De dominant coté web client (ou l'utilisation de Java a un intérêt, ne serait-ce que pour supporter les différentes plateformes), Java passe à dominant coté serveur (ou sa prétendue portabilité n'a strictement aucune influence). Des apprentis designers logiciels créent des monstruosités qui sont étendues par d'autres, devenant des quasi-standard dans le domaine du web et hop, on se retrouve aujourd'hui à parler d'ORM et de framework web MVC - alors que dans l'esprit d'un designer logiciel sain, ces deux choses ne sauraient exister.
Mais c'est une autre histoire.
Pour résumer, ce n'est pas l'excellence technique de Java qui a fait que le langage soit adopté en masse et qui a produit le développement des frameworks utilisés de nos jours ; c'est l'adoption par les développeurs web de cette technologie coté client qui a poussé au développement des frameworks cotés serveur qui a poussé à l'adoption en masse. Et curieusement au détriment d'un seul type de langage informatique : les langages compilés nativement - au profit de langages qui, à l'heure actuelle, sont de plus en plus compilés en byte code avant d'être compilés nativement grâce à un compilateur JIT.
Il y a 5 ans, l'idée qu'on pouvait réaliser un site web avec des CGI était complètement absurde - il faut un langage scripté ou un langage basé sur une VM. Pourtant, à bien y réflechir, je ne voie aucune contre-indication à l'utilisation de programmes binaires natifs pour la génération de pages web.
Vous en voyez vous ?
L'existence d'une machine virtuelle (vm) facilite l'intégration de programmes tiers (applets) dans les navigateurs non?
Si tu veux parler de cet article de SQLPro qui compare des procédures stockées écrites par un expert SQL aguerri à une couche client faite par un idiot qui sait pas ce qu'il fait, ce sera sans moi. Je suis suffisamment intervenu sur le sujet en question.Citation:
Envoyé par Emmanuel Deloget
Pour le reste je me tiens à l'écart, mon post a été déplacé ici, tout ce que j'ai voulu faire c'était relever le fait que l'offre C++ sur le développement web était limitée et que l'informatique de gestion s'était déjà tourné vers autre chose.
Ce n'est pas de mon ressort de dire pourquoi ça s'est fait comme ça ou pas autrement, les choses étant ce qu'elles sont si on me demande ce que je recommande pour le développement d'un intranet avec base de données, ça me vient même pas à l'idée de considérer C++.
Dans le même ordre d'idée, cf les initiatives comme GWT qui ... compilent du Java en javascript.Citation:
Envoyé par Emmanuel Deloget
Il n'y a pas d'impossibilité, mais la charge sur de telles appli est bien souvent sur le réseau et la BDD, plus que sur l'appli elle même. On a donc interêt à utiliser un langage bien plus permissif que C++, quitte à y perdre sur d'autres points.
Je ne vois pas ce qui empêche de faire des applis web en c++.
A part peut être que des dixaines de solutions, plateformes, frameworks et langages sont spécialisés pour ce genre de job (et que ça marche quand même).
Mais bon, quand un composant s'avère valoir le coup, il finira par être implémenté en c ou c++ et une ribambelle de bindings viendront graviter autour.
Oui mais ça, c'est coté client - et c'est complètement justifié, ne serait-ce qu'au niveau de la gestion de l'hétérogénéité des plateformes cibles et au niveau sécurité.Citation:
Envoyé par r0d
Une question purement naive : est-ce que la gestion de la mémoire (et donc des strings notamment) peut être un problématique de performance comparé aux languages sous garbage collector dans le type de cas d'applications web totalement générées?
Je sais que le fait d'être au controle de la memoire est déjà rédibitoire pour l'essentiel des développeurs web, mais si on omet ça deux minutes, est-ce qu'il y a un quelconque impact sensible (positif ou négatif) niveau performances qui irait contre l'idée qu'ont peu baser un site web sur du C++?
Pas à ma connaissance - ça serait bien le premier cas ou on me dirait "C++, c'est trop lent pour ce type de traitement".Citation:
Envoyé par Klaim
C'est vrai qu'une application web gère énormément de chaines de caractère. Ceci dit, c'est vrai - qu'on soit en C++ ou en Java. Je ne pense donc pas que la gestion de la mémoire associées à ces string soit plus problématique en C++ qu'en Java. Si toutefois cela s'avère être le cas, on peut toujours trouver une autre solution (basée par exemple sur un allocator spécifique ; certains sont très performants dès lors qu'il s'agit de gérer des petits blocs de mémoire très volatiles).
Salut,
Je vois une autre raison 'historique' à l'absence d'utilisation du C++ pour le web. Au tournant des années 2k, quand le web a explosé, il n'était pas rare d'avoir un bel écran bleu avec un programme natif. Je ne sais pas si la fréquence était la même avec un programme tournant sur une VM. Bien sûr cet argument reste moins vrai aujourd'hui.
Le C++ est-il adapté au oueb aujourd'hui ? Ben j'aurais une réponse de normand : le C++ n'est adapté à rien mais permet de faire tout. C'est sa faiblesse et sa puissance. Après, concrètement, c'est bien l'historique qui pèse dans ce genre de prise de décision. Une boîte ne va pas (re)former tous ses développeurs vers un nouveau langage et des bibliothèques spécifiques pour un gain pas évident. Le problème de perf ? Ca coûte moins cher d'acheter un nouveau serveur + boosté que 5 jours de prestations. Le calcul est vite fait.
Ensuite, je n'ai pas l'impression qu'il y ait de framework/bibliothèque 'référence' pour faire du dev oueb en C++. Tout refaire serait absurde. Choisir une plateforme plutôt qu'une autre pose différents problèmes : formation des développeurs, stabilité de la plateforme, support disponible, pérennité ?
J'ai entendu beaucoup de biens de Wt (notament sur stackoverflow.com) mais jamais essayé.
Sinon, je viens de me rappeler autre chose en rapport avec les strings, qui pourrait avoir rebuté l'essentiel des programmeurs web : le manque de standardisation de la gestion des caractères unicodes dans le language (corrigé dans C++0x a priori).
Je ne suis pas sur de l'impact que ça peut avoir, ce n'est qu'une autre supposition naïve.
Quel argument de choc! Ca me parait un peu gros, à moins que tu ne fasses allusion qu'au monde de Windows? (sans troll, juste par rapport au blue screen)Citation:
Envoyé par 3DArchi
Plus prosaïquement, le manque de sécurité offert par un programme natif : si un attacker arrive à faire planter le programme, risque-t-il de faire flancher le serveur aussi ? AVec les OS Windows d'il y a quelques années, c'était quand même plus que probable. Tandis que faire planter la VM (et donc arriver au même résultat) c'est quand même plus compliqué.Citation:
Envoyé par metagoto
Le fait est que maintenant, la plupart des gros serveurs webs sont virtualisés. Si une machine virtuelle plante, on la redémare et hop, ni vu ni connu. Et faire tourner une VM sur une machine virtuelle (ça se fait ; gamedev.net est géré comme ça, si je ne me trompe pas. Le site est en C# et tourne sur plusieurs serveurs IIS virtualisés), c'est prendre le risque de dégrader les performances par rapport à du code natif (qui, avec la virtualisation hardware, sera à priori plus performant).
Donc, a vous lire, on serait dans une époque où il n'y a plus de bonne raison de ne pas utiliser le C++ pour du web?
Ben personnellement, je le pense. Maintenant, j'ai quand même peur que ça n'apporte pas grand chose par rapport aux solutions existantes. J'essaie de voir si pour certains cas d'utilisation le C++ aurait un intérêt particulier par rapport à un serveur Tomcat et un framework adequat, mais j'ai un peu de mal :)Citation:
Envoyé par Klaim
Ceci dit, au niveau technologique, le C++ est très certainement adapté au medium.
L'intérêt premier que je vois à utiliser c++ coté server est la facilité d'interfaçage avec la myriade de librairies et systèmes qui ont, pour la plupart, une api native en c ou c++.
C'est un réel avantage comparé à python, ruby ou php (je ne me prononcerais pas pour java ou c#) qui n'ont pas toujours des bindings uptodate et/ou exploitant les services ciblés dans les meilleurs conditions. Encore faut-il avoir un intérêt à utiliser un service dans les meilleurs conditions, ce qui n'est pas forcément le cas pour une appli web. Il y a d'autres facteurs inhérents qui ont été évoqués (ping, bande passante etc)
Je pensais effectivement à NT qui, s'il était le plus stable des windows de l'époque, pouvait être planté par un programme un peu maladroit. En revanche, aujourd'hui ça fait très longtemps que je ne vois plus une appli planter windows.Citation:
Envoyé par metagoto
Je déterre le fil pour lui rajouter un lien.
Hier, je suis tombé là dessus: du Qt dans un navigateur via le projet Native client de google.
Si je comprends bien il semblerait que l'on disposera ainsi d'une machine virtuelle qui permettra de faire tourner des programmes "natifs" dans des navigateurs.
Oui c'est l'idée, et je trouve ça assez énorme. C'est tout récent en plus. Y'a ca pour avoir des "clients riches" et Wt pour la génération de webservices, c'est un bon début ;)
A propos de client riche, j'utilise ça pour les interfaces de mon jeu, effectivement c'est très efficace, mais je pensais qu'on parlait principalement des technologies server (type Wt) pour les application web, pas forcément coté client où on a déjà des tas de solutions en C++.
edit> Ah non j'avais compris l'inverse du Native Client, c'est bien un client embarqué dans une page web, pas comme l'exemple que j'ai donné... au temps pour moi. :)
En listant la mailing list de boost, je suis tombé sur une référence à CppCMS: http://cppcms.sourceforge.net/wikipp/en/page/main
Ca semble très interessant dans le domaine. A voir ce que ça donne.
Par contre, comme indiqué dans le Rational, c'est interessant uniquement pour des souci de performance.
-> #6Citation:
Envoyé par Klaim
:P
Tes ellipses sont parfois déroutantes :( Qu'entends-tu par '#6' ?Citation:
Envoyé par Luc Hermitte
numéro de post ... :
http://www.developpez.net/forums/d84...b/#post4833161
C'est ça. :)
Oups, désolé :aie:
C'était pourtant évident
:ccool:
le post numero 6 de ce fil.Citation:
Envoyé par 3DArchi
Bonjour,
Je crois que que l'expression "déterrer un sujet" n'est pas de trop ici ! :)
Je me permets de relancer ce sujet, au vu des nombreuses nouvelles technologies qui sont apparues depuis 2010.
Tout d'abord je voudrais signaler que je suis encore étudiant en école d'ingé, donc svp ne hurlez pas s'il y a des aberrations dans ce post, je n'ai clairement pas encore assez d'expérience pour que tout ce que je vais dire soit 100% juste... mais je vais faire de mon mieux ;).
J'ai développé dans une société pendant 6 mois en PHP (avec le framework Symfony2). Il m'a semblé alors que le principal souci du PHP c'est ... le PHP. J'entends par-là que si les framework PHP sont très "pros" à mon goût (je n'ai cependant pas fait de Perl / .NET / Ruby pour pouvoir comparer), surement dû à la longue histoire du PHP dans le web, dès qu'on veut faire un peu de calcul (de vrai calcul, avec de l'algèbre et tout, ce qui est mon cas actuellement), il faut plonger dans la doc ancestrale des librairies PHP, et on n'est pas sûr d'en sortir un jour...
Je me suis ensuite mis au Python, que je trouvais alors simplement génial. Déjà pour sa syntaxe très épurée et intuitive, et aussi (surtout) pour ses bibliothèques très performantes (pour ne pas citer Numpy, Matplotlib, Pandas...), répliquant à la perfection le fonctionnement de gros logiciels de calculs comme R et Matlab, ainsi que les biblis très récentes liées aux nouveaux modèles comme le Machine Learning (Scikit).
Le souci, c'est que j'ai toujours été beaucoup trop puriste dans mon code, passant plus de 80% de temps en refacto pour trouver la meilleure façon de faire les choses... la conclusion qui m'est apparue il y a quelques jours est qu'il est simplement impossible de faire quelque chose d'aussi 'propre' en Python qu'il n'est possible de le faire en Java et surtout qu'en C++ (j'avais étudié les deux en école). Cela pour des raisons évidentes, dont par exemple le "typage dynamique" (aka "absence totale de typage", ou encore "tkt ça passe"), l'héritage multiple (ok, il y est aussi en C++), l'absence de gestion de la mémoire, etc.
Bref, j'arrête de digresser et en viens au sujet : depuis le dernier post de cette discussion, on a vu l'apparition de JS côté serveur avec Node, faisant preuve d'une rapidité assez impressionnante (pour de l'interprété) grâce au moteur V8 de Google, à la suite de quoi d'autres technos hallucinantes ont vu le jour (comme React ou Meteor, qui permet de générer d'un coup l'appli Android + l'appli iOS + l'appli web, tout en 'simulant' un accès à la DB côté client, et tout ça uniquement en JS).
Cependant, le débat est toujours d'actualité : le C++ est-il toujours aussi adapté (ou plutôt toujours aussi mal adapté) au Web ?
D'après vos réponses (ultra intéressantes pour la plupart), la conclusion laissée en suspens semblait être que le C++ pourrait très bien être employé (il semblait même l'être bien plus en 2010 qu'avant 2000), cependant les autres technos sont "plus adaptées" et proposent plus de biblis, de frameworks, d'outils, etc. (autre débat : ces outils sont-ils rééllement indispensables ? L'article sur la pertinence des ORMs est aussi très intéressant).
Mais le problème de la performance est toujours là ! Je ne peux croire que le JS (même avec un moteur 16 cylindres en V8) parvienne à dépasser du compilé (même s'il semble d'après vos réponses que la plupart de la complexité en temps dans le Web est dû à la DB et au réseau, c'est un autre débat).
Quelque chose a-t-il changé depuis 2010 ? Les autres technos ont-elles pris tellement d'avance qu'il est désormais impensable d'utiliser du C++ ? (pourtant on voit toujours un sacré paquet de .NET !). Ou bien les frameworks que vous avez cités (comme Wt ou CCP CMS) se sont développés et proposent maintenant de réelles solutions alternatives ?
Merci pour vos réponses !
Maintenant j'ai entendu parler de node pour lancer des modules écrits en C++.
L'avantage de node c'est surtout sa facilité et rapidité de mise en place d'un serveur.
Mais dans le cas de serveur de jeu, pas de simples servers webs.
Salut,
alors j'ai pas suivi la discussion d'antan donc je vais peut-être dire des trucs déjà dits.
Perso (enfin au taff) on utilise encore beaucoup le C (pas ++) pour des appli web.
On a bien évidemment les éternels CGI, mais aussi des appli lourdes et des services sur les serveurs, tout en C.
Maintenant faut voir le besoin : si t'as des traitements lourds à faire, des CGI derrière un serveur HTTP c'est très bien.
Les cas où il faut coder le serveur en lui-même (quelque soit le protocole choisi) est quand même assez rare.
Dans le cas du HTTP il existe des serveurs déjà faits qui offrent très peu de fonctionnalités pour un maximum de perf.
Cela fait quelques jours que je parcours les forums de ce site pour trouver l'emplacement adéquat pour exposer un des me projets, sans vraiment trouver. Puis ce fil, dont le sujet est proche de l'objet de mon projet, a été réactivé. Je tente donc ma chance ici, en espérant que cela ne contrevienne pas aux règles de ce site.
Il y quelques temps, j'ai conçu un système qui permet de développer en C++ une interface desktop qui s’appuie sur des technos web. Les technos web étant très répandues, et moi-même n'ayant que des compétences très limitées dans ce domaine, cela permettait de trouver facilement des personnes à qui déléguer le design de l'interface.
Du fait de l'utilisation de ces technos web, je me suis dit qu'il devait être facile d'utiliser cette interface desktop pour en faire une interface web. J'ai donc développé, toujours en C++, quelques outils en ce sens que j'ai mis en œuvre, à titre de proof of concept, dans une application, dont la démonstration en ligne est accessible ici : http://q37.info/xdh/orgnzq.html.
Le principe général, c'est qu'à chaque événement susceptible d'être déclenché à partir d'une page web, est associée une fonction C++. Cette fonction va, pour ce qui est de l'interface, générer un flux au format XML contenant les données à afficher. Ce flux XML est envoyé au navigateur web associé à une page XSL, que le navigateur web va appliquer au flux XML pour générer la page HTML à afficher.
De mon point de vue, par rapport à la question à l'origine de ce fil, à défaut d'être adapté, je trouve que le C++ est facilement adaptable au développement web, comme j'espère l'avoir démontré avec cette application. Ceci dit, comme je n'ai jamais développé d'application web en tant que telle, j'ignore si ma solution est viable, et comment elle se place par rapport à d'autres solutions, éventuellement basées sur d'autres langages.
Pour ce qui voudrait en savoir plus, vous pouvez consulter ce billet sur le sujet. Si vous avez des questions spécifiquement sur cette application, j'y répondrais volontiers. Le cas échéant, je pense qu'il vaudrait mieux que je crée un fil dédié, mais j’ignore quel est le forum le plus adapté...
Bonjour, pour donner suite à la conversation je viens des Ordinateurs propriétaire IBM , j'ai conçu des applications en natif (RPGIV...) pour le web ..... aucun souci de performance etc.....
aujourd'hui je suis à la retraite , et je m'amuse à reproduire l'équivalence sur pc/serveur .... étant habitué de très longue date j'ai repris la méthode Proof une méthode qui dans les années 70 à fait ses preuves et qui disait un écran = une fonction = un programme = un traitement formulaire.
en partant de ce schéma j'ai cherché ce qui était le plus approprié tant performance , sécurité, fiabilité, simplicité.
HTML/JSON couplé JQUERY , template , du CGI , et bien-sur du c/c++ , cela est en adéquation lorsque je fais appel à des base de données dont les données sont partageable et chacun sait oh combien il est important de géré les lock ... les traçages de sécurité pour le client,la mise en ligne fiable.
j'ai été obligé de refondre la méthode d'accès aux données aux programmes afin qu'elles soit facilement identifiable commune et répondant à un suivit de DBA ,
tout fonctionne .....
Aujourd'hui je me penche sur une relation de traitement websocket chose simple et performante .... on peut développer en C++ , j'en arrive à ma conclusion c'est de développer un framework une sorte d'outil pour générer l'intendance ce que j'appelle pisser de la ligne toujours les mêmes principe, une fois fait on trouve les programmes très épurés et facile a lire ne s'occupant que du métier.
les pages son générés à la volés, il n'y a pas d'interprétation , les objets sont compilés , le serveur de BD est hors d’atteinte, le serveur web Apache a fait ses preuves ,
gestion de stock , de livraison , de demande de livraison , de suivit de traçabilité avec information pour les services des fraudes.
les commandes sont fait par des applications traditionnel interactive GTK/C++ et communique ou plutôt sont en symbiose avec les applications web, enfin de compte les applications web sont la mise à disposition; un déport d'informatique du client pour que la fabrication soit a disposition avec un maximum de suivit.... exemple Fnac, Renault ....
Ah j'allai oublier ce sont des sites pour des industriels qui ne veulent pas de complication et passer le moins de temps possible sur ses écrans , donc des écrans épurés dont le fonctionnement répond a une charte et pas a un jeu (hihi) bref du pur et dur .... pour eux il ne fallait pas sortir de polytechnique pour utiliser le site.
@bientôt