le recours generalise a base/trouver_table entraine une augmentation significative du nombre de requetes sur le calcul des petits squelettes (un squelette avec une boucle articles simple genere plus de 16 requetes hors compilation).
On cache donc les descriptions des tables dans cache/sql_desc.txt
le cache est mis a jour en cas de ?var_mode=recalcul, ou d'appel a trouver_table avec un nom de table vide
on revient dessus avec une solution simple :
le where est toujours ecrit sous la forme "xxx IN (a,b,c)" plus rapide
et le FIELD(xxx,a,b,c) est reserve au defaultorder et ne sera insere que si strictement necessaire
{xxx !IN y,z}
{par ...}{xxx IN y,z}
l'ecriture de type FIELD ... vise a trier implicitement par l'ordre des valeurs listees dans IN x,y,z
mais cela n'a aucune utilite si c'est un !IN ou si un order est deja present
prendre en compte la condition {order ...} ici revient a differencier les requetes produites par
{xx IN ...}{order xxx} et {order xxx}{xxx IN ...}
ce qui peut etre source de confusion.
Il faudrait y revenir avec une solution qui ne depende pas de l'ordre des criteres
* #1539 reste à résoudre;
* la question posée par [12822] de l'ordre hétérogène des arguments dans les balises {{{#FORMULAIRE_EDITER_}}} reste posée;
* un point de doc qui manquait cruellement: ces balises ont un 7e argument qui sera inclus à l'intérieur dans le formulaire produit, et qui peut donc contenir des saisies supplémentaires.
A noter cependant que les limitations syntaxiques des squelettes font que ce 7e argument ne peut contenir des boucles (erreur de syntaxe immédiate) ni une inclusion dynamique (un {{{<INCLURE..>}}}) ici produit un code incohérent) mais une inclusion statique marche. Exemple:
{{{
(#FORMULAIRE_EDITER_ARTICLE{
#ID_ARTICLE,
#ID_RUBRIQUE,
'./?page=art_edit',
0,
langue_article_dynamique,
'',
[<fieldset>
<legend>Choisir un ou plusieurs mots-clés</legend>
(#INCLURE{fond=formulaires/inc-choix_mots}{id_groupe}{unseul})
</fieldset>]})
}}}
Puisque cette fonctionalité n'a visiblement pas été testée, je profite de ce qu'il est encore temps pour l'élargir et de proposer une rationnalisation qui n'est pas sans incompatibilité dans l'usage de ces nouvelles balises (combien d'utilisateurs aujourd'hui?).
Donc, dans les squelettes des formulaires d'édition privée, si le paramètre {{{action}}} est vide, alors les balises ouvrante et fermante {{{form}}} ne sont pas produites, non plus que {{{hidden}}} de l'action et le bouton {{{submit}}}. En pratique, cela veut dire qu'on peut faire ramener à une {{{#FORMULAIRE_*}}} le corps du formulaire sans ces balises {{{form}}} englobante, qu'on complètera facilement dans le squelette appelant. Par exemple, pour compléter le formulaire d'édition d'un article, au lieu d'écrire (comme dans prive/editer/article.hmtl):
{{{
#FORMULAIRE_EDITER_ARTICLE{#ENV{id_article}, #ENV{id_rubrique}, #ENV{redirect},#ENV{lier_trad},#ENV{config_fonc},#ENV{row}}
}
}}}
on écrit
{{{
<form action='#ENV{redirect}'>
[(#ACTION_FORMULAIRE{#ENV{redirect}}]
#FORMULAIRE_EDITER_ARTICLE{#ENV{id_article}, #ENV{id_rubrique}, ' ',#ENV{lier_trad},#ENV{config_fonc},#ENV{row}}
}
mes autres saisies
<input type='submit' />
</form>
}}}
Cela est rendu opérationnel par le présent dépot. Points méritants discussion:
* On a écrit ci-dessus {{{' '}}} et pas la chaîne vide car le bug actuel fait que donner la chaîne vide équivaut à obtenir le formulaire complet, avec {{{self()}}}, et on a préféré ne pas casser la compatibilité. Si on veut pouvoir le faire (ce qui est plus conforme à la compréhension qu'on a du squelette), la conséqence est que si on veut expliciter par exemple {{{lier_trad}}} mais avoir le comportement par défaut pour le retour, il faudra écrire explicitement #SELF (ou NULL).
* Dans cette famille de balises, ce retour est parfois le 3e argument et parfois le 2e, il serait bon d'unifier.
* De même l'argument {{{config_fonctions}}} change de rang souvent, on pourrait unifier ici aussi.
- si la base était inaccesssible le mail prétendant que l'inscription avait été faite partait quand même;
- non transmission du 3e argument optionnel de la balise #FORMULAIRE_INSCRIPTION.
Et petite réogranisation de ce code devenu inutilement compliqué par endroit (mais j'ai pas vu comme supprimer {{{ balise_FORMULAIRE_INSCRIPTION_stat }}}, dommage).
Committo,Ergo:sum
kent1
Eric Lupinacci
tetue
Fil
Stephane
Cerdic
ARNO*
Salvatore
Matthieu Marcillaud