🌍
Français
Au final j'ai fait différemment : faisant une actions +/- similaire à tous mes éléments du formulaire (un 'set' dans un objet), j'ai créé un tableau contenant tous les éléments et je boucle en faisant un "isset" sur le $_POST correspondant.
C'est sûrement plus coûteux que le @ mais ça respecte le code. De toutes façons la performance pour un formulaire d'admin de plugin n'est pas primordiale.
Merci en tout cas.
Quant on sait pourquoi on utilise @, alors même si ce n'est pas nickel...
Cela est mieux qu'une erreur.
Je ne blague pas... je reconnais que ce n'est pas super clean... mais je ne vois vraiment pas le soucis pour un plugin perso...
Dans phpwebgallery, je vois par exemple:
@include(PHPWG_ROOT_PATH. 'include/config_local.inc.php');
Il serait peut-etre plus propre de faire:
if (file_exists(PHPWG_ROOT_PATH. 'include/config_local.inc.php'))
{
include(PHPWG_ROOT_PATH. 'include/config_local.inc.php');
}
Mais c'est quand meme franchement plus pratique d'utiliser l'arobase...
P@t a écrit:
nicolas a écrit:
Ahhhhhhhhhhhhhh mes yeux. Tu caches la misère mais ce n'est pas une bonne idée du tout.
N'exagerons rien quand meme! Pour un plugin perso, le @ est parfait ;-)
Tu blagues ? Rassure moi.
Je ne sais même pas pourquoi cette horreur existe. Il n'y a qu'une seule utilisation acceptable car on ne peut pas faire autrement : on peut utiliser l'arobase pour toutes les ouvertures de flux (fichier, socket,...) mais à l'unique condition de traiter les cas d'erreurs derrière. Sinon c'est juste dégueulasse et ce n'est pas moins coûteux que de faire un test.
nicolas a écrit:
Ahhhhhhhhhhhhhh mes yeux. Tu caches la misère mais ce n'est pas une bonne idée du tout.
N'exagerons rien quand meme! Pour un plugin perso, le @ est parfait ;-)
nicolas a écrit:
Je pense que tu voulais dire !empty. Mais quoi qu'il en soit c'est strictement équivalent dans le cas qui nous intéresse.
Oui oui, !empty.... mais c'est aussi ce qu'il me semble, ca revient exactement au meme ici...
P@t a écrit:
Criss a écrit:
Dans ce cas, tu n'as qu'à faire:
$valeur = @$_POST['my_box'];
Ahhhhhhhhhhhhhh mes yeux. Tu caches la misère mais ce n'est pas une bonne idée du tout.
P@t a écrit:
Au lieu de faire un if (empty($_POST['my_box'])) pour tester la variable, il suffit de faire un if (isset($_POST['my_box']))
Je pense que tu voulais dire !empty. Mais quoi qu'il en soit c'est strictement équivalent dans le cas qui nous intéresse.
Criss a écrit:
Actuellement c'est bien pire : je fais :
Code:
$valeur = $_POST['my_box'];(je sais c'est pas beau, mais flemme oblige lors du développement initial, et comme ça marchait...)
Ce même code génère chez moi ladite notice en 2.0...
Dans ce cas, tu n'as qu'à faire:
$valeur = @$_POST['my_box'];
VDigital a écrit:
assign() au lieu de assign_vars()
mais également l'assign_block_vars n'existe plus...
Smarty - Chapitre 4. Variables
Mais également nos fonctions comme personal_remove_tpl_code() qui se basaient sur $template->uncompiled_code ou des $template->_tpldata, cela ne marcheront plus.
Donc pour:
Gommer les récentes
et pour:
Faire son plugin personnel
Nous ferons autrement...
Ok merci je le note, d'autant qu'il me semble utiliser ces dernières fonctions...
VDigital a écrit:
Tout ceci sera à expliquer dès la sortie de Piwigo 2.0.0 (je dis bien Piwigo et pas PiWiGo - merci).
Ok j'le r'ferai plus. :o
P@t a écrit:
Au lieu de faire un if (empty($_POST['my_box'])) pour tester la variable, il suffit de faire un if (isset($_POST['my_box']))
Ce n'est pas plus compliqué que ca.... mais je ne vois pas pourquoi le comportement de ca serait différent entre la 1.7 et la 2.0...
Actuellement c'est bien pire : je fais :
$valeur = $_POST['my_box'];
(je sais c'est pas beau, mais flemme oblige lors du développement initial, et comme ça marchait...)
Ce même code génère chez moi ladite notice en 2.0...
Criss a écrit:
Première question : les principes (généraux) de codages des plugins ne vont pas changer, je veux parler par là des fonctions communément appelées (assign à la place de assign_var par exemple) ?
assign() au lieu de assign_vars()
mais également l'assign_block_vars n'existe plus...
Smarty - Chapitre 4. Variables
Mais également nos fonctions comme personal_remove_tpl_code() qui se basaient sur $template->uncompiled_code ou des $template->_tpldata, cela ne marcheront plus.
Donc pour:
Gommer les récentes
et pour:
Faire son plugin personnel
Nous ferons autrement...
Tout ceci sera à expliquer dès la sortie de Piwigo 2.0.0 (je dis bien Piwigo et pas PiWiGo - merci).
Au lieu de faire un if (empty($_POST['my_box'])) pour tester la variable, il suffit de faire un if (isset($_POST['my_box']))
Ce n'est pas plus compliqué que ca.... mais je ne vois pas pourquoi le comportement de ca serait différent entre la 1.7 et la 2.0...
Hello,
J'ai décidé de commencer la migration de mon plug-in perso vers PiWiGo ce qui me permet de voir ce qui m'attend par la suite.
Première question : les principes (généraux) de codages des plugins ne vont pas changer, je veux parler par là des fonctions communément appelées (assign à la place de assign_var par exemple) ?
J'ai cru voir une différence de traitement des formulaires des pages admin (au moins). Dans ma page j'ai un certain nombre de checkboxes. En 1.7 si elles ne sont pas cochées la variable $_POST['my_box'] est "disponible" (mais vide je dirais). Là j'ai une notice qui apparaît : "Undefined index: my_box"
Donc dois-je faire un isset() à chaque élément ou existe-t-il une option à rajouter ?
Criss