J'ai eu beau parcourir les différents sites de la galaxie SPIP, je n'ai pas encore trouvé de doc claire sur l'état de l'art du développement de plugins pour SPIP 2, c'est à dire ce qu'il y a de plus optimal à faire quand on ne cherche pas à être compatible avec SPIP 1.9.
Pas moyen de trouver deux plugins codés de la même manière : installation/désinstallation, pages privées en squelettes, cron ou genie, etc.
Du coup, j'ai une première question pour amorcer une collecte de bonnes pratiques :
De quelle manière dois-je constituer les pages privées pour qu'elles profitent de la mise en page par défaut (et des nouvelles "robes") ?
Je suis tombé sur des trucs comme ça par exemple :
[(#VAL|debut_gauche{true})]
[(#VAL|debut_cadre_enfonce{true})]
[(#VAL{true}|fin_cadre_enfonce)]
[(#VAL|debut_droite{true})]
[(#VAL|debut_cadre_relief{true})]
Etc.
Est-ce la bonne méthode ?
Pourquoi dans ce cas passe-t-on parfois {true} à #VAL, et parfois au filtre ?
[(#VAL|debut_gauche{true})]
[(#VAL|debut_cadre_enfonce{true})]
[(#VAL{true}|fin_cadre_enfonce)]
[(#VAL|debut_droite{true})]
[(#VAL|debut_cadre_relief{true})]
Etc.
Est-ce la bonne méthode ?
Comme pour l'instant il n'y a pas encore de modèles (au sens SPIP) ou de fonds réutilisables, oui c'est une bonne méthode si tu veux faire tes pages privées en squelettes.
Pour certaines des fonctions c'est pas forcément appréciable car je crois me rappeler qu'il y en a qui génèrent du code pas super "propre".
Pourquoi dans ce cas passe-t-on parfois {true} à #VAL, et parfois au
filtre ?
Ça c'est comme tous les filtres : la balise sur laquelle on fait le filtre constitue le premier argument, alors que les accolades qui viennent ensuite c'est le deuxième argument (puis 3ème, etc).
Donc tout dépend si dans ce filtre précis il y a un booléen à mettre en premier ou deuxième argument.
[(#VAL|debut_gauche{true})]
[(#VAL|debut_cadre_enfonce{true})]
[(#VAL{true}|fin_cadre_enfonce)]
[(#VAL|debut_droite{true})]
[(#VAL|debut_cadre_relief{true})]
Etc.
Est-ce la bonne méthode ?
Comme pour l'instant il n'y a pas encore de modèles (au sens SPIP) ou de fonds réutilisables, oui c'est une bonne méthode si tu veux faire tes pages privées en squelettes.
Pour certaines des fonctions c'est pas forcément appréciable car je crois me rappeler qu'il y en a qui génèrent du code pas super "propre".
Mais du coup, prévoir dès maintenant les modèles ou noisettes permettant de structurer la page, en reprenant proprement ce que font ces filtres/fonctions, serait intéressant, non ?
Pourquoi dans ce cas passe-t-on parfois {true} à #VAL, et parfois au
filtre ?
Ça c'est comme tous les filtres : la balise sur laquelle on fait le filtre constitue le premier argument, alors que les accolades qui viennent ensuite c'est le deuxième argument (puis 3ème, etc).
Donc tout dépend si dans ce filtre précis il y a un booléen à mettre en premier ou deuxième argument.
OK. Du coup faut vraiment pas se tromper dans les exemples que j'ai cités...
[(#VAL|debut_gauche{true})]
[(#VAL|debut_cadre_enfonce{true})]
[(#VAL{true}|fin_cadre_enfonce)]
[(#VAL|debut_droite{true})]
[(#VAL|debut_cadre_relief{true})]
Etc.
Est-ce la bonne méthode ?
Comme pour l'instant il n'y a pas encore de modèles (au sens SPIP) ou de fonds réutilisables, oui c'est une bonne méthode si tu veux faire tes pages privées en squelettes.
Non, c'est horrible.
On va déjà galèrer à se débarrasser de toute cette tripaille datée dans le php, il serait sympa de pas en recoller dans le html.
La bonne méthode, pérenne, c'est ça :
- ce squelette est pris en charge par exec/fond.php quand on visualise ecrire/?exec=controler_urls
- le premier <hn> de la page est automatiquement repris en title
- le contenu entre
<!--#navigation-->
et
<!--/#navigation-->
est placé dans la colonne navigation. idem pour
<!--#extra-->
et
<!--/#extra-->
Pour certaines des fonctions c'est pas forcément appréciable car je crois me rappeler qu'il y en a qui génèrent du code pas super "propre".
Mais du coup, prévoir dès maintenant les modèles ou noisettes permettant de structurer la page, en reprenant proprement ce que font ces filtres/fonctions, serait intéressant, non ?
Pourquoi dans ce cas passe-t-on parfois {true} à #VAL, et parfois au
filtre ?
Ça c'est comme tous les filtres : la balise sur laquelle on fait le filtre constitue le premier argument, alors que les accolades qui viennent ensuite c'est le deuxième argument (puis 3ème, etc).
Donc tout dépend si dans ce filtre précis il y a un booléen à mettre en premier ou deuxième argument.
OK. Du coup faut vraiment pas se tromper dans les exemples que j'ai cités...
Pitié, évitons de pérenniser tout cela, vraiment.
Cédric
Pas de doc officielle pour le moment. C’est une fonctionnalité amenée sur la version dev, et ajoutée sur la version stable ensuite pour permettre le support multi version des plugins.
J'ai ajouté un message d'avertissement sur la page concernée.
Je suis à l'origine de cette page qui je l'espère en a dépanné plus d'un.
Elle a été élaborée en son temps à partir des upgrades réels constatés sur la zone
mais ceux ci n'étaient pas forcément optimum ...
ou peuvent être maintenant déjà dépassés.
Puisque tu as indiqué des bons liens
- en réponse à une question déjà posée sur la zone et restée longtemps sans réponse -
j'ai complété ton message d'avertissement par ces bons liens !
Je viens de découvrir cette page, qui doit beaucoup participer à la
pérennité de codes obsolètes : PortageV2 : Migrer un plugin vers SPIP2
J'ai ajouté un message d'avertissement sur la page concernée.
Je suis à l'origine de cette page qui je l'espère en a dépanné plus d'un.
Je le pense !
Je signalais juste qu'elle ne correspond pas à l'état de l'art comme le signale Cédric, mais plutôt à ce qu'il faut faire à minima pour rendre opérationnels de vieux développements.
Elle a été élaborée en son temps à partir des upgrades réels constatés sur la zone
mais ceux ci n'étaient pas forcément optimum ...
ou peuvent être maintenant déjà dépassés.
Puisque tu as indiqué des bons liens
- en réponse à une question déjà posée sur la zone et restée longtemps sans réponse -
j'ai complété ton message d'avertissement par ces bons liens !
Je corrige « état de l’Art en Juin 2006 » par « état de l’Art en juin 2009 »...
