ATOMIK FRAMEWORK
coucou747
Messages postés
12303
Date d'inscription
mardi 10 février 2004
Statut
Membre
Dernière intervention
30 juillet 2012
-
30 juin 2007 à 12:10
coucou747 Messages postés 12303 Date d'inscription mardi 10 février 2004 Statut Membre Dernière intervention 30 juillet 2012 - 2 juil. 2007 à 18:31
coucou747 Messages postés 12303 Date d'inscription mardi 10 février 2004 Statut Membre Dernière intervention 30 juillet 2012 - 2 juil. 2007 à 18:31
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/43289-atomik-framework
https://codes-sources.commentcamarche.net/source/43289-atomik-framework
2 juil. 2007 à 18:31
2 juil. 2007 à 15:55
Pour les variables globales, je sais très bien que ce n'est pas un choix conseillé ! Je débute pas en PHP va ! mais ici ça simplifie et la vie de l'utilisateur et la mienne ! parfois il faut savoir sortir des modeles de conception standard (t'inquiete je maîtrise tout mes design patterns...). L'utilisation de variables globales allège le code et simplifie la configuration dans mon cas, puisque tout tient dans un script. Et puis elle sont toutes prefixées d'un underscore, on écrit rarement c'est variable en commençant par un underscore nan ? (sauf dans les classes pour certaines propriétés, mais pas de problème là !)
2 juil. 2007 à 07:14
# {
# $rows[] = $row;
# if($unique) break;
# }
# if($unique) $rows = $rows[0];
avec ca serait mieux comme ca :
if(!$unique){
while($row = $_database_func_fetch($results))
{
$rows[] = $row;
}
return $rows;
}else{
return $_database_func_fetch($results);
}
sinon, avoit tout un tas de variables globales, c'est... pas top, car ca empeche l'utilisateur de choisir les memes noms de variables
30 juin 2007 à 14:36
Maintenant sur le db_insert, ne l'utilise pas si c'est pour faire des inserts complexes, ce n'est pas le but de la fonction. Elle sert simplement pour les inserts communs.
J'ai des " effectivement, et si tu regarde de plus près ils sont justifiés par l'utilisation de caractère d'échappements, toutes les autres chaînes utilisent des simples quotes.
db_select gère maintenant les erreurs, mais les autres fonctions renvoi le résultat brut de la fonction, donc chacun peut gérer ses erreurs.
Pour la gestion des exceptions, il doit être compatibles PHP4 donc pas d'exceptions. en revanche j'ai rajouter la gestion des erreurs simples.
Pour la non gestion des erreurs des touch, mkdir et compagnie: il sont utilisés en mode console, les erreurs php sont donc affichées. Je ne veux pas que le script s'arrête sur une erreur. C'est volontaire.
Voila, c'est vraiment quelque chose de minime ! Il ne faut pas chercher à gérer des choses complexes. J'ai fait ça après avoir aider un ami sur un petit projet où un mini cadre applicatif rendé l'appli plus claire.
C'est une sorte d'introduction au framework, il ne faut pas le prendre autrement. Comme je l'ai dit, j'ai un autre framework, bien plus complet !
30 juin 2007 à 14:12
pour ta fonction insert, par rapport a un query simple, t'as des concatenations en plus, or ca ne simplifie pas beaucoup...
t'as pas de verification pour tes fopen et querys touch et autre
t'as des "
db_select ne gere pas les eventuelles erreurs idem pour toutes tes fonctions sql
30 juin 2007 à 13:47
Pour l'optimisation, je vois pas pourquoi tu dis ça. Dans tous les cas tu ferais la même chose. Le seul cas où cette fonction n'est pas optimisée, c'est lorsque tu veux récupèrer la première ligne alors que la requête en renvoie plusieurs (je changerais ça d'ailleurs). Pour le reste elle est tout à fait standard et ne provoque aucun ralentissement.
30 juin 2007 à 13:25
30 juin 2007 à 13:09
30 juin 2007 à 12:10
t'as aucune getion des Exception, aucune classe, db_fetch_results si tu veux une seule ligne, elles sont quand meme toutes extraites (cote vitesse... bof)