Salut les devs, et en particulier les pros des questions style architecture,
performances, etc...
Je manque un peu d'arguments face à un nouveau web-dev (profil plutôt PHP,
Zend...) qui vient de rejoindre à notre équipe, et se met à SPIP pour la
première fois. Les reproches qu'il formule :
- les boucles posent un pb de performance comparé à la possibilité d'écrire
soi-même les requêtes SQL -> génère des requêtes trop complexes pour ce qu'on
veut faire, d'où pb de lenteur dans l'application
- le principe d'écriture de plugins ne permet pas une réactivité nécessaire dans
la mise à jour du code : ajout d'une nouvelle icône dans le menu de l'espace
privé associé à l'URL de la page appelée (?exec=toto). Une modification de la
page appelée n'est pas mise à jour instantanément, malgré vidage de cache,
obligé de désactiver le plugin puis de le réactiver pour prendre en compte ces
modifs. D'où une certaine lourdeur dans le développement s'il faut faire ça à
chaque mise à jour du code.
Quelles avantages tire-t-on en contre partie de l'architecture et du principe de
fonctionnement de SPIP tel qu'il est à l'heure actuelle ?
A t-on de la littérature sur le sujet ?
- les boucles posent un pb de performance comparé à la possibilité d'écrire
soi-même les requêtes SQL -> génère des requêtes trop complexes pour ce qu'on
veut faire, d'où pb de lenteur dans l'application
Les boucles n'empêchent pas d'écrire du PHP à la main. Par contre :
* Écrire du PHP avec des failles genre SQL injection, c'est facile.
C'est beaucoup plus dur avec des boucles.
* Le cache de SPIP permet quand même de limiter les problèmes de perf.
Ceci dit, je suis loin d'être un spécialiste en la matière.
Je me souviens t’avoir dit il y a 8 jours méfie toi des dev php tout juste sorti du moule qui s’imaginent que c’est toujours plus simple et plus facile de refaire a chaque fois leur petit CMS à la main brut de fondrerie, réinventé la roue etc …
Souvent parce qu’ils ont pas encore pris la peine de comprendre la logique SPIP et ils se confortent dans leurs connaissances acquises sans chercher plus loin ^^
Pour en avoir parlé avec des dev PHP qui sont devenus dev SPIP par la suite, on ne citera pas de noms, tu vois de qui je veux parler ^^ il n’y a quasi aucune requete qui ne puisse se faire en SPIP.
Faut juste faire un petit effort au début, de conversion, effort qui doit paraitre à votre nouvelle recrue démesurée par ce qu’il ne perçoit pas encore tout le temps précieux que lui fera gagner SPIP par la suite, et il pense encore qu’en php et sql il aurait torché le truc en 10 minutes.
En revanche ces connaissances seront précieuse pour tous les filtres maisons dont vous aurez besoin et diverses plugins sur mesure etc …
Tu devrais lui offrir un programmer SPIP pour Noel ! lol
Salut les devs, et en particulier les pros des questions style architecture,
performances, etc...
Je manque un peu d'arguments face à un nouveau web-dev (profil plutôt PHP,
Zend...) qui vient de rejoindre à notre équipe, et se met à SPIP pour la
première fois. Les reproches qu'il formule :
- les boucles posent un pb de performance comparé à la possibilité d'écrire
soi-même les requêtes SQL -> génère des requêtes trop complexes pour ce qu'on
veut faire, d'où pb de lenteur dans l'application
La complexité éventuelle se compare aussi au temps passé, maitrise
exacte du langage, ....
- le principe d'écriture de plugins ne permet pas une réactivité nécessaire dans
la mise à jour du code : ajout d'une nouvelle icône dans le menu de l'espace
privé associé à l'URL de la page appelée (?exec=toto). Une modification de la
page appelée n'est pas mise à jour instantanément, malgré vidage de cache,
obligé de désactiver le plugin puis de le réactiver pour prendre en compte ces
modifs. D'où une certaine lourdeur dans le développement s'il faut faire ça à
chaque mise à jour du code.
Là je comprends pas trop la question.
Une partie de l'espace privé se squelettise et par conséquent tous les
services ?var_mode=recalcul et consorts sont fonctionnels
La maitrise de plugin.xml permet d'ajouter comme on le souhaite et
simplement une icone dans le menu
Quelles avantages tire-t-on en contre partie de l'architecture et du principe de
fonctionnement de SPIP tel qu'il est à l'heure actuelle ?
Cela évite de réinventer la roue c'est le principe des outils qu'on
met dans la catégorie framework ou CMS
Cela fait 80% du boulot pour 20% de fatigue et non le contraire.
Merci Matthieu, Alex, Km et Pierre d'avoir pris le temps de répondre à ces
points, dont j'ai fait une petite synthèse. Je ne manquerai pas de transmettre
cet article intéressant sur le blog.
@Alex, Oui oui, ces "remarques" ont commencées à apparaître que récemment. Il se
réfère déjà à Programmer SPIP en ligne, je lui ai filé le lien :=)
@Km et Pierre, il utilise plugin.xml, insère une icône dans le menu via piplines
mais les modifs de son code ne sont pas prises en compte (la destination du lien
correspondant au bouton, en l'occurrence). Mais si un simple refresh de
ecrire/?exec=admin_plugin sans avoir à décocher puis recocher le plugin, ça
devrait déjà être plus jouable.
- les boucles posent un pb de performance comparé à la possibilité d'écrire
soi-même les requêtes SQL -> génère des requêtes trop complexes pour ce qu'on
veut faire, d'où pb de lenteur dans l'application
Le dev peut jeter un coup d'oeil aux requetes SPL générées par un squelette avec &var_mode=debug; il s'apperevra que celles-ci sont parfaitement optimisées, et sont loin d'être "trop complexes" par rapport à ce qu'il pourrait faire à la main, de manière sécurisée; en revanche, le fameux cache de SPIP (que le monde entier nous envie...) augmente significativement la rapidité des page servies (les requetes sont exécutées une fois, le résultat est mis en cache pour être servi en http)
- le principe d'écriture de plugins ne permet pas une réactivité nécessaire dans
la mise à jour du code : ajout d'une nouvelle icône dans le menu de l'espace
privé associé à l'URL de la page appelée (?exec=toto). Une modification de la
page appelée n'est pas mise à jour instantanément, malgré vidage de cache,
obligé de désactiver le plugin puis de le réactiver pour prendre en compte ces
modifs. D'où une certaine lourdeur dans le développement s'il faut faire ça à
chaque mise à jour du code.
le vidage du cache par la 2ème icone "Images calculées automatiquement" permet de remettre à jour les fichiers stockés dans les caches de /local/ ce qui suffit pour que les mises à jour s'affichent après un simple rafraichissement de la page.
En complément, pour forcer le recalcul des pages du plugin en cours de développement, tu peux paramétrer dans les options du plugin la variable $GLOBALS['marqueur'] de cette manière :
D'une manière générale, comme le dit Alexandra, le(s) intérêt(s) majeurs d'utiliser SPIP sont :
1. de ne pas avoir à réinventer la roue ...
et
2. d'utiliser un système fiable, mature, pérenne...
3. de bénéficier d'une mutualisation extra-ordinaire des compétences / connaissances/ savoirs-faire
Merci à toi pour ces précisions, que j'ajoute à ma petite synthèse, maintenant
j'ai de quoi répondre !
Ca vaudrait bien un petit papier sur le blog, ça, genre "SPIP : les questions de
perf et sécurité pour les nuls"
