Piwigo.org

Criss · 2009-02-02 11:13:56

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

P@t · 2009-02-02 12:30:26

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...

VDigital · 2009-02-02 13:41:02

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).

Criss · 2009-02-02 14:32:39

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 :

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...

Criss · 2009-02-02 14:35:28

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 · 2009-02-02 15:22:28

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'];

Dernière modification par P@t (2009-02-02 15:22:54)

nicolas · 2009-02-02 15:55:39

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.

P@t · 2009-02-02 16:04:56

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...

nicolas · 2009-02-02 16:35:04

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.

P@t · 2009-02-03 10:56:47

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...

VDigital · 2009-02-03 12:27:42

Quant on sait pourquoi on utilise @, alors même si ce n'est pas nickel...
Cela est mieux qu'une erreur.

Criss · 2009-02-03 15:24:35

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.

Piwigo.org

Annonce

#1 2009-02-02 11:13:56

migration plugin perso 1.7.x --> 2.0

#2 2009-02-02 12:30:26

Re: migration plugin perso 1.7.x --> 2.0

#3 2009-02-02 13:41:02

Re: migration plugin perso 1.7.x --> 2.0

Criss a écrit:

#4 2009-02-02 14:32:39

Re: migration plugin perso 1.7.x --> 2.0

P@t a écrit:

Code:

#5 2009-02-02 14:35:28

Re: migration plugin perso 1.7.x --> 2.0

VDigital a écrit:

VDigital a écrit:

#6 2009-02-02 15:22:28

Re: migration plugin perso 1.7.x --> 2.0

Criss a écrit:

Code:

#7 2009-02-02 15:55:39

Re: migration plugin perso 1.7.x --> 2.0

P@t a écrit:

Criss a écrit:

P@t a écrit:

#8 2009-02-02 16:04:56

Re: migration plugin perso 1.7.x --> 2.0

nicolas a écrit:

nicolas a écrit:

#9 2009-02-02 16:35:04

Re: migration plugin perso 1.7.x --> 2.0

P@t a écrit:

nicolas a écrit:

#10 2009-02-03 10:56:47

Re: migration plugin perso 1.7.x --> 2.0

#11 2009-02-03 12:27:42

Re: migration plugin perso 1.7.x --> 2.0

#12 2009-02-03 15:24:35

Re: migration plugin perso 1.7.x --> 2.0

Pied de page des forums