La création d’événement devrait, semble-t-il, être possible sans création d’article attaché. En tout cas c’est ce que laisse supposer la page ?exec=calendrier
Bien sûr le lien en bas plante sous SPIP2.0rc1, mais avant de commiter quelques modifs que j’ai faites, j’aimerais qu’on me confirme que c’est le bon choix (une autre option est de forcer la création d’un nouvel article)
Euh... le calendrier historique de l'espace privé et la gestion d'événement sont deux choses sans rapport
- Ce ticket préconise de retirer le calendrier de SPIP (sans doute vaut-il mieux le proposer en plugin). Euh, d'ailleurs, c'est passé où ? Je ne le retrouve plus dans mon site en SPIP 2.0.0 rc1 [13284] ???
- La gestion d'événements est quand à elle déjà gérée en plugin (le fameux « plugin agenda »).
La création d'événement devrait, semble-t-il, être possible sans création d'article attaché. En tout cas c'est ce que laisse supposer la page ?exec=calendrier
Bien sûr le lien en bas plante sous SPIP2.0rc1, mais avant de commiter quelques modifs que j'ai faites, j'aimerais qu'on me confirme que c'est le bon choix (une autre option est de forcer la création d'un nouvel article)
Non, un evenement doit *toujours* etre rattaché à un article. Sinon il faudrait gérer son statut, ses auteurs etc ..., ce qui n'est pas le choix actuel.
La page ?exec=calendrier doit permettre à terme de crééer directementun événement, mais avec un navigateur d'articles dans la page de saisie, qui permettra de le rattacher à un article existant.
Le 30 nov. 08 à 12:29, cedric.morin@yterium.com a écrit :
Gilles VINCENT a écrit :
Bonjour,
La création d'événement devrait, semble-t-il, être possible sans création d'article attaché. En tout cas c'est ce que laisse supposer la page ?exec=calendrier
Bien sûr le lien en bas plante sous SPIP2.0rc1, mais avant de commiter quelques modifs que j'ai faites, j'aimerais qu'on me confirme que c'est le bon choix (une autre option est de forcer la création d'un nouvel article)
Non, un evenement doit *toujours* etre rattaché à un article. Sinon il faudrait gérer son statut, ses auteurs etc ..., ce qui n'est pas le choix actuel.
La page ?exec=calendrier doit permettre à terme de crééer directementun événement, mais avec un navigateur d'articles dans la page de saisie, qui permettra de le rattacher à un article existant.
Oui, je suis du même avis, même si la version actuelle d'Agenda pour spip 20rc1 permet de créer un événement sans qu'il soit dans un article ... ce qui semble provenir, peut-être du fait qu'à la création dudit événement, il n'y a pas de contrôle de son rattachement à un article. Lorsque j'ai tenté cela, j'ai juste eu une page me signalant qu'il n'y avait pas d'article, mais ensuite plus rien. Un retour en arrière dans mon navigateur me montrait que, pourtant, l'événement avait bien été enregistré, semble-t-il ...
Ne pourrait-on, si on crée un événement sans article, proposer, avant son enregistrement, de choisir dans la liste des articles celui auquel le rattacher ?
En essayant de créer une boucle CONDITION avec spip-bonux, je constate le comportement suivant:
la boucle est la suivante:
<BOUCLE_est_admin(CONDITION){si #SESSION{statut}|=={0minirezo}}>
toto est admin
</BOUCLE_est_admin>
toto n'est pas admin
<//B_est_admin>
si elle est placée dans un fichier de la dist (/squelettes/article.html ou /squelettes/rubrique.html par ex), pas de problème: il est retourné "toto est admin" ou "toto n'est pas admin" selon que le lecteur est loggué admin ou non
En revanche si je passe cette même boucle dans un fichier n'existant pas dans la dist (/squelettes/truc.html par ex) la page spip.php?page=truc renvoie le message d'erreur:
Unknown SQL table "condition"
Le problème est identique avec une condition {si 1} comme utilisé dans le fichier de test du plugin
Du coup je suis super-déçu: j'ai bien trouvé la petite auto dans mon paquet-bonux mais elle n'est pas rouge!!!
Alors est-ce une limite "normale" du système utilisé pour faire tourner la boucle CONDITION ou y'a t'il un bogue par là ?
Si il s'agit d'une limite du système, ça mériterait de l'ajouter en remarque à la doc de contrib...
En essayant de créer une boucle CONDITION avec spip-bonux, je constate le comportement suivant:
la boucle est la suivante:
<BOUCLE_est_admin(CONDITION){si #SESSION{statut}|=={0minirezo}}>
toto est admin
</BOUCLE_est_admin>
toto n'est pas admin
<//B_est_admin>
si elle est placée dans un fichier de la dist (/squelettes/article.html ou /squelettes/rubrique.html par ex), pas de problème: il est retourné "toto est admin" ou "toto n'est pas admin" selon que le lecteur est loggué admin ou non
En revanche si je passe cette même boucle dans un fichier n'existant pas dans la dist (/squelettes/truc.html par ex) la page spip.php?page=truc renvoie le message d'erreur: Unknown SQL table "condition"
ça n'est pas normal. Un &var_mode=recalcul n'arrange rien ?
Le problème est identique avec une condition {si 1} comme utilisé dans le fichier de test du plugin
Du coup je suis super-déçu: j'ai bien trouvé la petite auto dans mon paquet-bonux mais elle n'est pas rouge!!!
Alors est-ce une limite "normale" du système utilisé pour faire tourner la boucle CONDITION ou y'a t'il un bogue par là ?
ben non, il n'y a pas de raison que ca bug comme ça. Ce qui marche dans un squelette devrait marcher dans un autre de la meme façon...
Cédric
Le dimanche 30 novembre 2008 à 12:29 +0100, cedric.morin@yterium.com a
écrit :
Non, un evenement doit *toujours* etre rattaché à un article. Sinon il
faudrait gérer son statut, ses auteurs etc ..., ce qui n'est pas le
choix actuel.
Question (un peu trollesque, je l'avoue) : quelles sont les raisons de
ce choix.
Pour ma part, je m'empêtre régulièrement dans ce double niveau et je me
retrouve la plupart du temps à créer un article pour un événement (par
exemple lorsque j'ai besoin d'un logo pour chaque), ce qui n'est pas
très ergonomique. Je trouve qu'il serait plus simple et plus complet à
la fois de faire des événements des "objets" de SPIP au même titre que
les articles, les brèves ou les sites.
Mais bon, il y a sûrement quelque chose qui m'échappe...
On faisait déjà tous plus ou moins des trucs comme:
[...]
Ouh là, non, pas moi, mais j'ai sans doute déjà fait des trucs encore plus tordus...
Mais là n'est pas la question.
Comment expliquer à un néophite du dev de squelettes qu'une structure nommée "BOUCLE" peut être utilisée dans certains cas pour autre chose qu'une boucle ?
Ce qui était pratique mais pas joli joli, la boucle CONDITION sera au
moins plus propre...
Il aurait peut-être fallu introduire une nouvelle balise bouclante
dans SPIP pour ça... Mais était-ce au moins possible ?
Mais non, pas bouclante, justement !
En tout cas, Spip-Bonux sera incontestablement quelque chose qui me
motivera pour affronter la migration vers Spip 2 !
C'est clair qu'il y a plein de belles choses, je ne le conteste pas !
Comment expliquer à un néophite du dev de squelettes qu'une structure nommée "BOUCLE" peut être utilisée dans certains cas pour autre chose qu'une boucle ?
peut-être en disant que la seule constante de l'univers c'est la variabilité.
Que spip fait partie de l'univers et que donc les exceptions existe aussi pour lui
Plus sérieusement je n'ai pas compris en quoi la boucle sur une condition était différente des autres boucles
Attention, c'est une discussion de puriste, je précise que c'est déjà bien que ce soit possible !
Le 1 déc. 08 à 12:48, Pierre Fiches a écrit :
Le 1 déc. 08 à 12:34, Nicolas Hoizey a écrit :
Comment expliquer à un néophite du dev de squelettes qu'une structure nommée "BOUCLE" peut être utilisée dans certains cas pour autre chose qu'une boucle ?
peut-être en disant que la seule constante de l'univers c'est la variabilité.
Que spip fait partie de l'univers et que donc les exceptions existe aussi pour lui
Plus sérieusement je n'ai pas compris en quoi la boucle sur une condition était différente des autres boucles
Bin en gros, si tu connais PHP, on fait en gros ça :
$ok = false;
while() {
... // cas 1
$ok = true;
}
if (!$ok) {
... // cas 2
}
...là où on devrait faire logiquement ça :
if () {
... // cas 1
} else {
... // cas 2
}
Certes ça marche, et la partie des boucles SPIP permettant de gérer les boucles vides est ici pratique, mais ce n'est pas complètement intuitif.
Alors est-ce une limite "normale" du système utilisé pour faire tourner la boucle CONDITION ou y'a t'il un bogue par là ?
Si il s'agit d'une limite du système, ça mériterait de l'ajouter en remarque à la doc de contrib...
je reproduis pas...
spip [12863]
bonux [24494]
ta boucle (seule) appelée depuis : squelettes/test_boucle.html
Je suis à deux doigts de mettre un "+1".
En tous les cas ca il me semble que ca se discute, peut-être avec Esj le maître de la grammaire SPIP.
Un raccourci plus osé n'est pas possible ?
<CONDITION_est_admin(SI){#SESSION{statut}|=={0minirezo}}>
<CONDITION_est_admin(){si #SESSION{statut}|=={0minirezo}}>
<CONDITION_est_admin{si #SESSION{statut}|=={0minirezo}}>
<SI_est_admin(CONDITION){#SESSION{statut}|=={0minirezo}}>
<SI_est_admin(){#SESSION{statut}|=={0minirezo}}>
<SI_est_admin{#SESSION{statut}|=={0minirezo}}>
<TEST_est_admin(SI){#SESSION{statut}|=={0minirezo}}>
<TEST_est_admin(){#SESSION{statut}|=={0minirezo}}>
<TEST_est_admin{si #SESSION{statut}|=={0minirezo}}>
etc.
Pat
En tant que modeste codeur de squelettes je trouve que la syntaxe
<CONDITION_est_admin(SI){#SESSION{statut}|=={0minirezo}}> serait la plus parlante :
<BOUCLE_est_admin(CONDITION)…> donne l’impression d’une part d’utiliser un objet « condition » qui n’existe pas et d’autre part supposerait l’utilisation de balises qui, à fortiori, n’existent pas.
Je suis à deux doigts de mettre un « +1 ».
En tous les cas ca il me semble que ca se discute, peut-être avec Esj le maître de la grammaire SPIP.
Un raccourci plus osé n’est pas possible ?
<CONDITION_est_admin(SI){#SESSION{statut}|=={0minirezo}}>
<CONDITION_est_admin(){si #SESSION{statut}|=={0minirezo}}>
<CONDITION_est_admin{si #SESSION{statut}|=={0minirezo}}>
<SI_est_admin(CONDITION){#SESSION{statut}|=={0minirezo}}>
<SI_est_admin(){#SESSION{statut}|=={0minirezo}}>
<SI_est_admin{#SESSION{statut}|=={0minirezo}}>
<TEST_est_admin(SI){#SESSION{statut}|=={0minirezo}}>
<TEST_est_admin(){#SESSION{statut}|=={0minirezo}}>
<TEST_est_admin{si #SESSION{statut}|=={0minirezo}}>
etc.
Pat
En tant que modeste codeur de squelettes je trouve que la syntaxe <CONDITION_est_admin(SI){#SESSION{statut}|=={0minirezo}}> serait la plus parlante :
<BOUCLE_est_admin(CONDITION)...> donne l'impression d'une part d'utiliser un objet "condition" qui n'existe pas et d'autre part supposerait l'utilisation de balises qui, à fortiori, n'existent pas.
Salut,
sauf que les expressions régulières qui gérent la syntaxe des boucles est déjà suffisament complexe ( et donc couteuse en terme de perf ) pour ne pas en rajouter. Si on perd un peu en compréhension, on gagne en perf ...
Enfin c'est mon modeste avis.
Je ne connais pas toute la complexité du compilo donc je laisse ceux qui savent donner leur avis ...
