Outils de developpement

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.

Thief13 <Thief13@nospam.com> wrote:

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...


--
Un moyen de garde pour vos enfants ?
http://www.easynounou.com

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

On 7 mar, 17:23, messian_nos...@hypermedia-europe.com (JF Messian)
wrote:

Thief13 <Thie...@nospam.com> wrote:

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...

--
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 ;)

Thief13 <Thief13@nospam.com> wrote:

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 ?

--
Un moyen de garde pour vos enfants ?
http://www.easynounou.com

Thief13 <Thief13@nospam.com> wrote:

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.

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 : )))))

slambert wrote:

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.

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...

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.

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 :)

JF Messian wrote:

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

Qui ne l'a jamais fait...

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

Jean-Marc Molina wrote:

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.

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.

PEAR est supporté par une énorme communauté de développeurs

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

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)

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).

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.