[LONG] Syntaxe HEREDOC et inclusion de javascript, je nage...
35 réponses
Eric Demeester
Bonjour,
Dans le but d'externaliser le code javascript inclus dans un script php
dont je ne suis pas l'auteur [*], j'essaye de comprendre comment il a
été construit, et ça commence à me faire mal à la tête...
Voici une fonction mélangeant php et javascript, il y en a plusieurs
comme ça dans le script en question.
Ce que fait la fonction a peu d'importance, ni le nom des variables, ce
qui m'intéresse, c'est la logique (?) de l'imbrication PHP/javascript et
comment réécrire ça proprement...
Mes commentaires concernant ce que je crois comprendre sont entre
crochets.
......................................................................
function rotator_fade_orig( $mod, $fileList, $_params, $speed,
$speed_fade, $number, $url, $url_class, $url_target )
{
$stamp1 = <<<EOT
<script type="text/javascript" language="javascript">
<!--
var j{$mod}=0;
var rotImg{$mod}=new Array();
if (document.images){
EOT;
[ j'en déduis que $stamp1 contient la chaîne littérale contenue entre
<<<EOT et EOT;, et que la valeur de la variable $mod passée en
paramètre à la fonction est affectée à deux variables du javascript,
et ci-dessous on revient au PHP, j'ai bon jusque là ? ]
[ Le foreach ci-dessus et le $_out, c'est bien du PHP qui continue à
construire la chaîne $stamp1, mais on est toujours dans le javascript,
puisqu'on a pas encore rencontré de </script>. Donc le bidule est en
train de construire dynamiquement du javascript à la volée, j'ai
toujours bon ? Ci-dessous, on repasse en syntaxe HEREDOC : ]
$stamp2 = <<<EOT
}
function rotator$mod() {
if (document.all){
document.images.rot_img{$mod}.style.filter="blendTrans(duration={$speed_fade})";
document.images.rot_img{$mod}.filters.blendTrans.Apply();
}
document.images.rot_img{$mod}.src=rotImg{$mod}[j{$mod}].src;
if (document.all)
document.images.rot_img{$mod}.filters.blendTrans.Play();
if (j{$mod}<({$number}-1))
j{$mod}=j{$mod}+1;
else
j{$mod}=0;
[ On s'intéresse maintenant à la chaîne littérale $stamp2, qui comme
$stamp1 est en fait du javascript assaisonné de variables passées par
le PHP. Puis vient la fin du script. {$_out} entre accolades juste
avant la réouverture d'un script appelant la fonction rotator, je ne
comprends pas sa syntaxe... ]
return $stamp1.$stamp2;
}
[ ici, fin de la fonction PHP, qui renvoie la concaténation des deux
chaînes à la fonction appelante, laquelle insérera le javascript
dans la page appelante ($_out je suppose) ]
......................................................................
En résumé, si j'ai compris la philosophie de la chose, je pourrais
résoudre mon problème de séparation des genres en écrivant le javascript
dans un fichier texte puis appeler ce fichier dans les en-têtes de la
page, plutôt que d'insérer directement le javascript dans le corps de la
page html générée ?
Tout ça parce qu'un spécialiste du référencement (sic) n'aime pas le
javascript dans les pages « parce que ça perturbe les robots » :(
Si vous avez des idées, des commentaires, des suggestions, cela me sera
d'un grand secours.
Merci aux personnes qui auront eu la patience de me lire.
[*] Il s'agit de function.image_rotator.php, qui est un plugin de
cms made simple :
http://dev.cmsmadesimple.org/project/files/172#package-220
C'est ce qui fait défiler les portraits en haut à droite sur :
http://www.opusinfide.com/
Les habitudes à prendre sont bonnes. C'est comme utiliser SASS(1) ou LESS(2) : on se dit, vieux con, que tout ça c'est tendance mais ça ne sert à rien. Or, ça apporte un gain de productivité réelle ET une maintenance grandement facilitée.
Ha je ne connaissais pas ces 2 framework, merci des liens !
Pour ce qui est du changement des habitudes de développement, je ne sais pas trop où en est la situation actuelle. Vers 2001-2002-2003 beaucoup de gens dans l'industrie (intégrateurs, mais même développeurs et parfois graphistes) sont passés des "vieilles recettes" à séparation fond/forme avec du html autant valide que possible et du css. Je crois que tous ceux là ont déjà connu une transformation en profondeur de leur environnement professionnel, et pour des avantages très concrets et quais immédiats !
Mais depuis cette époque on peut imaginer que pas mal de "nouveaux entrants" sont arrivés sur le marché et n'ont pas cet historique en tête ? A l'inverse les arguments pas très pertinents ("plus propre") pour basculer aux standards utilisés au début des années 2000 me paraissent beaucoup moins répandus, j'ai l'impression que l'on parle plus de gains concrets pour la production, les performances et l'évolutivité ? Faut voir...
En tout cas je fais partie de ceux qui ont été longtemps sceptiques, ont fini par être convaincus, et il est clair que même sans considérer les problématiques de compatibilité CSS des navigateurs il y a encore beaucoup à faire sur de nombreux domaines ! Les performances étant un point vraiment critique, vu que les applications deviennent de plus en plus complexe et que les développeurs s'éloignent de plus en plus des réalités avec des tonnes de couches d'abstractions (frameworks serveur, api JavaScript, moteurs de template et cache, ...).
Tu parlais de E.Daspet
Oui, son blog était exceptionnel, j'y retourne régulièrement. C'est bien dommage qu'il ait arrêté de poster, c'était une source d'information quasi idéale !
On 08/03/2011 11:38, Olivier Masson wrote:
Les habitudes à prendre sont bonnes. C'est comme utiliser SASS(1) ou
LESS(2) : on se dit, vieux con, que tout ça c'est tendance mais ça ne
sert à rien. Or, ça apporte un gain de productivité réelle ET une
maintenance grandement facilitée.
Ha je ne connaissais pas ces 2 framework, merci des liens !
Pour ce qui est du changement des habitudes de développement, je ne sais
pas trop où en est la situation actuelle. Vers 2001-2002-2003 beaucoup
de gens dans l'industrie (intégrateurs, mais même développeurs et
parfois graphistes) sont passés des "vieilles recettes" à séparation
fond/forme avec du html autant valide que possible et du css. Je crois
que tous ceux là ont déjà connu une transformation en profondeur de leur
environnement professionnel, et pour des avantages très concrets et
quais immédiats !
Mais depuis cette époque on peut imaginer que pas mal de "nouveaux
entrants" sont arrivés sur le marché et n'ont pas cet historique en tête ?
A l'inverse les arguments pas très pertinents ("plus propre") pour
basculer aux standards utilisés au début des années 2000 me paraissent
beaucoup moins répandus, j'ai l'impression que l'on parle plus de gains
concrets pour la production, les performances et l'évolutivité ?
Faut voir...
En tout cas je fais partie de ceux qui ont été longtemps sceptiques, ont
fini par être convaincus, et il est clair que même sans considérer les
problématiques de compatibilité CSS des navigateurs il y a encore
beaucoup à faire sur de nombreux domaines ! Les performances étant un
point vraiment critique, vu que les applications deviennent de plus en
plus complexe et que les développeurs s'éloignent de plus en plus des
réalités avec des tonnes de couches d'abstractions (frameworks serveur,
api JavaScript, moteurs de template et cache, ...).
Tu parlais de E.Daspet
Oui, son blog était exceptionnel, j'y retourne régulièrement. C'est bien
dommage qu'il ait arrêté de poster, c'était une source d'information
quasi idéale !
Les habitudes à prendre sont bonnes. C'est comme utiliser SASS(1) ou LESS(2) : on se dit, vieux con, que tout ça c'est tendance mais ça ne sert à rien. Or, ça apporte un gain de productivité réelle ET une maintenance grandement facilitée.
Ha je ne connaissais pas ces 2 framework, merci des liens !
Pour ce qui est du changement des habitudes de développement, je ne sais pas trop où en est la situation actuelle. Vers 2001-2002-2003 beaucoup de gens dans l'industrie (intégrateurs, mais même développeurs et parfois graphistes) sont passés des "vieilles recettes" à séparation fond/forme avec du html autant valide que possible et du css. Je crois que tous ceux là ont déjà connu une transformation en profondeur de leur environnement professionnel, et pour des avantages très concrets et quais immédiats !
Mais depuis cette époque on peut imaginer que pas mal de "nouveaux entrants" sont arrivés sur le marché et n'ont pas cet historique en tête ? A l'inverse les arguments pas très pertinents ("plus propre") pour basculer aux standards utilisés au début des années 2000 me paraissent beaucoup moins répandus, j'ai l'impression que l'on parle plus de gains concrets pour la production, les performances et l'évolutivité ? Faut voir...
En tout cas je fais partie de ceux qui ont été longtemps sceptiques, ont fini par être convaincus, et il est clair que même sans considérer les problématiques de compatibilité CSS des navigateurs il y a encore beaucoup à faire sur de nombreux domaines ! Les performances étant un point vraiment critique, vu que les applications deviennent de plus en plus complexe et que les développeurs s'éloignent de plus en plus des réalités avec des tonnes de couches d'abstractions (frameworks serveur, api JavaScript, moteurs de template et cache, ...).
Tu parlais de E.Daspet
Oui, son blog était exceptionnel, j'y retourne régulièrement. C'est bien dommage qu'il ait arrêté de poster, c'était une source d'information quasi idéale !
Pierre Goiffon
On 08/03/2011 11:23, Olivier Masson wrote:
Daspet est un chouette gars, qui fait son boulot à fond et très bien. Mais un peu trop parfois.
A voir surtout : http://www.websiteoptimization.com/
Je m'abonne au rss, merci !
On 08/03/2011 11:23, Olivier Masson wrote:
Daspet est un chouette gars, qui fait son boulot à fond et très bien.
Mais un peu trop parfois.
A voir surtout : http://www.websiteoptimization.com/
Daspet est un chouette gars, qui fait son boulot à fond et très bien. Mais un peu trop parfois.
A voir surtout : http://www.websiteoptimization.com/
Je m'abonne au rss, merci !
Olivier Masson
Le 08/03/2011 15:20, Pierre Goiffon a écrit :
Ca peut servir pour des applications en ligne, typiquement des générations de graphiques qui évoluent en ajax. Par exemple OpenFlash Chart permet d'exporter les graphiques en générant dynamiquement un img srcÚta:.
Flash peut pas générer d'image directement ?
Le 08/03/2011 15:20, Pierre Goiffon a écrit :
Ca peut servir pour des applications en ligne, typiquement des
générations de graphiques qui évoluent en ajax. Par exemple OpenFlash
Chart permet d'exporter les graphiques en générant dynamiquement un img
srcÚta:.
Ca peut servir pour des applications en ligne, typiquement des générations de graphiques qui évoluent en ajax. Par exemple OpenFlash Chart permet d'exporter les graphiques en générant dynamiquement un img srcÚta:.
Flash peut pas générer d'image directement ?
Olivier Masson
Le 08/03/2011 15:30, Pierre Goiffon a écrit :
En tout cas je fais partie de ceux qui ont été longtemps sceptiques, ont fini par être convaincus, et il est clair que même sans considérer les problématiques de compatibilité CSS des navigateurs il y a encore beaucoup à faire sur de nombreux domaines ! Les performances étant un point vraiment critique, vu que les applications deviennent de plus en plus complexe et que les développeurs s'éloignent de plus en plus des réalités avec des tonnes de couches d'abstractions (frameworks serveur, api JavaScript, moteurs de template et cache, ...).
Ben maintenant, la grosse mode c'est d'être Agile. T'es pas scrummaster, t'es nase :)
Tu parlais de E.Daspet
Oui, son blog était exceptionnel, j'y retourne régulièrement. C'est bien dommage qu'il ait arrêté de poster, c'était une source d'information quasi idéale !
Il publie toujours, mais plus sur son blog. De temps en temps directement sur Google Docs. Sinon twitter @edasfr pour les infos.
Le 08/03/2011 15:30, Pierre Goiffon a écrit :
En tout cas je fais partie de ceux qui ont été longtemps sceptiques, ont
fini par être convaincus, et il est clair que même sans considérer les
problématiques de compatibilité CSS des navigateurs il y a encore
beaucoup à faire sur de nombreux domaines ! Les performances étant un
point vraiment critique, vu que les applications deviennent de plus en
plus complexe et que les développeurs s'éloignent de plus en plus des
réalités avec des tonnes de couches d'abstractions (frameworks serveur,
api JavaScript, moteurs de template et cache, ...).
Ben maintenant, la grosse mode c'est d'être Agile. T'es pas scrummaster,
t'es nase :)
Tu parlais de E.Daspet
Oui, son blog était exceptionnel, j'y retourne régulièrement. C'est bien
dommage qu'il ait arrêté de poster, c'était une source d'information
quasi idéale !
Il publie toujours, mais plus sur son blog. De temps en temps
directement sur Google Docs. Sinon twitter @edasfr pour les infos.
En tout cas je fais partie de ceux qui ont été longtemps sceptiques, ont fini par être convaincus, et il est clair que même sans considérer les problématiques de compatibilité CSS des navigateurs il y a encore beaucoup à faire sur de nombreux domaines ! Les performances étant un point vraiment critique, vu que les applications deviennent de plus en plus complexe et que les développeurs s'éloignent de plus en plus des réalités avec des tonnes de couches d'abstractions (frameworks serveur, api JavaScript, moteurs de template et cache, ...).
Ben maintenant, la grosse mode c'est d'être Agile. T'es pas scrummaster, t'es nase :)
Tu parlais de E.Daspet
Oui, son blog était exceptionnel, j'y retourne régulièrement. C'est bien dommage qu'il ait arrêté de poster, c'était une source d'information quasi idéale !
Il publie toujours, mais plus sur son blog. De temps en temps directement sur Google Docs. Sinon twitter @edasfr pour les infos.
Pierre Goiffon
On 08/03/2011 15:44, Olivier Masson wrote:
Ca peut servir pour des applications en ligne, typiquement des générations de graphiques qui évoluent en ajax. Par exemple OpenFlash Chart permet d'exporter les graphiques en générant dynamiquement un img srcÚta:.
Flash peut pas générer d'image directement ?
Les choses ne sont jamais complètement simples :) Le cas le plus courant est l'impression, mais on peut également imaginer bien plus.
On 08/03/2011 15:44, Olivier Masson wrote:
Ca peut servir pour des applications en ligne, typiquement des
générations de graphiques qui évoluent en ajax. Par exemple OpenFlash
Chart permet d'exporter les graphiques en générant dynamiquement un img
srcÚta:.
Flash peut pas générer d'image directement ?
Les choses ne sont jamais complètement simples :) Le cas le plus courant
est l'impression, mais on peut également imaginer bien plus.
Ca peut servir pour des applications en ligne, typiquement des générations de graphiques qui évoluent en ajax. Par exemple OpenFlash Chart permet d'exporter les graphiques en générant dynamiquement un img srcÚta:.
Flash peut pas générer d'image directement ?
Les choses ne sont jamais complètement simples :) Le cas le plus courant est l'impression, mais on peut également imaginer bien plus.