Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

config PHP pour images ?

16 réponses
Avatar
alainL
Bonsoir,

J'ai EasyPHP 1.7 et PHP 4.3.3 avec l'extension gd.
J'ai installé un script qui fonctionne sur le site distant(
http://autourdalos.fr/alcay/index.php ) mais produit des erreurs en
local. Voici la première, je pense que les autres sont la conséquence de
celle-ci... :

______________________________________________________________________________________________

Notice: Undefined variable: start in
e:\easyphp1-7\www\essais\alcay\index.php on line 89

------------------------------------------------------------------------------------------------
<?
function
affichimgs($nblignes,$larimage,$hautimage,$nbcols,$url,$urlancien,$redimvoz,$cadrak,$epaiscadretable,$coulcadretable){
if (isset($_REQUEST['start'])){
$start = $_REQUEST['start'];
}
if(is_null($start)){ ## <----- ligne 89
$start = 0;
}
___________________________________________________________________________________________________

Comment configurer mon EasyPHP ou que modifier dans le script pour
pouvoir bricoler sans avoir recours au site distant ?

Merci

--
Alain L

Mon village en Haute Soule : http://autourdalos.fr
Carnet de voyages: http://jarailet.club.fr/Randobal

6 réponses

1 2
Avatar
BertrandB
Bruno Desthuilliers a écrit :

function lire_get($cle, $defaut=NULL) {
return lire_tableau($_GET, $cle, $defaut);
}



effectivement mais doit on prendre comme nom lire_get ou charger_get ?
ou plus simplement get_get
de même qu'est il recomandé sur les noms de fonctions ?
get_get ou getGet ou ?
Avatar
Rakotomandimby (R12y) Mihamina
Bruno Desthuilliers wrote:
[...] opération des plus courantes en PHP. Il est donc préférable de
factoriser tout ce boilerplate une bonne fois pour toutes



Attention on parle à un "débutant", et il peut ne pas forcément
comprendre ça comme tu le comprendrais.
Il y a des cas _tres_ courants (Les formulaires qui remercient) eux
aussi ou la non initialisation de $_REQUEST est significative (porte une
information).
Genre (rapide, sale et pas testé):

<? if(!isset($_REQUEST)) { ?>
<form>
...
</form>
<? } else { ?>
<p>Merci</p>
<? foo($_REQUEST);} ?>
Avatar
Sylvain SF
Bruno Desthuilliers a écrit :

le serveur distant est mal configuré et permissif,



Non. Il est normal que sur un serveur de prod, les notices
n'apparaissent pas à l'utilisateur. Par contre il est clair
que sur un serveur de dev, au contraire...



entièrement d'accord; mon point était éronné.

Mettre ou enlever les accolades ne change rien au problème



les premiers problèmes semblent être:
- une analyse partielle du cas par le PO - qui traite le cas
où "start" est posté ou transmis (utiliser $_REQUEST est une
source de confusion supplémentaire) et le cas où il n'est pas
transmis,
- le fait de penser (ou de laisser penser) qu'il n'a pas compris
comment une variable est créée (à partir de quand elle existe).

un rappel sur le fonctionnement des variables dans tous les langages
de script aurait été plus complet que mon raccourci, je suis d'accord;
au dela, j'ai menti, certes, mais juste pour inciter à mieux déclarer
les variables.

et il est préférable de les mettre systématiquement, pour éviter
des erreurs lorsqu'on ajoute une autre instruction dans la branche.



hein ? non, si on n'est pas capable de comprendre ce qu'est un bloc
d'instructions, des accolades partout ne soigneront pas cette lacune
au pire cela irait dans le même sens que l'incompréhension initiale
sur la déclaration de la variable.

Quant à définir d'abord une valeur par défaut *puis* a essayer de
récupérer la vraie valeur, c'est une instruction potientiellement
inutile, et ça n'aide pas la lisibilité.



l'argument est trop subjectif pour mériter d'être débattu.

Sauf que tu es passé à côté de ce qui était invalide, à savoir tester
une variable non définie.



c'est ce que j'ai indiqué dans mon premier post, tu as du passer
à coté de cette info, ou ?...

Sylvain.
Avatar
Pascal PONCET
Sylvain SF a écrit :
Bruno Desthuilliers a écrit :
et il est préférable de les mettre systématiquement, pour éviter
des erreurs lorsqu'on ajoute une autre instruction dans la branche.



hein ? non, si on n'est pas capable de comprendre ce qu'est un bloc
d'instructions, des accolades partout ne soigneront pas cette lacune
au pire cela irait dans le même sens que l'incompréhension initiale
sur la déclaration de la variable.



Si, si, d'ailleurs la plupart des éditeurs de code PHP (et autres Java,
Javascript, etc.) les proposent automatiquement après les déclarations
de test, de boucle, de classe et de fonction.
C'est d'ailleurs, à ma connaissance, le seul moyen de gérer un "folding"
(pliage/dépliage) correct à la lecture d'un source, ce qui est quand
même très pratique (et même essentiel pour les classes).
Pas d'accord ?

Slts, Pascal
Avatar
Sylvain SF
Pascal PONCET a écrit :

Si, si, d'ailleurs la plupart des éditeurs de code PHP (et autres Java,
Javascript, etc.) les proposent automatiquement après les déclarations
de test, de boucle, de classe et de fonction.
C'est d'ailleurs, à ma connaissance, le seul moyen de gérer un "folding"
(pliage/dépliage) correct à la lecture d'un source, ce qui est quand
même très pratique (et même essentiel pour les classes).
Pas d'accord ?



"d'accord" sur quel point ?
le fait que le folding soit "essentiel" à l'écriture propre de classes?
et donc que, pendant les dizaines d'années où cela n'existait pas, le
codage était nécessairement non propre et/ou non pratique ?

le folding existe aujourd'hui entre autres sur UEdit 12+, Eclipse,
VS2005+, trois éditeurs que j'utilise et pour lesquel ce folding
ne fonctionne pas correctement, je ne l'utilise donc nul part,
comme je n'ai pas non plus l'habitude de taper des parenthèses
inutiles.

prétendre qu'"il est préférable de les mettre systématiquement"
est juste une ineptie ou une affirmation gratuite; savoir si
d'aucun préfère ou non en mettre systématiquement ne regarde que
lui et son style d'écriture (en supposant que le code n'est ni
élaboré, ni maintenu en équipe), en discuter à dès lors peu
d'intérêt.

Sylvain.
Avatar
Pascal PONCET
Sylvain SF a écrit :
et donc que, pendant les dizaines d'années où cela n'existait pas, le
codage était nécessairement non propre et/ou non pratique ?



Pas propre, je ne sais pas, ça dépend trop de la puissance de l'éditeur
et de la taille des scripts.
Par contre, moins pratique, je le crois sincèrement, mais on ne va pas
se bouffer le nez là-dessus.

le folding existe aujourd'hui entre autres sur UEdit 12+, Eclipse,
VS2005+, trois éditeurs que j'utilise et pour lesquel ce folding
ne fonctionne pas correctement, je ne l'utilise donc nul part,
comme je n'ai pas non plus l'habitude de taper des parenthèses
inutiles.



J'utilise couramment Eclipse, et aussi Notepad++ en appoint.
Les deux gèrent très bien le folding, mais pour Eclipse ça dépend quels
modules sont installés. Après être passé par PHPEclipse, qui le gérait
déjà, j'utilise maintenant Eclipse-PDT qui est suffisamment au point, et
le folding ne pose pas de problème.
Ensuite je ne "tape" pas les accolades, elles se mettent toutes seules,
alors je ne vais pas jusqu'à les enlever par plaisir ou par principe,
quand même.

prétendre qu'"il est préférable de les mettre systématiquement"
est juste une ineptie ou une affirmation gratuite; savoir si
d'aucun préfère ou non en mettre systématiquement ne regarde que
lui et son style d'écriture (en supposant que le code n'est ni
élaboré, ni maintenu en équipe), en discuter à dès lors peu
d'intérêt.



Par contre, le folding est surement sensible au style d'écriture.
Je ne parle pas de qualité, mais seulement de "formats" utilisés.
Par exemple, la place des accolades est déterminante, il vaudra mieux
écrire :
if( ...test... ) {
...code...;
}
que :
if( ...test... )
{
...code...;
}
et, sans accolades, ni :
if( ...test... )
...code...;
pas plus que :
if( ...test... ) ...code...;
ne permettrons un folding correct.

C'est encore plus vrai lorsqu'on utilise un outil de documentation,
comme PHPDocumentor ou Doxygen par exemple, qui fera n'importe quoi si
on ne respecte pas certaines contraintes de formes.

Voilà, ce sont des arguments auxquels on adhère ou pas, mais ils
existent. D'ailleurs Zend encourage ces pratiques.
Mais, personnellement, si je n'ai pas à reprendre le code derrière, je
me tape aussi complètement de savoir comment fait untel ou tel autre
avec ses blocs ! ;-)

Cordialement,
Pascal
1 2