Bonjour, pour mon prochain projet j'ai pris la décision d'exploiter au
maximum les classes PEAR à la place de certaines des miennes (DB, Auth,
Log, Validate, etc.)
Quel jugement portez-vous sur la qualité des classes PEAR ? Eventuellement
sur certains inconvénients potentiels...
L'idée c'est de disposer d'un code plus fiable que le mien et d'éviter de
perdre du temps à réinventer la roue pour en consacrer un peu plus à
l'essentiel
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
bruno
alors... tout depend de quelles classes tu veut te servir :
DB : c'est bien DB_DataObject : oublie : c'est super long a configurer et au final t'a plus de ligne, et des problemes a tire larigo (ca s'ecrit comme ca?) HTML_quickform : j'aime pas...
voila mes impressions...
alors...
tout depend de quelles classes tu veut te servir :
DB : c'est bien
DB_DataObject : oublie : c'est super long a configurer et au final t'a
plus de ligne, et des problemes a tire larigo (ca s'ecrit comme ca?)
HTML_quickform : j'aime pas...
alors... tout depend de quelles classes tu veut te servir :
DB : c'est bien DB_DataObject : oublie : c'est super long a configurer et au final t'a plus de ligne, et des problemes a tire larigo (ca s'ecrit comme ca?) HTML_quickform : j'aime pas...
voila mes impressions...
dmetzler
Sur le site de php, j'ai vu qu'ils intégraient les php data objects dans la dernière version beta. J'ai aussi vu qu'ils étaient dans les packages pecl.... Quelqu'un a des infos là dessus ou pas ?
Sur le site de php, j'ai vu qu'ils intégraient les php data objects
dans la dernière version beta. J'ai aussi vu qu'ils étaient dans les
packages pecl.... Quelqu'un a des infos là dessus ou pas ?
Sur le site de php, j'ai vu qu'ils intégraient les php data objects dans la dernière version beta. J'ai aussi vu qu'ils étaient dans les packages pecl.... Quelqu'un a des infos là dessus ou pas ?
Didier Raboud
Quel jugement portez-vous sur la qualité des classes PEAR ? Eventuellement sur certains inconvénients potentiels...
J'ai utilisé quelques classes de cette bibliothèque pour un projet. C'est 'achement pratique, mais il y a un certain effort à fournir pour en comprendre le fonctionnement (nottamment en terme de traitement d'erreurs).
Par contre, je n'ai pas trouvé comment grouper les requêtes MySQL. Exemple: J'utilisais la classe PEAR::Auth qui permet de gérer une autentification de manière assez aisée ainsi que la classe PEAR::DB qui permet de se connecter à une base de données (quasiment) quelconque. Mais j'aurais apprécié (mon hébergeur également) que l'ouverture de la connexion soit unique et que l'ordre soit le suivant:
* Ouverture de la connexion * Requête 1 > Stockage brut * Requête 2 > Stockage brut * Requête 3 > Stockage brut * Fermeture de la connexion * Traitement du résultat de la requête 1 * Traitement du résultat de la requête 2 * Traitement du résultat de la requête 3
afin de limiter au maximum le temps de connexion. Malheureusement, avec le niveau d'abstraction de PEAR, ceci ne semble pas possible (surtout si l'on utilise plusieurs classes utilisant la même base). C'est, à mon sens, un inconvénient.
L'idée c'est de disposer d'un code plus fiable que le mien et d'éviter de perdre du temps à réinventer la roue pour en consacrer un peu plus à l'essentiel
Je suis tout à fait d'accord sur le principe. Il faut voir dans les faits si le jeu en vaut la chandelle !
Salutations,
Didier
Quel jugement portez-vous sur la qualité des classes PEAR ? Eventuellement
sur certains inconvénients potentiels...
J'ai utilisé quelques classes de cette bibliothèque pour un projet.
C'est 'achement pratique, mais il y a un certain effort à fournir pour
en comprendre le fonctionnement (nottamment en terme de traitement
d'erreurs).
Par contre, je n'ai pas trouvé comment grouper les requêtes MySQL.
Exemple: J'utilisais la classe PEAR::Auth qui permet de gérer une
autentification de manière assez aisée ainsi que la classe PEAR::DB qui
permet de se connecter à une base de données (quasiment) quelconque.
Mais j'aurais apprécié (mon hébergeur également) que l'ouverture de la
connexion soit unique et que l'ordre soit le suivant:
* Ouverture de la connexion
* Requête 1 > Stockage brut
* Requête 2 > Stockage brut
* Requête 3 > Stockage brut
* Fermeture de la connexion
* Traitement du résultat de la requête 1
* Traitement du résultat de la requête 2
* Traitement du résultat de la requête 3
afin de limiter au maximum le temps de connexion. Malheureusement, avec
le niveau d'abstraction de PEAR, ceci ne semble pas possible (surtout si
l'on utilise plusieurs classes utilisant la même base). C'est, à mon
sens, un inconvénient.
L'idée c'est de disposer d'un code plus fiable que le mien et d'éviter de
perdre du temps à réinventer la roue pour en consacrer un peu plus à
l'essentiel
Je suis tout à fait d'accord sur le principe. Il faut voir dans les
faits si le jeu en vaut la chandelle !
Quel jugement portez-vous sur la qualité des classes PEAR ? Eventuellement sur certains inconvénients potentiels...
J'ai utilisé quelques classes de cette bibliothèque pour un projet. C'est 'achement pratique, mais il y a un certain effort à fournir pour en comprendre le fonctionnement (nottamment en terme de traitement d'erreurs).
Par contre, je n'ai pas trouvé comment grouper les requêtes MySQL. Exemple: J'utilisais la classe PEAR::Auth qui permet de gérer une autentification de manière assez aisée ainsi que la classe PEAR::DB qui permet de se connecter à une base de données (quasiment) quelconque. Mais j'aurais apprécié (mon hébergeur également) que l'ouverture de la connexion soit unique et que l'ordre soit le suivant:
* Ouverture de la connexion * Requête 1 > Stockage brut * Requête 2 > Stockage brut * Requête 3 > Stockage brut * Fermeture de la connexion * Traitement du résultat de la requête 1 * Traitement du résultat de la requête 2 * Traitement du résultat de la requête 3
afin de limiter au maximum le temps de connexion. Malheureusement, avec le niveau d'abstraction de PEAR, ceci ne semble pas possible (surtout si l'on utilise plusieurs classes utilisant la même base). C'est, à mon sens, un inconvénient.
L'idée c'est de disposer d'un code plus fiable que le mien et d'éviter de perdre du temps à réinventer la roue pour en consacrer un peu plus à l'essentiel
Je suis tout à fait d'accord sur le principe. Il faut voir dans les faits si le jeu en vaut la chandelle !
Salutations,
Didier
ftc
Par contre, je n'ai pas trouvé comment grouper les requêtes MySQL. Exemple: J'utilisais la classe PEAR::Auth qui permet de gérer une autentification de manière assez aisée ainsi que la classe PEAR::DB qui permet de se connecter à une base de données (quasiment) quelconque. Mais j'aurais apprécié (mon hébergeur également) que l'ouverture de la connexion soit unique
Si la chaine de connexion à la BDD est la même, une seule connexion est utilisée.
Si 20 connexions sont demandées dans un script, une et une seule connexion sera utilisée si les paramètres sont les mêmes.
cf doc de mysql_connect par exemple: Si un deuxième appel est fait à mysql_connect() avec les mêmes arguments, aucune nouvelle connexion ne sera établie, mais plutôt, l'identifiant de la connexion de la connexion déjà ouverte sera retourné.
Il en est de même pour la plupart des fonctions de connexion à un SGBD.
Par contre, je n'ai pas trouvé comment grouper les requêtes MySQL.
Exemple: J'utilisais la classe PEAR::Auth qui permet de gérer une
autentification de manière assez aisée ainsi que la classe PEAR::DB qui
permet de se connecter à une base de données (quasiment) quelconque.
Mais j'aurais apprécié (mon hébergeur également) que l'ouverture de la
connexion soit unique
Si la chaine de connexion à la BDD est la même, une seule connexion est
utilisée.
Si 20 connexions sont demandées dans un script, une et une seule
connexion sera utilisée si les paramètres sont les mêmes.
cf doc de mysql_connect par exemple:
Si un deuxième appel est fait à mysql_connect() avec les mêmes
arguments, aucune nouvelle connexion ne sera établie, mais plutôt,
l'identifiant de la connexion de la connexion déjà ouverte sera retourné.
Il en est de même pour la plupart des fonctions de connexion à un SGBD.
Par contre, je n'ai pas trouvé comment grouper les requêtes MySQL. Exemple: J'utilisais la classe PEAR::Auth qui permet de gérer une autentification de manière assez aisée ainsi que la classe PEAR::DB qui permet de se connecter à une base de données (quasiment) quelconque. Mais j'aurais apprécié (mon hébergeur également) que l'ouverture de la connexion soit unique
Si la chaine de connexion à la BDD est la même, une seule connexion est utilisée.
Si 20 connexions sont demandées dans un script, une et une seule connexion sera utilisée si les paramètres sont les mêmes.
cf doc de mysql_connect par exemple: Si un deuxième appel est fait à mysql_connect() avec les mêmes arguments, aucune nouvelle connexion ne sera établie, mais plutôt, l'identifiant de la connexion de la connexion déjà ouverte sera retourné.
Il en est de même pour la plupart des fonctions de connexion à un SGBD.
loufoque
Zouplaz a dit le 19/07/2005 15:46:
Quel jugement portez-vous sur la qualité des classes PEAR ? Eventuellement sur certains inconvénients potentiels...
Je n'aime pas trop, je préfère faire mon propre framework. En tous cas, je déconseille vivement DB, utilise plutôt MDB2.
Zouplaz a dit le 19/07/2005 15:46:
Quel jugement portez-vous sur la qualité des classes PEAR ? Eventuellement
sur certains inconvénients potentiels...
Je n'aime pas trop, je préfère faire mon propre framework.
En tous cas, je déconseille vivement DB, utilise plutôt MDB2.
Quel jugement portez-vous sur la qualité des classes PEAR ? Eventuellement sur certains inconvénients potentiels...
Je n'aime pas trop, je préfère faire mon propre framework. En tous cas, je déconseille vivement DB, utilise plutôt MDB2.
Pour quelle(s) raison(s) ? Ca semble être la classe de base parfaite... Qu'est ce qui cloche selon toi ?
Jean-Marc Molina
Quel jugement portez-vous sur la qualité des classes PEAR ? Eventuellement sur certains inconvénients potentiels...
Avantages : - Gain en productivité : réutilisation, pas de maintenance à effectuer (bogues, trous de sécurité...) - Quantité de classes disponibles : DB, QuickForm, gestion des erreurs, XML... - Documentation : bien dans l'ensemble, nombre d'infos présentées (on est loin du manuel PHP complètement chaotique : paramètres ? valeurs de retour ? exceptions ?) - Qualité du code : "coding standards"... - Libre et communautaire : tout le monde peut participer
Inconvénients : - Documentation : packages non documentés (il faut regarder les sources, package Benchmark par ex), - Distribution mal architecturé : chemin d'installation par défaut, pas de notion d'espace de noms pour éviter les conflits (net_php_pear_...) - Installation et déploiement hazardeux
En utilisant PEAR une équipe de développeurs a tout à gagner si elle cherche à être plus efficace et productive. DB permet de gérer la majorité des SGBD (MySQL, PostgreSQL...), QuickForm permet de gagner du temps quand il s'agit de générer une multitude de formulaires pour une quantité astronomique de données différentes, le gestionnaire d'erreurs devient votre meilleure ami... et il présente évidemment tous les avantages d'un "framework" : réutilisation des classes, documentation, sécurité...
-- Jean-Marc.
Quel jugement portez-vous sur la qualité des classes PEAR ?
Eventuellement sur certains inconvénients potentiels...
Avantages :
- Gain en productivité : réutilisation, pas de maintenance à effectuer
(bogues, trous de sécurité...)
- Quantité de classes disponibles : DB, QuickForm, gestion des erreurs,
XML...
- Documentation : bien dans l'ensemble, nombre d'infos présentées (on est
loin du manuel PHP complètement chaotique : paramètres ? valeurs de retour ?
exceptions ?)
- Qualité du code : "coding standards"...
- Libre et communautaire : tout le monde peut participer
Inconvénients :
- Documentation : packages non documentés (il faut regarder les sources,
package Benchmark par ex),
- Distribution mal architecturé : chemin d'installation par défaut, pas de
notion d'espace de noms pour éviter les conflits (net_php_pear_...)
- Installation et déploiement hazardeux
En utilisant PEAR une équipe de développeurs a tout à gagner si elle cherche
à être plus efficace et productive. DB permet de gérer la majorité des SGBD
(MySQL, PostgreSQL...), QuickForm permet de gagner du temps quand il s'agit
de générer une multitude de formulaires pour une quantité astronomique de
données différentes, le gestionnaire d'erreurs devient votre meilleure
ami... et il présente évidemment tous les avantages d'un "framework" :
réutilisation des classes, documentation, sécurité...
Quel jugement portez-vous sur la qualité des classes PEAR ? Eventuellement sur certains inconvénients potentiels...
Avantages : - Gain en productivité : réutilisation, pas de maintenance à effectuer (bogues, trous de sécurité...) - Quantité de classes disponibles : DB, QuickForm, gestion des erreurs, XML... - Documentation : bien dans l'ensemble, nombre d'infos présentées (on est loin du manuel PHP complètement chaotique : paramètres ? valeurs de retour ? exceptions ?) - Qualité du code : "coding standards"... - Libre et communautaire : tout le monde peut participer
Inconvénients : - Documentation : packages non documentés (il faut regarder les sources, package Benchmark par ex), - Distribution mal architecturé : chemin d'installation par défaut, pas de notion d'espace de noms pour éviter les conflits (net_php_pear_...) - Installation et déploiement hazardeux
En utilisant PEAR une équipe de développeurs a tout à gagner si elle cherche à être plus efficace et productive. DB permet de gérer la majorité des SGBD (MySQL, PostgreSQL...), QuickForm permet de gagner du temps quand il s'agit de générer une multitude de formulaires pour une quantité astronomique de données différentes, le gestionnaire d'erreurs devient votre meilleure ami... et il présente évidemment tous les avantages d'un "framework" : réutilisation des classes, documentation, sécurité...
