Outils de developpement

[JF Messian]

Bonjour,

Il serait temps d'arrêter de faire du copier/coller... je m'explique...

Une part non négligeable de mes développement consiste à gérer des
formulaires pour entrées des informations et à mettre en place des
scripts permettant de retrouver les informations entrées dans la base de
données.

Concrêtement, je construit des formulaires dont les champs ont les mêmes
noms que ceux de la base de données, je les récupère et je les stoques.

De l'autre côté, je mets en place des requêtes (souvent les mêmes) pour
afficher les infos.

BREF : je fais beaucoup de copier/coller intelligents... enfin j'essaie
!

Il existe surement des outils logiciels pour gagner un peu de temps, non
? Je précise que je suis sur mac os x...

Merci.

[Thief13]

C'est à ça que servent les fonctions, éviter de faire du copier coller.
Tu fait un code générique, qui utilise des paramettres pour les truc qui
changent, et tu passes les paramettres à la fonction, pour le code dont
tu as besoin.

[JF Messian]

Post by Thief13
C'est à ça que servent les fonctions, éviter de faire du copier coller.
Tu fait un code générique, qui utilise des paramettres pour les truc qui
changent, et tu passes les paramettres à la fonction, pour le code dont
tu as besoin.

Oui mais par prenons un exemple simple :

J'ai une base MySQL avec la table ayant les champs nom, prenom, adresse

Je vais alors avoir un formulaire HTML avec pour simplifier :

<input type="text" name="nom">
<input type="text" name="prenom">
<input type="text" name="adresse">

et pour finir un script php avec :

insert into table (nom,nom,nom) values ('$ nom','$ prenom','$adresse') ;

ce qui serait sympa c'est d'automatiser un peu tout ça...

[Thief13]

Je ne vois pas ce qui t'empeche de faire une fonction que tu pourras
réutiliser pour d'autres script...

[JF Messian]

Post by Thief13
Je ne vois pas ce qui t'empeche de faire une fonction que tu pourras
réutiliser pour d'autres script...

Dans une fonction php, je peux passer en paramètre le nom d'un
formulaire ou je dois y aller variable par variable ?

[Thief13]

Post by JF Messian

Post by Thief13
Je ne vois pas ce qui t'empeche de faire une fonction que tu pourras
réutiliser pour d'autres script...

Dans une fonction php, je peux passer en paramètre le nom d'un
formulaire ou je dois y aller variable par variable ?

éventuellement ou alor, passe un tableau.

[Yanick]

Post by JF Messian

Post by Thief13
C'est à ça que servent les fonctions, éviter de faire du copier coller.
Tu fait un code générique, qui utilise des paramettres pour les truc qui
changent, et tu passes les paramettres à la fonction, pour le code dont
tu as besoin.

J'ai une base MySQL avec la table ayant les champs nom, prenom, adresse
<input type="text" name="nom">
<input type="text" name="prenom">
<input type="text" name="adresse">
insert into table (nom,nom,nom) values ('$ nom','$ prenom','$adresse') ;
ce qui serait sympa c'est d'automatiser un peu tout ça...
--
Un moyen de garde pour vos enfants ?http://www.easynounou.com

Regarde du côté de la commande SQL : DESCRIBE (ou DESC sous certaines
bases de données) qui te retourne de l'information sur une table
donnée. Tu peux, par exemple, définir la chaîne du champ du formulaire
dans les 'commentaires' du champ de la base de données... Si tu fais
des méthodes génériques pour te construire tes formulaires ainsi que
tes requêtes (que tu peux stockées dans une variable de session par
exemple, et l'identifiée à l'aide d'un champ HIDDEN de ton
formulaire...) Bref, c'est une idée lancée comme ça ;)

[Nicolas Le Gal]

Peut-être en construisant une bibliothèque de tes requêtes et variables
courantes, bref, par la programmation orientée objet.
Même si ton script est pas très complexe, si tu dois retaper chaque fois, ça
te permettrait déjà de réduire considérablement ton code.
Une première classe (MySQL) pour te connecter à la base de donnée.
La classe MySQLquery extends MySQL qui hérite des méthodes et variables de
MySQL dont le constructeur déifnit tes variables de formule (qui sont aussi
des champs de table MySQL).

[slambert]

Post by JF Messian
Il serait temps d'arrêter de faire du copier/coller... je m'explique...
Une part non négligeable de mes développement consiste à gérer des
formulaires pour entrées des informations et à mettre en place des
scripts permettant de retrouver les informations entrées dans la base de
données.
Concrêtement, je construit des formulaires dont les champs ont les mêmes
noms que ceux de la base de données, je les récupère et je les stoques.
De l'autre côté, je mets en place des requêtes (souvent les mêmes) pour
afficher les infos.
BREF : je fais beaucoup de copier/coller intelligents... enfin j'essaie

Bonjour



Il y a des technologies où on tente de mettre en place des systèmes
génériques pour ce genre de choses. Cela se nomme système de mapping (par
exemple Hibernate et NHibernate) et framework MVC style Struts. Le tout
couplé à des composants générique style DatGrid. Idéal pour faire de
l'entré/sortie bête de formulaire. Et le plus souvent, un système de
template vient se greffer par-dessus.



Cela n'est pas encore optimal et sent toujours l'usine à gaz à plein nez.



Néanmoins, je dois avouer être allé voir ailleurs ces derniers temps pour
voir ce qu'il s'y faisait. Il m'a semblé que C# et au J2EE étaient bien en
avance sur PHP pour ce genre de chose. Même si on trouve dans PEAR un
composant DataGrid (et oui...), et que les framework de mapping semble se
développer sous php.



Le concept est de monter en mémoire sous forme d'objets le contenu de tes
tables, et retrouver quasi dynamiquement dans ton formulaire le nouveau
champ que tu viens de créer dans ta base de donnée. Tu as accès à tes
valeurs via des collections d'objets. Tu mets à jour ces collections, et le
système se charge lui-même de faire les updates ou les insert. Lourd, mais
redoutables.



Mais pour faire tout cela, il faut de la vrai prog Objet, et donc php5. Il
faut aussi lancer un peu la grosse cavalerie, et s'investir dans des
framework immatures dont on n'est pas sur de la pérennité (et donc de
l'intérêt du temps passé).



Et surtout, ces technologies ont fait le choix de se comporter en serveur
d'application : c'est à dire qu'une partie de l'application est constament
en mémoire, ce qui évite par exemple de reloader la base pour chaque
utlisateur. Cela comporte un certain nombre de conséquences. Mais il n'est
pas certain que les avantages sous une plate-forme PHP soient équivalents.



Je me prends pourtant parfois à rêver d'avoir accès a ce genre de
technologies sans avoir à me prendre la tête à faire du boxing et du casting
redondant en permanence. Pour cela, mon avis est tranché, PHP est le
meilleurs. Le gain de temps est incomparable......



@ ++



Stef



PS: si quelqu'un a fait des découvertes pour arranger la vie dans ce
secteur, je suis preneur : )))))

[Jean-Marc Molina]

Post by slambert
Le concept est de monter en mémoire sous forme d'objets le contenu de
tes tables, et retrouver quasi dynamiquement dans ton formulaire le
nouveau champ que tu viens de créer dans ta base de donnée. Tu as
accès à tes valeurs via des collections d'objets. Tu mets à jour ces
collections, et le système se charge lui-même de faire les updates ou
les insert. Lourd, mais redoutables.

On parle d'Object Relational Mapping (ORM). C'est tout sauf lourd puisque
les classes PHP "mappant" les tables de la base sont épurées de tout code de
gestion de la base.

Post by slambert
Mais pour faire tout cela, il faut de la vrai prog Objet, et donc
php5. Il faut aussi lancer un peu la grosse cavalerie, et s'investir
dans des framework immatures dont on n'est pas sur de la pérennité
(et donc de l'intérêt du temps passé).

Je suis désolé mais des frameworks comme PEAR, Zend Framework, CakePHP ou eZ
Components sont tous sauf des "framework immatures". PEAR est supporté par
une énorme communauté de développeurs, CakePHP est un modèle du genre et les
deux autres sont supportés par des entreprises qui n'ont plus rien à
prouver.

Après c'est clair qu'il reste encore illusoire de vouloir mettre PHP et Java
EE ou .NET au même niveau. Mais quand on voit ce qu'ils se prennent dans la
tête face à des bolides comme Ruby on Rails...

Post by slambert
Et surtout, ces technologies ont fait le choix de se comporter en
serveur d'application : c'est à dire qu'une partie de l'application
est constament en mémoire, ce qui évite par exemple de reloader la
base pour chaque utlisateur. Cela comporte un certain nombre de
conséquences. Mais il n'est pas certain que les avantages sous une
plate-forme PHP soient équivalents.

Qu'est-ce que tu entends par "conséquences" ? Si tu veux parler de problèmes
de performances il existe des solutions comme Zend Encoder qui permettent de
décupler les performances des applications développées en PHP.

Post by slambert
Je me prends pourtant parfois à rêver d'avoir accès a ce genre de
technologies sans avoir à me prendre la tête à faire du boxing et du
casting redondant en permanence. Pour cela, mon avis est tranché, PHP
est le meilleurs. Le gain de temps est incomparable......

J'aime à dire que ce sont ses petits défauts qui font toute la richesse de
PHP :). Sa facilité d'accès mais son incroyable puissance quand on s'y
penche de prêt. Je te conseille de jeter un coup d'œil à Python et Ruby
comme tu sembles aimer voir ce qu'il se passe ailleurs. Il n'y a pas que
Java et .NET de l'autre côté du rivage :)

[Lionel]

Post by Jean-Marc Molina
On parle d'Object Relational Mapping (ORM). C'est tout sauf lourd
puisque les classes PHP "mappant" les tables de la base sont épurées
de tout code de gestion de la base.

Oui, c'est génial, mais on ne peut pas dire qu'un ORM n'est pas lourd.
C'est une magnifique usine à gaz, très pratique, mais qui n'est pas
forcément indispensable partout.
Une appli avec 5 requetes SQL n'a pas besoin d'un ORM.

Post by Jean-Marc Molina
Je suis désolé mais des frameworks comme PEAR, Zend Framework,
CakePHP ou eZ Components sont tous sauf des "framework immatures".

J'ai développé un site avec Seagull, assez peu connu mais qui semble être un
des très bons frameworks php existants.
Pour du PHP, j'ai trouvé ca génial.
Comparé à n'importe quel framework java, c'est immature, lourd et limite
nullissime.
Question de point de vue.

Post by Jean-Marc Molina
PEAR est supporté par une énorme communauté de développeurs

apparemment ca ne l'empeche pas d'etre buggé :)

Post by Jean-Marc Molina
Après c'est clair qu'il reste encore illusoire de vouloir mettre PHP
et Java EE ou .NET au même niveau. Mais quand on voit ce qu'ils se
prennent dans la tête face à des bolides comme Ruby on Rails...

Oui, RoR pour les démos c'est génial.
Mais en prod, avec plus de deux utilisateurs simultanés, apparemment
certains en reviennent...
Je n'ai pas encore investigué personnellement, donc je ne ferai pas plus de
commentaire.
ce qui est un fait, c'est que beaucoup d'entreprises refusent les appli
python (principalement pour des problèmes de peur et/ou maintenance)

Post by Jean-Marc Molina
Qu'est-ce que tu entends par "conséquences" ? Si tu veux parler de
problèmes de performances il existe des solutions comme Zend Encoder
qui permettent de décupler les performances des applications
développées en PHP.

certes, mais le pauvre dév, lui il souffre sur son appli php non optimisée
qui se traine pitoyablement.
Mais, on gagne beaucoup en temps de déploiement comparé à du java (en dév).

Post by Jean-Marc Molina
J'aime à dire que ce sont ses petits défauts qui font toute la
richesse de PHP :). Sa facilité d'accès mais son incroyable puissance
quand on s'y penche de prêt. Je te conseille de jeter un coup d'œil à
Python et Ruby comme tu sembles aimer voir ce qu'il se passe
ailleurs. Il n'y a pas que Java et .NET de l'autre côté du rivage :)

Heureusement !
Chacun développe sur la plateforme qu'il maitrise, c'est ça qui fait la
qualité du code source.
Un dév java aura du mal à passer à PHP, et inversement.
Chaque plate-forme a ses avantages et ses inconvénients, le débat est sans
fin.
Le bon dév, c'est celui qui saura proposer la plate-forme la plus adaptée au
besoin du client.

[slambert]

Post by Lionel
ce qui est un fait, c'est que beaucoup d'entreprises refusent les appli
python (principalement pour des problèmes de peur et/ou maintenance)

Moyennement d'accord. Ici, Python est très a la mode. Par exemple , Google
l'utilise beaucoup. Il faut dire qu'ils ont embauché Guido van Rossum......
Mais ce sont loin d'etre les seuls !

Stef

[Lionel]

Post by slambert

Post by Lionel
ce qui est un fait, c'est que beaucoup d'entreprises refusent les
appli python (principalement pour des problèmes de peur et/ou
maintenance)

Moyennement d'accord. Ici, Python est très a la mode. Par exemple ,
Google l'utilise beaucoup. Il faut dire qu'ils ont embauché Guido van
Rossum...... Mais ce sont loin d'etre les seuls !

J'aurais du préciser le type de client, car des exemples représentant
1/1000e des clients existants en France, tu peux m'en sortir plusieurs:
celui qui héberge ton appli, achète ton code source et qui est susceptible
(en cas de défaillance de ta part ou disparition de ta boite) de reprendre
le bébé soit pour le maintenir en interne, soit pour le refiler à un autre
presta.
Et là, une boite classique (pas google ou IBM, hein) dont la moitié des
codeurs fait du cobol, l'autre du VB, avec qq connaissances (pages perso) en
php, refusera quasi systématiquement python.
Déjà java ça passe pas toujours dans ce genre de cas, alors python, c'est
meme pas la peine.
Evidemment, dans le cas d'appli hébergée par le presta, la question ne se
pose pas.

[slambert]

Post by Lionel
J'aurais du préciser le type de client, car des exemples représentant

Ah, désolé, je ne parlais pas du marché Francais.

Mais c'est vrai que Google n'est pas une entreprise "standard".

Les autres exemples qui me viennent tout de suite à l'esprit en ce qui
concerne Python sont des entreprises développant leur propre SI en interne.
Ce ne sont effectivement pas des prestataires....

Et oui, effectivement, Python n'est visiblement pas la technologie
principale du marché du développement. Cela reste tout de meme assez
minoritaire, meme si je vois régulièrement passer des offres d'emplois sur
cette techno.

@++

Stef

[Bruno Desthuilliers]

Post by slambert

Post by Lionel
J'aurais du préciser le type de client, car des exemples représentant

Ah, désolé, je ne parlais pas du marché Francais.
Mais c'est vrai que Google n'est pas une entreprise "standard".
Les autres exemples qui me viennent tout de suite à l'esprit en ce qui
concerne Python sont des entreprises développant leur propre SI en interne.
Ce ne sont effectivement pas des prestataires....
Et oui, effectivement, Python n'est visiblement pas la technologie
principale du marché du développement. Cela reste tout de meme assez
minoritaire, meme si je vois régulièrement passer des offres d'emplois sur
cette techno.

<troll>
Un des problèmes avec Python, c'est que vu la productivité moyenne
comparée à une usine à gaz Java, les grosses SSII on du mal à justifier
leurs tarifs (et les DRI leurs budgets - or chez les grands comptes, le
plus important n'est pas le résultat mais la quantité de fric cramée).

Accessoirement aussi, Python n'étant encore que marginalement enseigné,
les développeurs compétents dans ce langage sont non seulement des
oiseaux rares, mais surtout des passionnés - donc pas *du tout* le type
de profil que recrutent les grosses SSII (et d'ailleurs pas non plus le
profil à vouloir travailler dans une grosse SSII).
</troll>

Ceci étant, Python (et Ruby) gagnent du terrain petit à petit.

[Michel Billaud]

Post by Bruno Desthuilliers
Accessoirement aussi, Python n'étant encore que marginalement
enseigné, les développeurs compétents dans ce langage sont non
seulement des oiseaux rares, mais surtout des passionnés - donc pas
*du tout* le type de profil que recrutent les grosses SSII (et
d'ailleurs pas non plus le profil à vouloir travailler dans une grosse
SSII).
</troll>
Ceci étant, Python (et Ruby) gagnent du terrain petit à petit.

Cela dit, un bon programmeur ça se reconnait aussi à sa capacité
d'apprendre des outils et des langages nouveaux. Imaginez ceux qui
n'ont rien appris depuis 10 ans...

MB

[slambert]

Post by Michel Billaud
Cela dit, un bon programmeur ça se reconnait aussi à sa capacité
d'apprendre des outils et des langages nouveaux.

C'est vrai.

J'ai toujours été convaincu de l'immensité de ce que je ne connaissais pas,
et je tente régulièrement de pallier à cet état de fait :D

Pour moi, quelqu'un qui ne pratique pas cette approche individuelle va au
devant de grosses désillusions, surtout dans notre métier.

Dire que j'ai croisé des ingénieurs juste diplômés qui m'ont sorti en
entretiens de recrutement leur diplôme juste en poche: "Moi, programmer,
maintenant, je sais. Je voudrais encadrer et expliquer, car avec mes 5 ans
d'études et mes deux stages, je pense que j'en ai fait le tour."

Les pauvres, s'ils savaient......


Ø Imaginez ceux qui

Post by Michel Billaud
n'ont rien appris depuis 10 ans...

Ø
Ils ont encore du boulot ?????

Post by Michel Billaud
LABRI-Université Bordeaux I tel [phone]

Tiens, le Labri....

J'ai eu de très bons profs de là bas, dont un fabuleux qui nous proposait en
module I1 de DEUG [ça ne nous rajeunit pas....] une "histoire de
l'informatique" qui partait des boules et des jetons de l'antiquité et qui
finissait à Xerox et la souris. Avec les collègues, on se battait pour
assister aux cours et on en ratait pas une miette : )

Et puis quelques profs de math pas mal aussi....

Il fait beau chez vous ? :)

@++

Stef

[Bruno Desthuilliers]

Post by slambert

Post by Michel Billaud
Cela dit, un bon programmeur ça se reconnait aussi à sa capacité
d'apprendre des outils et des langages nouveaux.

(snip)

Post by slambert
Dire que j'ai croisé des ingénieurs juste diplômés qui m'ont sorti en
entretiens de recrutement leur diplôme juste en poche: "Moi, programmer,
maintenant, je sais. Je voudrais encadrer et expliquer, car avec mes 5 ans
d'études et mes deux stages, je pense que j'en ai fait le tour."

Avec mes 8 ou 9 années d'"études sur le terrain"/expérience
professionnelle (bin oui, je suis essentiellement autodidacte), je
commence tout juste à prendre la mesure de tout ce que je ne suis pas
près de savoir faute de temps...

Post by slambert
Les pauvres, s'ils savaient......
Ø Imaginez ceux qui

Post by Michel Billaud
n'ont rien appris depuis 10 ans...

Ø
Ils ont encore du boulot ?????

Beaucoup, oui.

[Bruno Desthuilliers]

Post by Michel Billaud

Post by Bruno Desthuilliers
Accessoirement aussi, Python n'étant encore que marginalement
enseigné, les développeurs compétents dans ce langage sont non
seulement des oiseaux rares, mais surtout des passionnés - donc pas
*du tout* le type de profil que recrutent les grosses SSII (et
d'ailleurs pas non plus le profil à vouloir travailler dans une grosse
SSII).
</troll>
Ceci étant, Python (et Ruby) gagnent du terrain petit à petit.

Cela dit, un bon programmeur ça se reconnait aussi à sa capacité
d'apprendre des outils et des langages nouveaux.

Depuis quand les grandes SSII recherchent-elles des bons programmeurs ?

Post by Michel Billaud
Imaginez ceux qui
n'ont rien appris depuis 10 ans...

Pas besoin, j'en croise régulièrement.

[Bruno Desthuilliers]

Lionel a écrit :
(snip)

Post by Lionel
Oui, RoR pour les démos c'est génial.
Mais en prod, avec plus de deux utilisateurs simultanés, apparemment
certains en reviennent...
Je n'ai pas encore investigué personnellement, donc je ne ferai pas plus de
commentaire.
ce qui est un fait, c'est que beaucoup d'entreprises refusent les appli
python (principalement pour des problèmes de peur et/ou maintenance)

Heu... Tu nous expliquera le rapport entre *Ruby* on Rails et Python ?

[Lionel]

Post by Bruno Desthuilliers
Heu... Tu nous expliquera le rapport entre *Ruby* on Rails et Python ?

Ils ont les mêmes qualités et les mêmes inconvénients qui font qu'il ne
remplaceront pas java.

[Bruno Desthuilliers]

Post by Lionel

Post by Bruno Desthuilliers
Heu... Tu nous expliquera le rapport entre *Ruby* on Rails et Python ?

Ils ont les mêmes qualités et les mêmes inconvénients

Ah tiens ? Lesquels ?

Post by Lionel
qui font qu'il ne
remplaceront pas java.

Ruby On Rails est un framework. Python est un langage. Tu n'a pas
l'impression de mélanger un peu, là ?

Quant à ce qui est de remplacer Java, je crains qu'effectivement ce ne
soit pas pour demain - mais je doute que ce soit dû aux qualités[1] du
langage...

[1] <troll>Java : l'élégante simplicité de C++, les perfs foudroyantes
de Smalltalk...</troll>

Mais bon, tout cela est quelque peu hs ici, donc...

[slambert]

[1] <troll>Java : l'élégante simplicité de C++, les perfs foudroyantes de
Smalltalk...</troll>

Attends attends, tu n'as pas parlé de l'architecture type des logiciels
Java.

En Java, faut découper. Faut faire pleins d'espace mémoire différents qui
communiquent entre eux. Le concept de couche, chez eux, prend tout son sens.
Un programme java n'est pas concevable pour un puriste s'il ne comporte pas
au moins 3 couches plus un navigateur web, même si ce programme est déployé
sur une seule et même machine. Et certains sont près à payer des systèmes
Corba super chers et lourds pour faire communiquer leurs couches entre
elles. Il faut créer des espaces mémoires bien distinctes et pondre tout un
tralala pour les faire communiquer entre eux. J'ai travaillé avec un système
RMI de Iona, rien que pour aller chercher une bête info dans la base de
donnée, il fallait mettre à jour une 20ine de classe, et écrire la partie
correspondante dans le protocole d'échange Corba. Temps pour ajouter une
icône "est abonné oui/non" : 3 jours pour le spécialiste de la boite
connaissant le logiciel, 10 jours pour le freelance qui vient d'arriver dans
la boute. Ben oui, en plus, un soft de 7 ans d'existence sans docs, avec 40
000 intervenants qui sont passés dessus depuis l'origine, avec des niveaux
divers et variés, et qui sont partis sans rien écrire en disant uniquement à
voix haute à leurs collègues ce qu'ils ont fait... La tradition orale
anglo-saxonne a parfois du bon, mais là..... Et dans ces conditions, mettre
en plus des applet pour le plaisir de créer un espace mémoire supplémentaire
très contestable avec encore des protocoles de communication à la con.... Ca
ferait presque passer la notion de VIEWSTATE du C# pour un truc opportun et
libertaire.

Pourtant, le MVC, moi j'ai bien aimé. Mais c'est au niveau de ce que c'est
devenu qu'il faut se pencher et regarder.

Le MVC, c'est un Design Pattern permettant de gérer la couche présentation,
et la couche d'accès aux donnés. Généralement sur le serveur du milieu en
cas de 3 tiers :)

Enfin je crois:
http://fr.wikipedia.org/wiki/Architecture_trois_tiers

Mais bon, des fois, tu as le n tiers, les mecs de Java par exemple découpent
ce serveur du milieux en deux, avec des EJB voir du SOAP [ou même du RMI],
pour théoriquement pouvoir proposer un serveur d'objet sur une machine
appelé par des machines clientes, qui a leurs tour vont aller s'occuper des
couches présentation qu'elles ont à manager.

Là où on se marre, c'est quand tout cela, du serveur de base de donnée au
client web, est déployé sur la MEME machine. Mouarf. Mais c'est encore un
autre problème. : ))))

Mais bon, tout cela est quelque peu hs ici, donc...

C'est vrai.

Je repars sur le code goret qu'on m'a chargé de compléter, avec le plaisir
inhérent de travailler sur un truc de 16Mo de fichiers php non commentés qui
mélangent code et html, avec des globales partout et des fonctions pour
faire des bouts de tableaux et fonction des cas. Du pur bonheur. Je
reverrais presque de refaire du nTiers en localhost, pour le coup.

Stef

[Bruno Desthuilliers]

Post by slambert

[1] <troll>Java : l'élégante simplicité de C++, les perfs foudroyantes de
Smalltalk...</troll>

Attends attends, tu n'as pas parlé de l'architecture type des logiciels
Java.

Non, mais tu le fais si bien que je ne regrette pas !-)

(snip excellente description de la chose)

Post by slambert
Pourtant, le MVC, moi j'ai bien aimé. Mais c'est au niveau de ce que c'est
devenu qu'il faut se pencher et regarder.

Dans ce cas, regarde du côté de Ruby on Rails, Pylons, ou (pour revenir
dans le sujet) CakePHP.

(snip suite)

Post by slambert

Mais bon, tout cela est quelque peu hs ici, donc...

C'est vrai.
Je repars sur le code goret qu'on m'a chargé de compléter, avec le plaisir
inhérent de travailler sur un truc de 16Mo de fichiers php non commentés qui
mélangent code et html, avec des globales partout et des fonctions pour
faire des bouts de tableaux et fonction des cas. Du pur bonheur.

Bienvenu dans le monde merveilleux de PHP !-)

C'est quand même très culturel, tout ça. On *peut* techniquement faire
du MVC globalement propre *et* simple en PHP (cf CakePHP, et même en le
faisant à la mano ce n'est pas bien méchant), et pourtant la moyenne de
ce qu'on voit en PHP est effectivement assez goret.

De même - même si le langage est en lui même, disons, pas très agile -
on *pourrait* techniquement faire du MVC simple et relativement light en
Java, et pourtant la moyenne de ce qu'on voit est usineàgazesque et
arbitrairement compliqué au point d'en devenir risible (tant qu'on n'a
pas à travailler avec, j'entends...).

Alors pourquoi ?

[slambert]

Post by Jean-Marc Molina

Post by slambert
les insert. Lourd, mais redoutables.

On parle d'Object Relational Mapping (ORM). C'est tout sauf lourd puisque
les classes PHP "mappant" les tables de la base sont épurées de tout code de
gestion de la base.

Je disais lourd pour la mémoire tout de même. On monte quasi toute la table
a chaque fois, c'est beaucoup plus gourmand en ressource qu'un système sql
traditionnel programmé correctement...

Post by Jean-Marc Molina
Après c'est clair qu'il reste encore illusoire de vouloir mettre PHP et Java
EE ou .NET au même niveau. Mais quand on voit ce qu'ils se prennent dans la
tête face à des bolides comme Ruby on Rails...

Ah ça....

J'aime bien Python, ceci dit. Ce serait moi, tout le monde en ferait au
moins 6 mois durant leurs études. Ca leur apprendrait à indenter
correctement : )))))))

Post by Jean-Marc Molina

Post by slambert
Et surtout, ces technologies ont fait le choix de se comporter en
serveur d'application : c'est à dire qu'une partie de l'application
est constament en mémoire, ce qui évite par exemple de reloader la
base pour chaque utlisateur. Cela comporte un certain nombre de
conséquences. Mais il n'est pas certain que les avantages sous une
plate-forme PHP soient équivalents.

Qu'est-ce que tu entends par "conséquences" ?

La facon de programmer certaines choses n'est pas la même sous un "serveur
d'application"..... Il y a quelques avantages à avoir accès à un espace
mémoire commun à l'application, un autre au request, et un troisième à la
session !

Quand aux perf, je n'en parlerais pas. Je réserverais même les commentaires
sur mes crises de rire devant le temps mis pour développer certains écrans
d'application J2EE n-tiers découpées à grand coup d'EJB, le tout en
Localhost. C'est un autre problème. :))))

Post by Jean-Marc Molina

Post by slambert
Je me prends pourtant parfois à rêver d'avoir accès a ce genre de
technologies sans avoir à me prendre la tête à faire du boxing et du
casting redondant en permanence. Pour cela, mon avis est tranché, PHP
est le meilleurs. Le gain de temps est incomparable......

J'aime à dire que ce sont ses petits défauts qui font toute la richesse de
PHP :). Sa facilité d'accès mais son incroyable puissance quand on s'y
penche de prêt.

Ah mais je suis ok ! Je suis tombé dedans depuis 1999, et à chaque fois, il
n'y a rien à faire, j'y reviens......

Post by Jean-Marc Molina
comme tu sembles aimer voir ce qu'il se passe ailleurs.

Oui. Durant longtemps, j'ai été partisan du choix de préférer devenir expert
dans une technologie que de prendre le risque de devenir moyen dans
plusieurs. Je pense que c'était une erreur. Et puis "expert", hein, ça veut
dire quoi.......

Post by Jean-Marc Molina
Il n'y a pas que
Java et .NET de l'autre côté du rivage :)

C'est vrai. Mais c'est pas mal d'aller passer un peu de temps, parfois, pour
voir les bonnes idées que forcément, ils ont parfois.... Très humblement, je
pense que cela m'a fait beaucoup de bien. Je sais maintenant que j'ai encore
plus de choses à apprendre et à compléter que je ne le pensais : )

@++



Stef

[Bruno Desthuilliers]

Post by slambert

Post by Jean-Marc Molina

Post by slambert
les insert. Lourd, mais redoutables.

On parle d'Object Relational Mapping (ORM). C'est tout sauf lourd puisque
les classes PHP "mappant" les tables de la base sont épurées de tout code de
gestion de la base.

Je disais lourd pour la mémoire tout de même. On monte quasi toute la table
a chaque fois,

Alors mauvais ORM, à jeter. Le fonctionnement que tu décris n'est en
rien constitutif d'un ORM - c'est juste une erreur de conception.

Post by slambert
c'est beaucoup plus gourmand en ressource qu'un système sql
traditionnel programmé correctement...

Insistons bien sur le "programmé correctement". J'ai vu pas mal
d'horreurs dans des applis PHP/MySQL sans ORM (du genre "select * "
suivi d'une boucle pour compter les enregistrements... Non non, je
n'invente pas).

(snip)

[Lionel]

Post by Bruno Desthuilliers

Post by slambert
Je disais lourd pour la mémoire tout de même. On monte quasi toute
la table a chaque fois,

Alors mauvais ORM, à jeter. Le fonctionnement que tu décris n'est en
rien constitutif d'un ORM - c'est juste une erreur de conception.

Ce n'est pas parce que l'on ne sait pas bien se servir d'un ORM qu'il est à
jeter :)

Post by Bruno Desthuilliers
Insistons bien sur le "programmé correctement". J'ai vu pas mal
d'horreurs dans des applis PHP/MySQL sans ORM

Je pense qu'il y a autant d'horreurs avec ORM que sans ORM.
Le problème est qu'avec un ORM, on peut très vite faire des choses pires
qu'en SQL à la main sans le savoir.

Exemple avec hibernate: pour qu'une requete SQL se transforme en plusieurs
milliers de requetes, il suffit de se planter dans la configuration d'un
paramètre dans un fichier XML. Celui qui code sans regarder les requetes SQL
exécutée ne le verra jamais.

[Bruno Desthuilliers]

Lionel a écrit :
(snip)

Post by Lionel
Exemple avec hibernate: pour qu'une requete SQL se transforme en plusieurs
milliers de requetes, il suffit de se planter dans la configuration d'un
paramètre dans un fichier XML. Celui qui code sans regarder les requetes SQL
exécutée ne le verra jamais.

C'est ça qui est bien avec Java: le langage est tellement lourd qu'en
comparaison, le XML semble agile...

[Jean-Marc Molina]

Post by JF Messian
Il serait temps d'arrêter de faire du copier/coller... je
m'explique...

Qui ne l'a jamais fait...

Post by JF Messian
Une part non négligeable de mes développement consiste à gérer des
formulaires pour entrées des informations et à mettre en place des
scripts permettant de retrouver les informations entrées dans la base
de données.
Concrêtement, je construit des formulaires dont les champs ont les
mêmes noms que ceux de la base de données, je les récupère et je les
stoques.
De l'autre côté, je mets en place des requêtes (souvent les mêmes)
pour afficher les infos.
BREF : je fais beaucoup de copier/coller intelligents... enfin
j'essaie !
Il existe surement des outils logiciels pour gagner un peu de temps,
non ? Je précise que je suis sur mac os x...

La solution consiste à développer avec de bonnes méthodes et à utiliser les
bons outils, plus spécifiquement un "framework".

Concernant les méthodes je te renvoie aux nombreuses références sur le sujet
de la Programmation Orientée Objet (POO). Quand on est un développeur C++
l'incontournable c'est le livre de Grady Booch par exemple, aussi inventeur
d'une méthode de développement. J'imagine qu'il doit exister des adaptations
de ses recettes à PHP. On pourrait parler par exemple de l'importance de la
réutilisation des composants d'une application. Une première approche est
par exemple de transformer ses copiés-collés en fonction, comme l'a dit
quelqu'un dans un autre message. Ensuite on regroupe des fonctions dans des
classes, on passe à l'héritage... Mais déjà prendre la bonne habitude de
toujours créer une fonction pour effectuer une opération même très basique,
c'est un grand pas ! On a moins le réflexe de vouloir la copier-coller pour
l'adapter, on a plus tendance à la "paramétrer" en lui ajoutant des
arguments... Puis ça permet de se constituer rapidement une petite
bibliothèque de fonctions bien pratiques qu'on réutilise à travers tous ses
petits projets. L'aboutissement de tout ça ce sont les...

Frameworks, comme PEAR [1] ou ceux dont je parle dans un autre message de
cette discussion. PEAR propose tout un tas de "packages" documentés et très
pratiques. Pour les formulaires il y a par exemple HTML_QuickForm qui permet
de générer rapidement un formulaire HTML à partir d'un modèle. Terminées les
lignes de HTML qu'on copie-colle à travers tous ses modèles HTML. Pour les
accès à la base il y a DB_DataObject qui permet de mapper une classe à une
table de BDD et donc de faire de l'ORM ni une ni deux.

Une bonne introduction à ces sujets est l'article "Three-Tier Development
with PHP 5" [2] de ONLamp.com. Désolé si tu es allergique à l'anglais :).
Par contre se méfier de l'approche utilisant Smarty car il y a toute une
Paul & Mickey sur le sujet. "Template engines are evil" ! :D

Notes :
* [1] http://pear.php.net
* [2] http://www.onlamp.com/pub/a/php/2004/12/09/three_tier.html