PORTAGE PDO DE MES ANCIENNES PUBLICATIONS
Utilisateur anonyme
-
9 déc. 2008 à 18:10
cs_8Tnerolf8 Messages postés 30 Date d'inscription vendredi 25 novembre 2005 Statut Membre Dernière intervention 17 novembre 2009 - 16 oct. 2009 à 18:42
cs_8Tnerolf8 Messages postés 30 Date d'inscription vendredi 25 novembre 2005 Statut Membre Dernière intervention 17 novembre 2009 - 16 oct. 2009 à 18:42
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/48669-portage-pdo-de-mes-anciennes-publications
https://codes-sources.commentcamarche.net/source/48669-portage-pdo-de-mes-anciennes-publications
16 oct. 2009 à 18:42
Je te remercie d'avoir analysé ma classe d'objet.
La où effectivement nous n'avons pas le même point de vue, c'est sur la notion d'un objet.
Autant je suis d'accord avec toi que l'on construit une base de données de telle sorte qu'il y ait le moins de redondance possible dans les enregistrements, autant je vois un objet comme une entité possédant tout ce qui est nécessaire pour atteindre un but fixé.
C'est pour cela que je n'ai créé qu'une seule classe d'erreur. Celle-ci gère les différents type de problématiques que tu as ennoncé dans ton commentaire.
Quant à la classe elle même, elle gère plusieurs choses mais, au final, n'est faite que dans un seul but : Requêter et afficher des enregistrements.
Je comprends ton point de vue qui se veut le plus universel possible quant à l'exploitation et à la réutilisation des modules de classe.
Concernant l'impossibilité de générer la documentation à partir de mes commentaires, j'en suis désolé.
Merci encore pour tes critiques et suggestions constructives.
16 oct. 2009 à 09:50
Je viens de regarder la mise à jour, c'est mieux mais pas assez.
Déjà les points positifs :
- Tu as beaucoup documenté ton code avec des exemples
- Tu as une classe de gestion des erreurs
Remarques sur le style :
La documentation est bien mais pas exploitable car pas possible de la générer avec phpDoc ou doxygen. Le mieux serait que tu jettes un coup d'œil sur ces librairies, elles t'expliquent comment formater tes commentaires pour un générer une documentation online ou papier à partir de ton code. Utilises phpDoc il est implémenté dans Zend avec l'intellisense et donc on appelant une fonction t'as l'aide qui s'affiche automatiquement.
Remarques sur le fond :
T'as des classes, mais c'est toujours la même chose qu'avant. Je m'explique en prenant chaque élément en exemple :
-- Les erreurs :
Tu as commencé une gestion des Exception, c'est très bien, même parfait, mais tu n'as qu'une seule classe qui gére tout, du coup elle son utilisation est limitée.
Actuellement tu peux faire ceci :
try {
...fonction();
} catch(Err_PDO_Lekod $err) {
...gestion ?...
}
Ton erreur peut être de X types différents, donc dans ta gestion d'erreurs tu ne sais pas quoi faire à moins de tester le message. Les exceptions sont prévues autrement :
Pour chaque type d'erreur tu devrais avoir une classe :
class ExEcritureImpossible extends Exception ...
class ExVarNoNull extends Exception ...
... etc ... selon le nom de types d'erreurs
Ton code deviendra alors :
try {
...fonction();
} catch(ExEcritureImpossible $err) {
...que faire si pb d'écriture
} catch(ExVarNoNull $err) {
...que faire si pb de variables non définie
} catch(Exception $err) {
...que faire si autre problème
} finaly {
...que faire après un pb
}
-- La classe PDO_Lekod
Quand tu fais une classe, et qu'on te demande ce qu'elle fait, tu dois pouvoir répondre par un seul truc, elle fait ceci ou cela. Ta classe parcontre fait : la connexion à la base, le requettage, l'execution des requettes, la génération du formulaire, l'encryptage et décryptage ...etc...
Pour être plus précis je vais plus parler de POO mais de création d'une base de données. Lorsque tu fais une table elle stocke quoi ? Une seul type de truc : un utilisateur, une page, une news ...etc... Il te viendrais pas à l'idée de faire une table dans laquelle tu y mets tous les champs : infos user, infos page ... etc ...
Par analogie c'est la même chose en programmation objet, la découpe est similaire, chaque entité ayant un rôle spécifique aura une classe spécifique. Les objets pourront communiquer entre eux ... à travers soit des instances, soit à travers des appels statiques.
Là ou l'analogie s'arrête c'est au niveau de l'héritage et de la spécialisation.
Tu une classe exception, elle définit sa structure (comme une table dans une base)
Tu as plusieurs types d'erreurs, donc chaque type hérite de la classe exception en re-définissant des valeurs ou des fonctions.
C'est pas encore ça, mais c'est un début, donc bonne continuations.
10 déc. 2008 à 19:20
Effectivement, mon code pour tri.php a été écrit pour un besoin précis : Faire des formulaires pour trier et filtrer des données. Je n'ai effectivement pas été plus loin. J'essaye de développer un jeu en ligne et mon but étant de le réaliser au plus tôt, je pourvois à mes besoins en développant mes outils.
Si je pense que ces outils peuvent être utiles à d'autres, je les publie en espérant que cela pourra aider quelqu'un.
Etant seul pour tout faire, tu comprendras que je pare au plus pressé.
Merci encore pour ton investissement quant à l'élaboration d'une classe à partir de mon package.
Je vais déroger aux règles précitées et élaborer une ou plusieurs classes qui prennent en compte MySQL et Oracle.
Je prends note de tes commentaires et reviendrai lorsque j'aurai quelque chose de consistent à soumettre.
10 déc. 2008 à 10:14
Je m'explique :
La classe de tri :
abstract class BaseTri {
private $nbPages
...
}
En entrée tu aurais les paramètres de ton construct le s arguments de ta fonction, et cette fonction ne ferais que du calcul sur les variables que tu instance dans ta fonction.
Ensuite tu aurais une classe d'affichage :
class Tri extends BaseTri {
public function Header() {
return 'Pages :
';
}
public function __toString() {
...
}
}
Dedans tu définis son affichage - attention si tu veux qu'elle joue le role de template ne mets que des boucles du html ou bien des données provenant de la base. Exploses au max les fonctions, genre les les pages, header, footer ...
Alors maintenant ton code peut être repris et adapté sans que j'ai besoin de modifier tes fonctions :
class MonTri extends Tri {
public function Header() {
return 'Toto : ';
}
}
Et maintenant à moi de choisir quel affichage je veux :
echo new Tri(...);
ou bien
echo new MonTri(...);
Ton code est trop linéaire et donc spécifique à un besoin précis, exploses le au max pour qu'il soit plus générique.
Akh
9 déc. 2008 à 20:09
Je te remercie d'avoir pris le temps d'analyser et de suggérer des optimisations pour mon package PDO.
Je vais voir ce que je peux faire.
Néanmoins, je ne suis pas d'accord lorsque tu dis que je mélange HTML et PHP.
J'ai effectivement dans le guide de mise en place laissé sous-entendre qu'il y en avait car il est fort possible d'inclure mes fonctions au beau milieu de HTML.
La fonction function Init($Entete="",$Pied="") permet justement de ne passer que par du PHP; Il suffit pour cela de renseigner la valeur $Entete et $Pied.
Sur mon site, j'ai déja une fonction similaire qui renseigne les metas, le javascript commun et les liens js et css, ainsi qu'une autre pour la navigation du site et la fermeture des balises et <html>.
C'est pour cela que dans mon guide je ne montre que le texte qui apparaît avant les filtres et boutons de ma feuille Mondanites.php.
9 déc. 2008 à 18:10
- Déjà regardes comment tu peux le refaire en objet, en plus vu les blocks de php dans les fonctions tu dois encore plus découper en fonctions.
- Tu mélanges du PHP avec du HTML et vu que t'as pas de classes ça limite la réutilisation / adaptation en tant que tel
- Tu ne gères pas les erreurs correctement - au lieu de faire un echo 'Erreur ... oups ...' fais plûtot un threw new Exception('description'); et c'est au niveau du controleur que tu décideras de la catcher ou de l'ignorer ou autre.
Pour moi une piste serait de reprendre from skratch ton code en te disant j'ai quoi comme entités (un peu comme en merise pour les bases de données). Alors tu as :
SQL.php :
- Un connecteur (qui est un singleton)
- Un Requetteur
- Un Analyseur de Requettes
TRI.php :
- Une liste de résultats
Y'à pas mal de taf avant que ton code puisse être repris en tant qu'outil indépendant.
Bonne prog et bon courage,
Akh