Je vois pas mal de monde s'agiter sur le plugin ajaxforms.
Je tiens à rappeler qu'il est antérieur à la médiathèque, et que tout ce qui concerne l'upload de documents est bien plus avantageusement pris en charge par celle-ci qui reprend et mets au propre toute l'API SPIP concernant les documents et constitue le futur de ce qui sera intégré dans SPIP.
Il reste le cas des logos non encore traité par la médiatheque car je veux ré-implémenter toute la gestion des logos pour les stocker en base.
Tout ça pour dire qu'investir du temps et de l'énergie sur ajaxforms n'est peut-être pas très profitable.
Cédric
Le 4 mai 2010 à 09:40, gilles.vincent@gmail.com a écrit :
Author: gilles.vincent@gmail.com
Date: 2010-05-04 09:40:33 +0200 (Tue, 04 May 2010)
New Revision: 37969
Je sors également quelques affectations qui sont noyées dans des conditions PHP : en général on perd en lisibilité avec ce type de syntaxe.
Le seul avantage que j'y vois est quand on a des 'AND' en cascade dans les conditions (mais à ce niveau ça reste de la micro-optimisation, ça ne justifie pas beaucoup de rendre le code moins lisible..)
J’avais utilisé ce plugin car j’avais juste besoin d’un upload de logo depuis la partie publique.
Histoire d’être très logique, j’avais auparavant choisi le plugin « formulaire upload » pour la partie « upload de document ».
A aucun moment il ne m’est venu à l’idée d’utiliser un plugin « complet » comme la médiathèque, que je ne perçois pas comme une API.
Pour moi ce n’est pas du temps perdu : ça permet de maintenir ces plugin, d’en comprendre les principes, et d’appréhender ainsi plus facilement le macro-plugin médiathèque.
Et j’aime bien le côté minimaliste de ces deux plugins – donc faciles à intégrer et customiser
Je vois pas mal de monde s’agiter sur le plugin ajaxforms.
Je tiens à rappeler qu’il est antérieur à la médiathèque, et que tout ce qui concerne l’upload de documents est bien plus avantageusement pris en charge par celle-ci qui reprend et mets au propre toute l’API SPIP concernant les documents et constitue le futur de ce qui sera intégré dans SPIP.
Il reste le cas des logos non encore traité par la médiatheque car je veux ré-implémenter toute la gestion des logos pour les stocker en base.
Tout ça pour dire qu’investir du temps et de l’énergie sur ajaxforms n’est peut-être pas très profitable.
Je sors également quelques affectations qui sont noyées dans des conditions PHP : en général on perd en lisibilité avec ce type de syntaxe.
Le seul avantage que j’y vois est quand on a des ‹ AND › en cascade dans les conditions (mais à ce niveau ça reste de la micro-optimisation, ça ne justifie pas beaucoup de rendre le code moins lisible…)
je travaille actuellement sur le plugin « publication ouverte », version spip2.1 :
Je comptais initialement déléguer la partie upload de document et de logo à l’api ajaxforms, mais si j’ai bien compris, c’est sur le plugin mediathèque qu’il faudrait que je m’appuie ?
(D’ailleurs je viens de voir que ça s’appelle « gestion_documents », c’est plus parlant pour une api)
Question annexe : mon site n’utilise pas « Z » (et encore moins mediabox), pourtant nécessaire pour le plugin « gestion_documents » : ne serait-ce pas possible de séparer la partie traitement de la partie affichage (un plugin api_gestion_documents et le plugin gestion_document qui l’utilise) ?
Auquel cas on pourrait reprendre l’API sans être dépendant de l’affichage. C’est d’ailleurs la séparation qui s’était faite pour spip-bonux.
Je vois pas mal de monde s’agiter sur le plugin ajaxforms.
Je tiens à rappeler qu’il est antérieur à la médiathèque, et que tout ce qui concerne l’upload de documents est bien plus avantageusement pris en charge par celle-ci qui reprend et mets au propre toute l’API SPIP concernant les documents et constitue le futur de ce qui sera intégré dans SPIP.
Il reste le cas des logos non encore traité par la médiatheque car je veux ré-implémenter toute la gestion des logos pour les stocker en base.
Tout ça pour dire qu’investir du temps et de l’énergie sur ajaxforms n’est peut-être pas très profitable.
Je sors également quelques affectations qui sont noyées dans des conditions PHP : en général on perd en lisibilité avec ce type de syntaxe.
Le seul avantage que j’y vois est quand on a des ‹ AND › en cascade dans les conditions (mais à ce niveau ça reste de la micro-optimisation, ça ne justifie pas beaucoup de rendre le code moins lisible…)
je travaille actuellement sur le plugin "publication ouverte", version spip2.1 :
Je comptais initialement déléguer la partie upload de document et de logo à l'api ajaxforms, mais si j'ai bien compris, c'est sur le plugin mediathèque qu'il faudrait que je m'appuie ?
oui car il ne fait pas qu'implémenter les formulaires d'upload, mais toutes les fonctions sous jacentes ont été ré-écrites.
Cela remplacera à terme toute la gestion document du core qui est vraiment obsolète à tous points de vue. De ce fait ajaxforms n'est pas perenne car ne marchera plus à ce moment là.
(D'ailleurs je viens de voir que ça s'appelle "gestion_documents", c'est plus parlant pour une api)
Question annexe : mon site n'utilise pas "Z" (et encore moins mediabox), pourtant nécessaire pour le plugin "gestion_documents" :
non pas du tout, le plugin mediabox n'est pas nécessaire pour la mediatheque (bien que recommandé)
ne serait-ce pas possible de séparer la partie traitement de la partie affichage (un plugin api_gestion_documents et le plugin gestion_document qui l'utilise) ?
A priori non, cela ira plutôt dans l'autre sens, ce plugin etant prévu pour regrouper tout ce qui concerne la gestion des logos et documents de SPIP (donc API et interface privée réutilisable dans le public), ce qui permettra de supprimer toute cette partie du code du core.
je travaille actuellement sur le plugin « publication ouverte », version spip2.1 :
Je comptais initialement déléguer la partie upload de document et de logo à l’api ajaxforms, mais si j’ai bien compris, c’est sur le plugin mediathèque qu’il faudrait que je m’appuie ?
oui car il ne fait pas qu’implémenter les formulaires d’upload, mais toutes les fonctions sous jacentes ont été ré-écrites.
Cela remplacera à terme toute la gestion document du core qui est vraiment obsolète à tous points de vue. De ce fait ajaxforms n’est pas perenne car ne marchera plus à ce moment là.
(D’ailleurs je viens de voir que ça s’appelle « gestion_documents », c’est plus parlant pour une api)
Question annexe : mon site n’utilise pas « Z » (et encore moins mediabox), pourtant nécessaire pour le plugin « gestion_documents » :
non pas du tout, le plugin mediabox n’est pas nécessaire pour la mediatheque (bien que recommandé)
ne serait-ce pas possible de séparer la partie traitement de la partie affichage (un plugin api_gestion_documents et le plugin gestion_document qui l’utilise) ?
A priori non, cela ira plutôt dans l’autre sens, ce plugin etant prévu pour regrouper tout ce qui concerne la gestion des logos et documents de SPIP (donc API et interface privée réutilisable dans le public), ce qui permettra de supprimer toute cette partie du code du core.
je travaille actuellement sur le plugin « publication ouverte », version spip2.1 :
Je comptais initialement déléguer la partie upload de document et de logo à l’api ajaxforms, mais si j’ai bien compris, c’est sur le plugin mediathèque qu’il faudrait que je m’appuie ?
(D’ailleurs je viens de voir que ça s’appelle « gestion_documents », c’est plus parlant pour une api)
Question annexe : mon site n’utilise pas « Z » (et encore moins mediabox), pourtant nécessaire pour le plugin « gestion_documents » : ne serait-ce pas possible de séparer la partie traitement de la partie affichage (un plugin api_gestion_documents et le plugin gestion_document qui l’utilise) ?
Auquel cas on pourrait reprendre l’API sans être dépendant de l’affichage. C’est d’ailleurs la séparation qui s’était faite pour spip-bonux.
.Gilles
Bonjour Gilles,
Si tu bosses sur publication ouverte pour 2.1, je me demandais l’intérêt de repartir du plugin plutôt que des simples editer_article.html/php du /prive ? Suffit de mettre ça dans ton /squelettes/formulaires et tu as une publication ouverte (en définissant le statut à prop plutôt qu’à prep).
Je suppose qu’à porter en plugin avec les quelques ajouts nécessaires ça sera mille fois moins lourd que d’adapter le publication ouverte ?
Enfin, je me gourre peut être, mais je trouvais ça bizarre que publication ouverte réécrive les fonctions d’ajout d’articles plutôt que d’utiliser celles existantes.
Je vois pas mal de monde s’agiter sur le plugin ajaxforms.
Je tiens à rappeler qu’il est antérieur à la médiathèque, et que tout ce qui concerne l’upload de documents est bien plus avantageusement pris en charge par celle-ci qui reprend et mets au propre toute l’API SPIP concernant les documents et constitue le futur de ce qui sera intégré dans SPIP.
Il reste le cas des logos non encore traité par la médiatheque car je veux ré-implémenter toute la gestion des logos pour les stocker en base.
Tout ça pour dire qu’investir du temps et de l’énergie sur ajaxforms n’est peut-être pas très profitable.
Je sors également quelques affectations qui sont noyées dans des conditions PHP : en général on perd en lisibilité avec ce type de syntaxe.
Le seul avantage que j’y vois est quand on a des ‹ AND › en cascade dans les conditions (mais à ce niveau ça reste de la micro-optimisation, ça ne justifie pas beaucoup de rendre le code moins lisible…)
