- Statut : non résolu
- Ce sujet contient 61 réponses, 14 participants et a été mis à jour pour la dernière fois par
, le il y a 17 années et 8 mois.
-
Messages
-
Le problème, c’est justement que WordPress n’a connu aucun changement radical dans sa conception depuis la première release, ce qui fait que c’est peu à peu devenu un assemblage de code un peu n’importe comment, ce qui le fait de plus en plus ressembler à … PhpBB !! (et caÿ mal :fouet: )
Programmer Orienté Objet ne veut pas (forcément) dire n’utiliser fanatiquement que des classes ! Ce genre de conception se retrouve justement dans LifeType (je dirais même que c’est un cas extrême): toute action est dispersée dans de multiples fichiers, ce qui enlève tous les avantages qu’elle était censé apporter au développeur et en particulier :
** Lenteur extrême due aux multiples instanciations des différentes classes (même si toutes ne sont bien évidemment pas instanciées en même temps, je dirais qu’il y en a une bonne trentaine qui tournent en même temps pour chaque page appelée par un visiteur)
** Difficulté de maintenir le code étant donné la multitude de fichiers (quoi qu’en disent les puristes, pour moi le fait de partitionner à ce point son application n’aide pas au développement et aux mises à jour)AmO wrote:A ce sujet vous saviez que Google est codé à 90% en Python ?Oui, en particulier tout ce qui concerne la section d’aide 😉
AmO wrote:En passant Lifetype et le moteur de template Smarty… c’est pas vraiment une référence… très loin même !C’est clair 😕 😕 😕
P.S: AmO, pourrais-tu demander à ton expert ès PHP s’il peut se pencher 2 secondes sur mon problème de preg_replace ? 😇
MS-DOS_1991 wrote:Le problème, c’est justement que WordPress n’a connu aucun changement radical dans sa conception depuis la première release, ce qui fait que c’est peu à peu devenu un assemblage de code un peu n’importe comment, ce qui le fait de plus en plus ressembler à … PhpBB !! (et caÿ mal :fouet: )Programmer Orienté Objet ne veut pas (forcément) dire n’utiliser fanatiquement que des classes ! Ce genre de conception se retrouve justement dans LifeType (je dirais même que c’est un cas extrême): toute action est dispersée dans de multiples fichiers, ce qui enlève tous les avantages qu’elle était censé apporter au développeur et en particulier :
** Lenteur extrême due aux multiples instanciations des différentes classes (même si toutes ne sont bien évidemment pas instanciées en même temps, je dirais qu’il y en a une bonne trentaine qui tournent en même temps pour chaque page appelée par un visiteur)
** Difficulté de maintenir le code étant donné la multitude de fichiers (quoi qu’en disent les puristes, pour moi le fait de partitionner à ce point son application n’aide pas au développement et aux mises à jour)AmO wrote:A ce sujet vous saviez que Google est codé à 90% en Python ?Oui, en particulier tout ce qui concerne la section d’aide 😉
AmO wrote:En passant Lifetype et le moteur de template Smarty… c’est pas vraiment une référence… très loin même !C’est clair 😕 😕 😕
P.S: AmO, pourrais-tu demander à ton expert ès PHP s’il peut se pencher 2 secondes sur mon problème de preg_replace ? 😇
La difficulté d’un projet comme WordPress est de faire évoluer le produit sans pour autant perdre la compatibilité avec la gamme de plugins et des thèmes existantes 🙂
Je ne parlais pas spécialement des classes, meme si ca en fait parti, la modelisation objet passe logiquement par l’utilisation des classes, interfaces, etc 🙂
Edit : la comparaison à phpBB est peu flatteuse…
Expose ton problème dans le bar 🙂
Tu auras peut etre des réponses 🙂 j’enverrai mes experts sur le sujet 😉Comparaison peu flatteuse, certes, mais avoue qu’objectivement WP s’en rapproche un peu quand même, au moins en termes de temps d’exécution et de nombre de requêtes SQL par page (sans plugins) 😕
Surtout qu’il suffirait de pas grand chose pour l’optimiser un maximum (par exemple virer les requêtes qui ne ramènent qu’un champ à chaque fois comme l’a dit ccvddt)Attention ! J’aime beaucoup WordPress et je le préfère de loin à Dotclear 😉
P.S: Je vais de ce pas au bar
Je suis d’accord… sur ce point… pour moi les bloginfo() devrait etre dans un fichier de configuration…
Salut,
En lisant ton post, on a l’impression que tout devrait être parfait dans ce monde… et aussi fait selon ta vision, tes intérêts et tes compétences. N’oublie pas que WordPress est en Open Source et que tout le monde n’est pas comme toi.
Il y a plein de choses à améliorer dans WordPress, c’est sûr.
Par contre, la plupart de tes arguments ne tiennent pas la route ou relèvent du débutant en programmation!cdvddt wrote:o Utilisation a outrance de fonctions pour chaque champ,
dépendant d’un contexte scrict d’execution et de variables
globales le fameux ‘The_Loop’, la ou la programmation object
serait bien plus légere et souple.
Pourquoi reinventer une semantique lourde avec ces
concept fumeux de ‘tags’ ?Ou est l’utilite d’ecrire
while(the_post()) {
the_title();
}
au lieu de :
foreach($posts as post) {
echo $post->title;
}
Les fonctions, c’est le truc de base en programmation.
C’est le premier point de modularité d’un programme.
Par exemple, le jour où tu auras envie que the_title() retourne _e($post->title); au lieu de $post->title;
Tu modifieras juste le code de ta fonction et les N appels dans ton code seront mis à jour.
Alors que si tu code ‘en dur’, tu seras obligé de faire la modif partout!
C’est d’autant plus important avec le système de plugin, vu que tu si Autommatic fait une modif dans son code, il faut que les milliers de plugin qui utlisent leur API continuent de marcher correctement.
Jamais, on utilise des accès directs pour un programme qui se veut évolutif et modulaire !!!
Ce serait une erreur énorme de conception.cdvddt wrote:o Melange de fonctions d’affichage et de fonction remvoyant une valeur
sans aucnue uniformite dans les options :
A quoi sert t’il de developper une fonction affichant un truc et une autre
la renvoyant. php fournit des fonctions pour l’affichage …
est equivalent aParce WordPress s’adresse à des gens qui comprennent l’anglais et pas trop le php.
Et aussi parce WordPress s’adresse à des gens qui comprennent le php autant que l’anglais.
Suivant ce dont tu as besoin tu utilises l’un ou l’autre!
C’est sur que pour l’une ou l’autre catégorie d’utilisateur, ça fait du code en trop, mais les serveurs web sont maintenant assez costauds pour gérer tout ça.cdvddt wrote:o Soupe de mélange entre presentationet contenu.
Pourquoi diable la fonction list_cats s’occupe t’elle de formattage ?
Et si je veux pas de liste dans des- ? Je developpe un neime
plugin bancal pour faire une copie personnalisee de cette fonction ?
Une liste d’objects bien faits feriaent l’affaire, je sais faire une boucle :
$post->getCategories()
ou toutes les categories
$wp->allCategories();
Et un moyen de descendre dedans recursivement, genre
$cat->getChildCats();Tu sais peut-être faire une boucle, mais plein d’autres utilisateurs ne savent pas.
Regarde un peu le type de questions sur ce forum…
WordPress n’a pas été fait que pour toi.cdvddt wrote:o Passage de parametres farfelus.
J’ai jamais compris pourquoi il fallait passer
les parametres avec une chaine occulte genre « addchild=1&toto=truc »
php gere les passage de parametres optionnels et les parametres par defaut.Tu connais les URLs et les Query String ?
Les paramètres que gère PHP viennent de l’utilisateur qui communique de son navigateur au serveur par des URLs et en Query String…
Ca permet d’utiliser directement les Query Strings sans avoir à coder un parser… C’est un gain de temps, si, si…cdvddt wrote:o Les globales en folies :
La gestion de variables globales en php est une horreur, et son mecanisme
va a l’encontre des choix de tous les autres langages de programmation.
Pourquoi ne pas tout regrouper dans un unique object contenant tous
les object ‘contextuels’ nexcessaire a l’affichage de chaque page :
genre
$wp->
/* Des parametres globaux */
blogTitle
rssEntriesURL
rssCommentsURL
….
allPages (liste des pages)
allCategories (liste des categories)
recentPosts (liste d’object post)/* Les information sur le conetnu courant a afficher*/
currentEntries (list des posts/pages selectionnees)
context (contexte d’affichage : soit un unique post ()single, ou une categories, des mots clefs de recherche, etc)
currPageIdx
NbPages (pour la pagination)Le tout avec une utilisation intelligente de la programmtion object
pour se debarrasser de ce fouilli de fonctions inutiles.Encore une fois, même si tu fais des objets, il faudra faire des méthodes !
C’est une erreur de conception de laisser les variables en accès direct.Autrement, WordPress se veut pour le moment compatible avec PHP4, qui n’offre qu’un programmation orientée objet assez limitée (tous les attributs sont ‘public’, pas de ‘protected’ ou ‘private’).
En faisant un petit effort de souplesse d’esprit, ça revient donc strictement au même d’écrire $wp_blogTitle que $wp->blogTitle, pour les variables globales. (Au niveau exécution, c’est même plus rapide sans objet…)
Il faut attendre que WordPress passe complètement à PHP5 pour avoir beaucoup plus de code objet qui en vaille la peine.cdvddt wrote:Tout ca fait que le developpement de themes sous WordPress est lourd
et sale : C’est une suite de bidouillages tordus pour contourner
de gros problemes de conception.Voila,
Qu’en pensez vous ? Par ou commencer pour proposer une refonte en ce sens
du code de wordpress (je veux bien aider).Raphael
Il n’y a pas de programme parfait; ce sont juste des outils pour faire ce dont tu as besoin.
WordPress est peut-être lourd, mais son framework essaye de laisser le plus de souplesse possible.
Forcément, à un moment ça coince et il faut aller dans la bidouille.De tout ton post, ce qui en ressort, c’est que tu as l’air d’avoir des notions plutôt ‘théoriques’ sur la programmation !
Il y a plein d’autres outils de blog et conçus ‘orienté-objet’, si tu veux partir sur des bases ‘plus saines’, tu n’as qu’à les faire évoluer pour les rendre ‘meilleurs’ que WordPress. Alors ne t’inquiète pas, tout le monde utilisera ton logiciel. (Le monde de l’open source est assez Darwinien…)
Mais si tu t’es attaché un peu à WordPress (malgré toutes tes doléances), je te conseille de préparer la migration vers PHP5.Have Fun.
LH wrote:Salut,cdvddt wrote:o Melange de fonctions d’affichage et de fonction remvoyant une valeur
sans aucnue uniformite dans les options :
A quoi sert t’il de developper une fonction affichant un truc et une autre
la renvoyant. php fournit des fonctions pour l’affichage …
est equivalent aParce WordPress s’adresse à des gens qui comprennent l’anglais et pas trop le php.
Et aussi parce WordPress s’adresse à des gens qui comprennent le php autant que l’anglais.
Suivant ce dont tu as besoin tu utilises l’un ou l’autre!
C’est sur que pour l’une ou l’autre catégorie d’utilisateur, ça fait du code en trop, mais les serveurs web sont maintenant assez costauds pour gérer tout ça.Sans compter que toutes les fonctions type the_title() (faisant un echo $post->title, en gros), disposent d’un équivalent get_the_*, comme get_the_title() (faisant simplement return $post->title, plutôt qu’un echo). Mais bon, pour savoir ça, faut lire le Codex.
[c] 19 function the_title($before = », $after = », $echo = true) {
20 $title = get_the_title();
21 if ( strlen($title) > 0 ) {
22 $title = apply_filters(‘the_title’, $before . $title . $after, $before, $after);
23 if ( $echo )
24 echo $title;
25 else
26 return $title;
27 }
28 }
29
30
31 function get_the_title($id = 0) {
32 $post = &get_post($id);
33
34 $title = $post->post_title;
35 if ( !empty($post->post_password) )
36 $title = sprintf(__(‘Protected: %s’), $title);
37 else if ( ‘private’ == $post->post_status )
38 $title = sprintf(__(‘Private: %s’), $title);
39
40 return $title;
41 }[/c]Vous êtes durs avec lui, je trouve 😕 :fouet:
Ces récriminations sont pour la plupart justifiées, même si leur implémentation impliquerait de perdre la facilité d’utilisation qui a rendu WordPress accessible aux débutants (je dirais même aux pré-techno-réfractaires
)Le plus gros problème, c’est que si on touche à quoi que ce soit, presque tous les plugins / thèmes existants ne fonctionneront plus du tout 😕 😕 😕
Après, tu peux toujours te développer toi-même une version de WP améliorée, mais tu ne pourras plus compter sur des mises à jour officielles pour corriger d’éventuels bugs 😉
la programmation objet (OOP) est une illusion si elle ne s’applique pas à une application entièrement orienté objet (OO).
l’OO ne date pas d’hier (OOP par Brad J. Cox 1986) et l’expérience a montré que la reprogrammation en OO d’applications existantes ne conduisait à rien de bon ; alors que les bénéfices importants sont pour les applications conçues OO dès l’analyse (OOA), la conception (OOD) puis la programmation (OOP) ; avec une bonne perception du « problem space », les besoins réels des utilisateurs.
Dotclear 2 a été cité. Il est la reprogrammation dans le modèle OO de PHP5 de Dotclear 1 ; ce dernier n’a rien d’OO dans sa conception. Le choix du PHP5 OO entraine des contraintes importantes, en particulier pour les plateformes supportées. L’application de type blog est toutefois limitée au support de billets texte essentiellement. L’absence de OOA et OOD pourrait ne pas être trop préjudiciable (ou visible).
Un code donné PHP ou autre doit avoir pour caractéristique première de fonctionner correctement sur les plateformes d’accueil. Ensuite d’être efficace et performant. La qualité du style et la documentation du code viennent ensuite.
Les critiques faites sur le style de programmation de WordPress ne seraient fondées que si elles entrainent des pertes d’efficacité ou de performance. Ce que ne démontre pas les exemples donnés.
Il ne faut pas se focaliser sur le style. Certains sont connus pour : « style appliqué, réalisation médiocre ». Ceci dit une unité de style facile la compréhension du code, la recherche et correction d’erreurs, l’apport d’autres programmeurs…
[parenthèse]Je pense que si on veut faire du code « parfait » en termes de conception et d’OO, java est un langage plus adapté, car complètement bati sur ces principes alors que PHP, un peu comme le C/C++, évolue d’une conception fondamentalement procédurale vers de l’OO. Plus PHP évolue et plus il essaye de ressembler à du java, perdant ce qui à mon avis faisait son intéret, à savoir d’etre un langage de script simple et permettant de faire du RAD tout en ayant à disposition un ensemble de fonctionnalités orientées vers le web. Dans PHP6, on aura surement le front controller à la struts ou les JSF, des ORMs et j’en passe, et il faudra un phD pour être capable de pondre un bout de code correct.[/parenthèse]
Indépendament des considérations sur l’OO ou pas OO, il y a clairement des innefficacités dans WP. Quand je regarde en bas d’une page bbpress, je vois « 7 requetes », « 10 requetes » pour punbb ou « 12 requetes » pour vbulletin. Quand je regarde en bas d’un blog wordpress, je vois parfois « 68 requetes », parfois « 130 requetes »… Un blog n’étant pas fondamentalement plus compliqué qu’un forum, je me dis qu’il y a un problème dans la conception de la manière de stocker et d’accéder aux données. Quand après je regarde ces requetes, et que je vois que le meme script exécute plusieurs fois *exactement* la meme, ou effectue 3 requetes séparées pour ramener 3 colonnes de la meme ligne, je me dis qu’il y a encore beaucoup à faire pour faire de WP un soft vraiment efficace.
Ce problème de requête pourrait être réglé en passant sous MySQL 5 et en profitant ainsi des procédures stockées (dont je suis un grand fan) encore que celle de MySQL ne sont pas encore très poussé à ma connaissance (manque le traitement de donnée). Cependant, cela ne semble pas dans être leur intention et je peux comprendre (pas facile de migrer tout ca !).
Je pense plutôt qu’il vaudrait mieux (si toutefois il y a retouche au niveau de la gestion des données) utiliser PDO, afin d’offrir un minimum de choix dans la base de données. Ainsi un utilisateur qui souhaiterai une bdd PostgreSQL n’aurai pas de grosse adaptation à faire, en particulier pour les gens voulant utiliser WpMU pour une utilisation orienté professionnel.
Oui mais PDO n’est pas un standard sur les serveur web… de ce fait pas compatible avec une application orienté grand public…
Mais c’est vrai que l’utilisation des sous requêtes va etre vachement pratique…
Actuellement WP est compatible MySQL3 et donc ne tire pas parti des fonctionnalités apparu depuis la version 4.2 (ou quelque chose comme ca)La version 2.1 devrait allé dans ce sens.
Tout comme l’usage abusif de bloginfo() dans les thèmes abusent et qui est l’une des sources de ces innombrables requêtes…A quand ces informations dans un fichier de config ?
- ? Je developpe un neime
- Vous devez être connecté pour répondre à ce sujet.