Committo,Ergo:sum a écrit :
j'ai poussé le concept un poil plus loin, pour pouvoir aussi choisir le module ou la chaine dynamiquement.
en gros le but, c'est de pouvoir faire par exemple:
<:#ENV{module_lang}:#GET{message,message_defaut}:>
au lieu de #ENV{module_lang}|concate{:,#GET{message,message_defaut}}|_T
et pouvoir du coup passer simplement des arguments.
j'ai fait ca en passant une couche de phraser_champs (dans phraser_html.php) / calculer_liste (dans compiler.php) sur le nom du module et de la chaine.
au niveau regexp, j'ai fait betement :
<:(([a-z0-9_]+|#[A-Z0-9_]+{?[^}]*}?):)?([a-z0-9_]+|#[A-Z0-9_]+{?[^}]*}?)({([^\|=>]*=[^\|>]*)})?((\|[^>]*)?:>)
c'est assez limité et sans doute moins robuste, mais ca marche pour les balises simples sans trop perturber l'existant
ca vous interesse ?
Phraser_champs est capable de repérer des champs imbriqués (comme #ENV{x,#ENV{z}} par exemple) or, comme tu le signales, ta Regexp na va laisser passer que des champs simples. Je trouve ennuyeux de faire croire que <:#ENV{x,#ENV{z}}:> serait disponible alors que ça ne l'est pas.
ben ce qui est surtout embetant, c'est que c'est juste un probleme de regexp, moi je suis incapable de faire mieux.
bon, d'un autre coté, c'est pas bloquant dans la mesure ou on peut toujours faire un #SET avant et utiliser le #GET, ca merite juste d'etre documenté.
Vu que ça n'apporte qu'un peu de concision (le concate dans ton exemple ci-dessus) ça ne me parait pas fondamental.
oui, c'est surtout ca la question, est-ce utile ???
perso je n'en ai pas l'utilité, j'ai un choix dynamique du module mais je passe par un filtre car c'est un peu specifique (recherche dans le module puis dans le local renvoyant vide ou une valeur par defaut passée au filtre)
je me disais par contre qu'un truc du genre :
#SET{module,local#ID_SECTEUR}
<:#GET{module}:chaine{titre=#TITRE}:> pouvait avoir une utilité pour faire l'équivalent d'un local_fr par secteur
ou des trucs du genre : <:#GET{erreur}{contexte=#ENV{contexte}}:> pour afficher les erreurs dans des squelettes (pour la gestion d'accès restreint par exemple)
Le seul avantage par rapport à l'ecriture filtre, c'est d'eviter de se construire un tableau des arguments.
Mais c'est peut etre plus vite fait de fournir un filtre du genre (pas testé) :
function T(){
$numargs = func_num_args();
$arg_list = func_get_args();
$args=array();
for ($i = 1; $i < $numargs; $i++) {
$arg=explode('=',$arg_list[$i]);
if ($arg[0]) $args[$arg[0]]=$arg[1];
}
return _T($arg_list[0],$args);
}
ce qui permettrait d'ecrire :
#GET{module}|concate{:chaine}|T{titre=#TITRE}
et
#GET{erreur}|T{contexte=#ENV{contexte},argument=valeur}
non ?
En revanche, je serais assez partisan de mettre là où tu en arrivé hier dans la beta, parce ce que ça rationalise l'existant: il n'était pas normal de ne pas pouvoir fournit le 2e argument de _T().
je pense aussi que ca ne devrait pas poser de problemes, mais c'est toi qui connait le mieux cette partie du code, moi j'ai juste survolé ca et copié/modifié un peu betement (ce que je fais assez bien en general, mais pas trop sur les regexp auquelles je ne comprend pas grand chose).
Il n'y a à priori pas de risque de regression, la regexp etant plus selective, et je ne vois pas ce qui pourrait ouvrir une faille de securité, mais bon, c'est vrai que c'est pas forcement le bon moment pour faire des modifs dans le compilo, et visiblement la fonctionnalité n'est pas très attendue...
@++