Reprise du message précédent :

http://be2.php.net/manual/fr/funct [...] onnect.php
Et tu as la même chose pour la plupart des implémentations spécifiques en php...

c'est celui qui affirme qui doit prouver, tu affirmes, donc tu te démerdes pour nous le prouver, sinon tu te tais, point. Chuis pas facturé 1000? par mois, j'ai pas le temps

Presque.
 

 
C'est bien pour faire des transactions en environement mono-utilisateur...
 
A moins que tu crée un compte dans la base de données par utilisateur de l'application ? Quelle souplesse !
 
Drasche > Je suis pas facturé 1000 ? de la journée pour justifier mes choix, mais pour faire un truc qui marche. Mon boulot, je le connais, et je connais un minimum les limitations des différents produits sur lesquels je bosse. Si t'es pas d'accord avec ce que je dis, tu me prouve le contraire, j'ai pas à prouver que j'ai raison. Mais fait bien gaffe, parceque dans ce domaine précis, je connais assez bien mon affaire. Ca fait 5 ans que je bosse avec des ERP, des implémentations j'en ai vu, et je suis à plusieur reprises passé derrière des développeur qui n'avaient pas toujours fais les bons choix. Les miens ne sont pas forcément les meilleurs, mais ils ont l'avantage de reposer sur une expérience mûre, et sont ceux qui à ma connaissance posent le moins de limitations. Arrêtez deux minutes de me contredire juste parceque je vous dis que le PHP c'est pas adapté à ce type de softs.
 
Les défenseurs du C viennent pas emmerder les trolls de PHP en disant que le C est mieu que le PHP pour faire des sites. Pourtant que je sâche on peut faire des CGI en C, et ça marche très bien. Les trolls ça va bien 5 minutes maintenant.
 
Pour ce type d'appli, y'a qu'un programme de type SERVICE, donc en C ou autre langage compilé qui tienne la route, et tous les traîtements sur la base doivent passer par ce soft, point barre.

on est vendredi, je te pardonne
 
mais je maintiens que c'est à toi de me prouver que t'as raison sinon ça sert à rien d'argumenter et tu vas encore passer pour quelqu'un qui n'y connait quedalle (ce que tu fais très bien tout seul d'ailleurs )

Vous devriez créer un sondage pour clarifier cette situation..

... bon, pour votre putain de connection persistante, j'ai pas prouvé que j'avais raison en citant qu'il faut utiliser une chaîne DSN différente pour chaque utilisateur, sâchant que c'est pas gérable ?
 
tu veux que je te prouve quoi ? qu'une page PHP peut pas faire du café ? je besoin de le prouver aussi ?
 
en PHP on peut pas faire, ça va pas être écrit dans la doc, si ?
 
non, en PHP tu peux pas lancer un missile sol-air. c'est marqué dans la doc ?

et un dernier truc.
 
si un développeur sait pas faire, que ce soit en réalité possible ou non, ça revient au même, il ne le fera pas.
 
hors vu que vous êtes incapable de me prouver que j'ai tord, c'est que vous savez pas faire. hors si vous savez pas faire, dites-moi comment vous allez faire ? avec un appli compilée, ça se fait tout seul, parceque c'est fait pour. les connections sont forcément persistantes, tu peux gérer des files d'attente avec une simplicité enfantine, tu peux rigoureusement faire 100% de ce dont l'appli à besoin de façon très simple. je vois pas d'où vient cet entêtement à vouloir le faire en PHP alors que c'est pas adapté.

je laisse tomber cette conversation stérile.
 
continuez comme ça, vous irez loin. j'espère juste qu'à votre taff vous êtes moins butés

Yo, çà fight hard dans le coin !
 
MagicBuzz, je suis assez intrigué par ton histoire de transaction sur plusieurs pages. Si tu conserve la connexion en session, çà veux dire qu'il te faut autant de connexions que d'utilisateurs potentiel non ? Ce n'est donc envisageable que pour un intranet, et donc il n'est pas idiot d'imaginer que chaque utilisateur ait son propre identifiant de connexion.
 
Autre chose :
 
Pour info, il est tout a fait possible de conserver de objets en session. Il suffit de les sérialiser.
J'ai justement utilisé cette technique pour gérer des transactions. Mais pas au niveau de la base. Les écrans se succèdent, faisant évoluer l'état des objets manipulés. A la fin, soit on laisse tomber, soit réalise les modifs à faire en une seule transaction BD.
 
A+

Application Java (JSP/Servlet) déployée sur WebSphere Express, base de données DB2 Enterprise, transactionnel IBM SanFrancisco, impressions Crystal Reports, gestion des processus, batchs Java.

On est d'accord, commencer une transaction dans une page et continuer éventuellement plus tard dans une autre est trop aléatoire pour avoir un comportement correcte et sûr. Donc l'avantage d'ASP n'en est pas vraiement un... Pas taper, hein, de toute façon j'aime pas les transactions... J'aime pas demander à un DB de faire 10 insert 3 updates et 5 delete pour ensuite lui dire, heu, ben en fait non, c'est pas ce que je voulais.... Je dis pas que çà sert à rien, je dis juste que moi personnelement, çà me met mal à l'aise.
 
J'ai pas d'exemple de code içi sous la main. Mais le principe est simple. Disons que par exemple on va gérer une commande de matériel (un panier virtuel). Ben on a un objet Panier avec toutes les propriétés qui vont bien comme par exemple une collection d'objets Item qui sont les choses commandées. Pour enregistrer le panier en session, il suffit de sérialiser l'objet Panier. Toutes ses propriétés seront automatiquement sérialisées recursivement. Enfin, quand la commande est validé, il suffit d'appeler la méthose qui va bien pour créer la commande en une seule fois.
 
Bon, c'est un exemple à la con, dans la pratique je l'ai utilisé pour gérer des engagements qui sont un peu plus compliqués à décrire.
 
Si tu tiend absoluement à avoir un bout de code, je peux t'en pondre un...

ouais, nan là on parlait de PHP, pas de JSP
 
D'autant plus que les servlet Java peuvent être persistants, et donc être utilisés comme une application telle que je la décris, et non comme une succession de pages PHP qui nécessite la rééxécution de tout le code à chaque chargement (c'est ça qui pose problème)

 
perso, pour la gestion d'un panier, j'utilise une table "basket" dans laquelle je stocke tout mon bordel, et au moment de la validation, je le recopie dans la table "commande", c'est plus simple à gérer

 
Je t'ai dis que c'était un exemple à la con !
C'est juste pour expliquer le principe...
 
Cela dit, je préfère le système des sessions :
Un table avec un champs BLOB qui contients toutes les données de session.
Le nettoyage est automatique. (Par exemple les paramêtres de nétoyage ne sont pas les mêmes suivant que le visiteur soit un Internaute ou un Intranaute)
 
Si tu utilise des tables spécifiques, il t'en faudra (éventuellement plusieurs) pour chaque type de transaction de ton appli, et il faudra gérer le nettoyage de chacune.

Sans doute. Bon ben, il se fait tard.

http://www.onlamp.com/pub/a/php/20 [...] falls.html
 
désolé j'ai pas résisté à poster l'article

un petit composant MTS peut-être?

On est bien d'accord. On ne fait pas de transactions sur plusieurs pages !
Les transactions permettent de s'assurer qu'un ensemble de requêtes sont bien toutes réalisées. Mais çà consomme des ressources, et çà lock des tables. Il faut donc faire la transaction en une seule fois pour rapidement libérer les locks et les ressources.

1) T'as lu l'article ?
2) T'as compris l'article ?
3) T'es vraiment *** ou tu le fait vraiment exprès ?
 
4) Est-ce que j'ai dit qu'on pouvait pas faire de trasaction en PHP ?
 
Pour info j'ai dit :
 
ON NE PEUT PAS FAIRE DE TRANSACTION SQL REPARTIES SUR PLUSIEURS PAGES PHP
 
T'as bien lu ? T'as bien compris cette fois ? Tu veux que je répette ? Tu veux que je t'explique ?
 
Oui, ok, je vais t'expliquer.
 
Imagine.
 
Je veux créer un client.
Un client à au moins 3 adresses (qui peuvent être identiques), une pour la livraison, une pour la facturation, et une pour le contact commercial.
Un client travaille dans une société.
 
Je suis donc devant ma fiche individu vierge.
 
Ma transaction commence à ce moment.
 
On me demande de choisir une société pour le client.
Elle n'éxiste pas.
 
Je clique pour créer une nouvelle société.
Je remplis les champs.
J'enregistre. Je suis maintenant de retour à ma fiche individu.
Je choisi sa société.
Je remplis les 10 champs présents dans la page.
Je passe à la page suivante. A ce momet, j'enregistre les informations du client dans la base. Mais ni le client, ni la société ne doivent encore être visible pour les autres utilisateurs, puisque je n'ai pas fini de les créer.
Je ne commit donc pas mal transaction.
 
J'arrive sur la page 2 de création d'un client.
Je remplis les nouveaux champs, et on me demande ses adresses.
 
Je clique pour voir la liste de ses adresses. Il n'en a pas.
Je crée donc son adresse de livraison.
J'enregistre.
J'affecte l'adresse de livraison au client.
 
Puis je recommence pour les adresse commerciales et de facturation.
 
Maintenant que mon client est complet, j'enregistre et je commit la transaction pour que tout le monde puisse l'utiliser maintenant.
 
Mais si au dernier moment je m'apperçois pour une raison ou pour une autre qu'il ne faut pas créer cet individu, alors il faut que j'annule tout ce que je viens de créer, l'individu, sa société, et ses adresses. Au lieu de faire un commit, je fais un rollback.
 
C'est pourtant pas compliqué à comprendre si ?
 
Maintenant, je te laisse me faire ça en utilisant plusieurs pages PHP, et les transactions serveur.
 
Sans la "bidouille" de mara's dad, y'a pas moyen. Hors, sa solution n'est pas toujours adaptée à toutes les situations (là ça va). Si tu décides degérer ça à la main avec des flags dans tous les sens, ou des delete en cascade, tu as toujours le risque que l'utilisateur ferme son navigateur sans annuler (après tout, c'est la réaction typique d'un utilisateur : "je suis en train de faire une connerie, je ferme tout." )
Là, ton code pour nettoyer la base ne s'est pas éxécuté. Avec une transaction, au moment du timeout sur la transaction, le SGBD va automatiquement faire le rollback.
Et pour tes flags indiquant qu'une ligne d'une table ne doit pas être visible, je te laisse trouver un système qui tienne la route... L'utilisateur qui modifie doit voir les données. Pas les autres. Et ce, dans l'intégralité du code de l'appli. Cela implique que tu penses systématiquement à filtrer toutes les tables dans toutes les requête en vérifiant ce flag. C'est le meilleur moyen d'introduire des bugs, un oubli lors d'une jointure est bien vite arrivé.
 
Révise un peu la notion de transaction.
 
Et là où le système de Mara's Dad n'est pas applicable (sans se prendre la tête des dizaines d'heures à perdre son temps sur un code qui va devenir une usine à gaz) c'est si pendant la création d'un élément (une fiche produit par exemple), je veux pouvoir consulter depuis le front-office l'aspect de mon produit, sans que personne d'autre ne le voit. Une transaction te permet de faire cette isolation des données de façon implicite. Je te laisse gérer ça sur un site web, lorsque généralement on a deux sites distincts pour le front et le back (ça ne s'applique pas dans la problématique présente, je te l'accorde).
 
Cette fois t'as compris ? T'as fini ta mauvaise fois ?

Un client a fait un truc pas mal pour suppléer à cette carence et garder les applications web stateless: une DB dédiée au stockage d'objets sérialisés, accessible via une petite API toute simple, on sauve tout dedans jusqu'au moment où on est contents et on fait la transaction d'un coup à la fin. Bon maintenant pour gérer leur DB, j'imagine qu'ils ont un batch pour effacer ce qui part en timeout
 
Mais pour un truc léger, les sessions suffisent amplement pour gérer les données de page en page (le timeout de la session faisant le reste). Ah mais c'est ce que Mara's Dad vient d'expliquer je crois

 
J'ai jamais dit le contraire, y a que buzz l'éclair qui se prends le mou la dessus, mais de la à dire qu'on sait pas le faire à la dernière page en utilisant d'autres techniques (vu que c'est quand même lourd de bloquer les tables même si c'est pas une page web soit dit en passant) voir d'utiliser une extension (ohé du bateau) ...
 
Dommage que bon buzz l'éclair soit pas très zen
Mais c'est pas grave, je l'aime bien quand même
 
N'empêche qu'on discute toujours d'une usine à gaz proposée par monsieur pour un truc de 4 personnes sur un site local consulté uniquement par eux, waaah

oui, mais c'est valable que lorsque tu peux gérer en session.
 
mais si tu veux afficher une preview, bah t'as l'air malin avec la page d'affichage qui va chercher dans la bdd, et toi qui a tes valeurs en session... ça te demande de tout exploser ton code, ou alors de le dupliquer (et à ce moment laisse tomber pour la TMA ou les évolutions)
 
sinon, le truc que tu indiques est en effet possible, mais il faut aussi penser à gérer les contrôles de contrainte.
 
imagine, dans une table j'ai une société avec personne dedans.
 
je commence un client.
 
dans ma transaction, je l'affecte à cette société.
 
si une personne tente de deleter la société avant que je commit, il va se prendre un lock dans la tronche. donc moi je vais pouvoir continuer tranquillement ma transaction.
 
si on gère pas ça en session, la société disparaît. quand j'insère la donnée, la clé externe ne peut plus être respectée, et je plante. si j'ai pas prévu de rattrapper le coup en permettant d'avoir en session un client pendant que je re-crée une société, j'ai perdu tout ce que j'ai fait sur ce client.
 
je pense que c'est assez facile de cerner l'importance des travaux nécessaires pour émuler convenablement une transaction.
c'est en ça que c'est pas gérable. rien que pour émuler ce système de transaction, tu vas y passer 2 mois, sans compter qu'ensuite, sur chaque page, le code sera complexifié à mort, donc in-maintenanble.
 
après, tu peux toujours décider de faire ça comme un cochon, et te disant "bon, ça c'est un cas qui n'arrivera jamais, donc je le traîte pas". c'est en effet la solution de raccourci qui est choisie la plupart du temps, et c'est pas vraiment condamnable (c'est dégueulasse, mais son amélioration ne justifie pas la charge supplémentaire).
 
Seulement, quand on est dans la phase de spec comme ici, le boulot de l'analyste, c'est d'étudier les différents outils possible, afin d'avoir le moins à ce dire "bon, ça je peux pas le gérer, mais tant pis c'est pas grave de toute façon ça sert à rien".
en utilisant les outils convenables non seulement ça te permet de faire exactement ce que tu veux, mais en plus, de façon plus simple.
 
C'est comme décider d'utiliser MySQL pour ce type de projet. C'est possible. Seulement, sans triggers et PS, ou selon la version, sans carrément de relations entre les tables, tu augmentes considérablement la charge de boulot pour émuler ces fonctions manquantes, pourtant vitales à ce type de logiciel. Et il y a un fort risque d'oubli de contrôle dans un coin, qui va mettre en périle tout le système.

Je suis tout à fait d'accord pour que cette information entre en considération lors du choix final.
 
Mais par contre, je ne suis pas d'accord pour qu'elle soit la clé du choix de la plateforme. En effet, c'est idiot de se lier les mains et les pieds à une pierre au dessus d'un pont quand on peut opter pour une solution qui ne sera pas forcément plus difficile à mettre en place, et qui nous permettra le cas échéant de gérer les choses de façon plus poussées ou plus sûres si le besoin s'en fait sentir à un moment.
 
Aujourd'hui, ils sont 4. Mais demain, il peuvent être 100, tout comme demain, tu peux décider de réutiliser ça pour une entreprise de 1000 personnes.
Sans parler du fait qu'ils peuvent décider de faire une partie public à leur système, afin de gérer par exemple des appels d'offre ou autres, et à ce moment la charge s'en trouvera très fortement impactée.
 
Personnellement, je suis partisan d'analyser à l'avance :
 
1) Le besoin de l'utilisateur
2) Les besoins nons définis qui seraient succeptibles d'avoir été omis par l'utilisateur (simplement parcequ'il ne pensait pas ça possible ou parcequ'il n'y a pas pensé)
3) Les besoins futurs en imaginant une évolution de leur fonctionnement (aujourd'hui, une appli pour gérer des prestataires, pourquoi pas demain un outils de gestion RH complet ?)
4) Définir l'impact au niveau des développement pour implémenter ces différents besoins, ou prévoir à l'avance leur implémentation (modèle de données évolutif, programmation modulaire, etc.)
5) Choix de la plateforme en fonction des besoins choisis, et des besoins "probables", et de la complexité de la mise en oeuvre.
 
Donc oui, souvent on a un choix de plateforme surdimensionné, mais cela évite que pour un lot 2 par exemple, on fasse exploser la charge, parcequ'on doit changer de plateforme, ou repenser l'intégralité de l'outil.
 
Et c'est dans cette optic qu'une appli client/serveur me semble bien plus apte à répondre au besoin de ce topic, même si dans l'état, une simple base access distribuée avec 3 formulaires est LARGEMENT suffisante, et peut se faire en 2 jours (après tout, quite à choisir un truc tout pourri mais qui répond aux besoins, autant prendre le plus minimaliste et le plus simple)

Tout à fait d'accord. Il faut revenir à du factuel.

 
T'es pas très juste, un truc php tiendra bien la route même pour 1000 personnes et une boite avec plus de 10 comptables ou assimilés en même temps déjà ca fait un peu beaucoup non? alors 100 voir 1000 bien sur
 

Non, c'est pas vrai, pour les X raisons que je me suis égosillé à dire depuis hier.
 
PHP n'est vraiment pas l'outils adapté pour faire ça.
 
Une voiture de rallye, ça va très vite et ça tiens très bien la route.
Seulement, si tu la met sur un circuit de F1, bah tu vas faire des temps de merde, parceque c'est pas prévu pour.
 
Très franchement, on a rigoureusement le même problème ici. PHP impliquera d'importantes limitations dans les fonctionnalités.
Et si on cherche à réduire ces limitations en faisant une implémentation plus complexe, on va perdre tout l'intérêt de rapidité de développement.
 
Je suis profondément convaincu qu'une version client/server, pourquoi pas en Java (comme ça, ça permet de gérer la GUI en JSP sans surcoût notable de développement) est largement plus adaptée.
 
Et pour que je dise ça, faut vraiment que je sois convaincu que c'est une meilleure solution... Parceque autant j'aime pas PHP, autant le mot java me donne des hauts le coeur (t'ain j'ai une poussée de bouton là )

et il prouve une fois de plus qu'il ne sait pas de quoi il parle
 
(client/server <--> jsp)

 
on doit pas avoir la même notion du client/server alors... pour moi un applicatif web n'entre pas dans la famille du client/server, même si ça s'en rapproche.

ben oui pour moi non plus !!
or tu as dis que tu prefererais faire du client/server pour ce soft, quite à faire la UI avec des jsp !
 

 
de toutes manières, le libre vaincra :
 
http://www.01net.com/article/223540.html

Avant de me contredire, regarde comment Oracle Application est fait. Merci.
 
C'est une appli client/server, mais ça repose quand même sur du JSP pour la GUI.

Je vois pas trop le rapport. Même si ce topic ressemble de plus à plus à un troll, c'est pas la poubelle du forum.

Euh, essayez de tous vous calmer un peu, et de rester courtois hein

Je suis d'accord avec harko.
Cà sert à rien de dire à quelqu'un que ce qu'il écrit, c'est des grosse conneries et qu'il ferait mieux de se renseigner avant de la ramener !
Si on est pas d'accord, il faut expliquer pourquoi. Donner des exemples, discuter quoi. Dès qu'on s'emporte, on est plus objectif.

Ouais, et du coup ils ont utilisés une JVM dépassée, propriétaire, ultra instable et ils l'installent dans windows en modifiant les 3 path système pour mettre leur crasse AVANT tout, histoire de bien bloquer toutes les applications. Et je ne parle même pas des merdes quand il faut installer un BDD oracle sur un Xserv ou un iris...
 
Très bon exemple.

 
vous avez le pax en belgique?

Joyeux noël.
Merci pour ce joli cadeau de noël.
Je vais l'encadrer, je le déballerai plus tard.
 
PS: tu peux m'expliquer en détail quel est le rapport entre le fait que leur façon de développer ne te convienne pas, et le choix de l'architecture ?