Si quelqu'un a envie de se lancer, j'ai jeté quelques notes pour un
futur "formulaire de contact" -- mais j'ai d'autres trucs à faire
présentement
formulaire de contact
----------------------------
ce plugin doit rester assez simple pour être éventuellement intégré
dans le core.
email_webmaster :
indiquez ci-dessous l'adresse email ou le numéro d'auteur des
responsables du site (séparés par des virgules). Ces responsables
recevront les messages du formulaire de contact
#FORMULAIRE_CONTACT
(prévoir extensibilité facile du formulaire CVT avce des champs complémentaires)
(stocker dans la table spip_messages ?)
Si quelqu'un a envie de se lancer, j'ai jeté quelques notes pour un
futur "formulaire de contact" -- mais j'ai d'autres trucs à faire
présentement
formulaire de contact
----------------------------
ce plugin doit rester assez simple pour être éventuellement intégré
dans le core.
email_webmaster :
indiquez ci-dessous l'adresse email ou le numéro d'auteur des
responsables du site (séparés par des virgules). Ces responsables
recevront les messages du formulaire de contact
#FORMULAIRE_CONTACT
(prévoir extensibilité facile du formulaire CVT avce des champs complémentaires)
(stocker dans la table spip_messages ?)
pied : [#EMAIL_WEBMESTRE ? #URL_PAGE{contact}]
contact.html : #FORMULAIRE_CONTACT
Bon il y a déjà depuis cette semaine le plugin contact_avance.
J'étais en train d'en faire un et comme il est un peu différent :
configuration de la liste des destinataires, choix des champs et de leur caractère obligatoire ou non
je l'ai comité.
un peu plus d'explication sur contrib prochainement.
Merci d'avance pour vos retours et libre participation, modification....
Bon il y a déjà depuis cette semaine le plugin contact_avance.
J'étais en train d'en faire un et comme il est un peu différent :
configuration de la liste des destinataires, choix des champs et de leur
caractère obligatoire ou non
Le plugin contact_avance a bien pour but de faire ça, et le fait déjà en partie.
Cf les éléments barrés (donc déjà fonctionnels) sur Formulaire de contact avancé - SPIP-Contrib
Je crois que ça sert à rien de multiplier les projets pour faire la même chose. Il faut qu'on développe tous ensemble.
Il reste deux bizarreries ici :
- pourquoi besoin de BONUX ?
Essentiellement parce que le plugin qui se configure avec CFG stocke plusieurs paramètres qui se récupèrent en tant que tableaux PHP et sur lesquels il faut ensuite boucler :
- le choix des destinataires
- les champs supplémentaires (et ceux qui sont obligatoires)
- le nombre de pièces jointes maximum
Il faut alors ensuite les parcourir simplement et lisiblement pour les afficher dans le HTML, et la boucle POUR est clairement indiquée pour cela. (Cf. formulaires/contact.html)
D'ailleurs ça me fait penser à un truc :
Pouvoir boucler sur des tableaux dans un squelette, j'en ai besoin super souvent et j'ai l'impression que ça facilite les choses pour de plus en plus de monde.
Cédric avait mis les nouvelles boucles dans un plugin car ça n'avait pas été validé pour la version 2.0, afin de ne pas la retarder encore plus. Mais maintenant que ça fait plusieurs mois que beaucoup de gens les utilisent, ne faudrait-il pas penser à les valider et à les intégrer dans la prochaine version mineure (2.0.9) ou majeure (2.1) ?
Elles ne vont pas rester dans un plugin éternellement quand même ? Ce sont des boucles généralistes qui ne touchent pas un domaine particulier, donc elles doivent à priori se trouver à terme dans le noyau, non ?
En plus ça résoudrait justement le problème que de plus en plus de plugins ont une dépendance à Bonux alors que ce dernier mélange boucles, critères et nouvelle CSS.
- lequel des deux plugins faut-il utiliser ? Et lequel passer en
archives sur contrib ?
Sur contrib, la doc à jour est "Formulaire de contact avancé". Il faut donc effectivement mettre "Formulaire de contact configurable" en archive.
Mais maintenant que ça fait plusieurs mois que beaucoup de gens les utilisent, ne
faudrait-il pas penser à les valider et à les intégrer dans la prochaine
version mineure (2.0.9) ou majeure (2.1) ?
oui je le pense aussi, même si je ne suis toujours pas persuadé que la
syntaxe soit la bonne
Sur contrib, la doc à jour est "Formulaire de contact avancé". Il faut donc
effectivement mettre "Formulaire de contact configurable" en archive.
Oui, le squelette de contrib de prend apparemment pas en compte le mot-clé "archive" (à quoi il sert alors ?). Il faut donc peut-être créer une rubrique "Archive".
En plus ça résoudrait justement le problème que de plus en plus de plugins ont une dépendance à Bonux alors que ce dernier mélange boucles, critères et nouvelle CSS.
Oui faut le démonter ce Bonux. Ca me rend fou les complications induites par ce plugin de bougonage là maintenant que j'ai arreté de fumer et que je m'enerve facilement ^^.
J'ai commencé à isoler les agrégateurs sql dans le plugin "agregateur sql", sur ce marcimat a complété ces fontions là dans Bonux, donc je vais devoir reporter... Quel bordel.
Bonux doit pouvoir se découper proprement :
- interface privée à la Bonux
- boucles etendues
- agrégateurs sql
- c'est tout ?
- interface privée à la Bonux
- boucles etendues
- agrégateurs sql
- c'est tout ?
Évidemment !
Et quand on aura dépecé le Bonux, il ne devra plus rien en rester. Même pas son nom, qui fut précisément choisi pour désigner le caractère fourre-tout de pacotille dudit plugin.
Mais maintenant que ça fait plusieurs mois que beaucoup de gens les utilisent, ne
faudrait-il pas penser à les valider et à les intégrer dans la prochaine
version mineure (2.0.9) ou majeure (2.1) ?
oui je le pense aussi, même si je ne suis toujours pas persuadé que la
syntaxe soit la bonne
si on intégère à la 2.1, faut inventer un synatxe pour plugin.xml qui dit "necessite spip-bonux" sous Spip 2.0 mais pas spip-bonux sous spip 2.1
Sur contrib, la doc à jour est "Formulaire de contact avancé". Il faut donc
effectivement mettre "Formulaire de contact configurable" en archive.
- interface privée à la Bonux
- boucles etendues
- agrégateurs sql
- c'est tout ?
Évidemment !
Et quand on aura dépecé le Bonux, il ne devra plus rien en rester. Même pas son nom, qui fut précisément choisi pour désigner le caractère fourre-tout de pacotille dudit plugin.
En plus, il n'y a rien à jeter dans bonux, c'est un peu comme avec le cochon.
S'il vous plaît, je veux aussi les pieds paquets
pierre
ps : je râle juste un peu de ne plus pouvoir faire fonctionner #TRI dans une pagination ajaxée...
Voilà, pour les chanceux qui utilisent bonux, le plugin Polyhierarchie a été publié :
Cédric
Le 9 juil. 09 à 13:04, romy@rezo.net a écrit :
Le 09 juil. 2009 à 12:33, BoOz a écrit :
Bonux doit pouvoir se découper proprement :
- interface privée à la Bonux
- boucles etendues
- agrégateurs sql
- c'est tout ?
Évidemment !
Et quand on aura dépecé le Bonux, il ne devra plus rien en rester. Même pas son nom, qui fut précisément choisi pour désigner le caractère fourre-tout de pacotille dudit plugin.
Et quand on aura dépecé le Bonux, il ne devra plus rien en rester. Même pas son nom, qui fut précisément choisi pour désigner le caractère fourre-tout de pacotille dudit plugin.
Naaan tu exagères !
Mais si il y a cette demande, n'est-ce pas parce qu'il lui manque
un système de choix des fonctionnalités (oui / non)
qui briserait les regrets des ultimes utilisateurs réticents ?
(comme le fait le par-d'autres-honni couteau Suisse...)
Mais si il y a cette demande, n'est-ce pas parce qu'il lui manque
un système de choix des fonctionnalités (oui / non)
qui briserait les regrets des ultimes utilisateurs réticents ?
(comme le fait le par-d'autres-honni couteau Suisse...)
Non parce que Bonux n'a jamais eu pour vocations d'être un agrégateurs de fonctionnalités. C'était juste un fourre-tout permettant de publier rapidement les choses qui n'avaient pas eu le temps d'être testées assez longtemps, ou pas acceptées pour l'instant, pour être intégrés dans le noyau de SPIP 2.0.
À terme, une bonne partie de ce que propose Bonux est censé revenir dans le core.
À terme, une bonne partie de ce que propose Bonux est censé revenir dans le core.
Certes mais en attendant, ca nous force soit a ne pas installer aucun des plugins de cerdic, soit d'accepter ses choix à lui, qui sont parfois très bons, parfois moins.
Corrolaire, les plugins en question sont moins utilisés, et moins de personnes y participent.
Tout d'abord merci beaucoup pour ce plugin qui m'intéresse énormément à priori et qui pourrait me permettre de supprimer beaucoup de tricks de code mis en place pour faire tourner le site que j'administre (et accessoirement me donner des munitions dans le débat spip-drupal qui anime les services pour lesquels je travaille).
Cependant, des incompatibilités apparaissent avec certains autres plugins que j'utilise et dont je ne peux pas me passer :
- Médiathèque
- SPIP-Lettres de Artego
Le symptôme est le même pour les deux, à savoir le message suivant qui apparaît dès l'activation du plugin :
Warning: Call-time pass-by-reference has been deprecated in C:\Program Files\EasyPHP 3.0\www\ambafrance\plugins\polyhierarchie\public\polyhier_criteres.php on line 61
message répété pour les lignes 65, 111, 114, 118, 210, 214, 218
ils correspondent aux appels aux fonctions "critere_enfants", "critere_parents" et "critere_branche" dans le code de polyhiérarchie.
Est-ce un problème de surcharge multiple et incompatible des mêmes fonctions ? (Médiathèque et SPIP-Lettres cohabitent pourtant très bien)
Y'a-t-il un moyen de le contourner facilement ?
- interface privée à la Bonux
- boucles etendues
- agrégateurs sql
- c'est tout ?
Évidemment !
Et quand on aura dépecé le Bonux, il ne devra plus rien en rester. Même pas son nom, qui fut précisément choisi pour désigner le caractère fourre-tout de pacotille dudit plugin.
