overlib

ASM a présenté l'énoncé suivant :

Et on essaie de faire croire que le php c'est *facile* ?

Les guillemets simples n'interprètent pas les variables.
Les guillemets doubles interprètent les variables.

Ben voilà, comme ça je le sais (si toutefois je n'oublie pas).

Si tu juges ça comme une difficulté, j'espère que tu ne considères ton
activité de programmation que comme du bricolage.

Oui, bien sûr. Pourquoi poses-tu cette question ?

C'est un savoir, et non un savoir-faire, donc par définition ça ne
présente aucune difficulté.

Ben si : savoir.

Il faut seulement passer par la phase normale d'apprentissage avant de
prétendre développer dans un langage, et ne pas mettre sur le compte
d'un langage ce qui vient d'une impasse personnelle.

Hu ... de là à passer aux grands poncifs ...

Enfin sinon à part ça, t'as une expérience très intéressante en JavaScript.

Peut-être.

--
ASM

Bonjour,

Si ça marche (sauf la dernière version).
le pb que j'avais c'était l'affichage qui groupait tous les liens-photos en
tête de page...
c'est 'presque' réglé...mais c'est un pb php.
Merci

GB


"ASM" <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> a écrit dans le message
de news: 4538cd26$0$27388$ba4acef3@news.orange.fr...

Merci
Ca marche en faisant ça :
$t1 ='<a href="javascript:void(0)" onMouseOver="';
$t1 .="return overlib('<img src=". $photo .">'";
$t1 .=',RELX, -160, RELY, -125)" onMouseOut="return nd();">';
$t1 .= "$nom</b></a>";

malheureusement ça ne marche pas dans une fonction....

comment ça : ça ne marche pas dans une fonction ?

d'une part je t'ai donné ma proposition de fonction corrigée
(testée : c'est OK)

d'autre part ceci devrait aussi fonctionner :

function newLien($photo, $nom) {
$t1 ='<a href="javascript:void(0)" onMouseOver="';
$t1 .="return overlib('<img src=". $photo .">'";
$t1 .=',RELX, -160, RELY, -125)" onMouseOut="return nd();">';
$t1 .= "$nom</b></a>";
echo $t1;
}

ou même ceci :

function newLien($image, $lien) {
print("<a href="javascript:void(0)"
onMouseOver="return overlib('<img src="$image">',
RELX, -160, RELY, -125);"
onMouseOut="return nd();">$lien</b></a>");
}


--
ASM

Bonjour,

Si ça marche (sauf la dernière version).

Ha bon ?
J'ai donc pas vraiment compris les histoires de ' et " en php ?
avec :

function newLien($image, $lien) {
print("<a href="javascript:void(0)"
onMouseOver="return overlib('<img src="$image">',
RELX, -160, RELY, -125);"
onMouseOut="return nd();">$lien</b></a>");
}

le pb que j'avais c'était l'affichage qui groupait tous les liens-photos en
tête de page...

Tu dois avoir fait une boucle à cet endroit sans doute ?

c'est 'presque' réglé...mais c'est un pb php.

à moins qu'il ne faille régler -160 et -125 pour chaque vue
individuellement ?
Ou bien qu'il ne faille mettre chaque image dans un conteneur ?

--
ASM

Les guillemets simples n'interprètent pas les variables.
Les guillemets doubles interprètent les variables.

Ben voilà, comme ça je le sais (si toutefois je n'oublie pas).

Il suffit de lire la doc. Elle est constamment en ligne, et qui plus est
en français (parmi quelques dizaines d'autres langues).

http://www.php.net/manual/fr/
http://www.php.net/manual/fr/language.types.php
http://www.php.net/manual/fr/language.types.string.php

Je ne comprends pas, alors que tu connais des tas de choses très
pointues sur HTML, CSS et JavaScript, voire sur les différences de
traitement qu'en font IE Win, IE Mac et NS4 pour ne citer qu'eux,
que tu dénigres tant un langage de programmation sous prétexte que
tu n'as pas envie de l'apprendre.

Si tu ne veux pas faire de PHP, n'en fais pas ! Mais cesse de lancer des
rumeurs contre un langage que tu ne veux pas connaître : tes compétences
en JavaScript pourraient faire croire à des novices que tu t'y connais
aussi en PHP et que tu parles en connaissance de cause alors que c'est faux.

Il faut seulement passer par la phase normale d'apprentissage avant de
prétendre développer dans un langage, et ne pas mettre sur le compte
d'un langage ce qui vient d'une impasse personnelle.

Hu ... de là à passer aux grands poncifs ...

Je suis d'accord avec Stéphane, même si « impasse personnelle » pouvait
être pris négativement (manque d'intelligence, toussa) alors qu'à mon
avis il s'agit juste d'un désintérêt de ta part, sans aucun rapport avec
ton niveau d'intelligence donc.

Tu n'es pas bête du tout (à preuve ce que tu arrives à faire en HTML et
JavaScript), simplement tu n'as pas envie de te mettre au PHP. Tu fais
comme tu veux, mais n'en dégoûte pas les autres !

Ha ? tien ?
Y avait longtemps...

Les guillemets simples n'interprètent pas les variables.
Les guillemets doubles interprètent les variables.
Ben voilà, comme ça je le sais (si toutefois je n'oublie pas).

En toute honneteté, Thibaut m'avait ici, me semble t-il ré-expliqué
cette astuce il y a qques mois.
Mais ... bon ... il arrive qu'on zappe :-(

Il suffit de lire la doc. Elle est constamment en ligne, et qui plus est
en français (parmi quelques dizaines d'autres langues).

http://www.php.net/manual/fr/

j'ai cette réf en bookmark
c'est innexploitable pour le basique de chez basique, le neuneu,
à preuve : mon incompréhension (ou Ha? j'avions point vu)
de cette particularité ' "
Il faut quand imaginer qu'il puisse il y avoir une différence, pour la
chercher.

http://www.php.net/manual/fr/language.types.php
http://www.php.net/manual/fr/language.types.string.php

Déjà faut arriver là.

Et c'est gai ! j'apprends que le php cause pas l'utf-8
(faut lui demander de se le traduire ...)

Bon c'est marqué là (en petit et même pas en rouge ni avec qque signe
d'importance) :
(cite)
Note : Contrairement aux autres syntaxes, les variables présentes dans
la chaîne ne seront PAS remplacées par leurs valeurs.
(/cite)

et ... pourtant : *Contrairement aux autres syntaxes*
aurait bien mérité d'être souligné.

Faut vraiment lire très attentivement pour comprendre que des variables
pourraient être remplacées par leurs valeurs dans une chaîne.

Je ne comprends pas,

Je ne commente pas.

Si tu ne veux pas faire de PHP, n'en fais pas !

C'est seulement que je ne pratique pas suffisamment.
(on se demande bien pourquoi ?)

Pour être honnête 'types.string.php' je crois bien que je l'ai déjà vue.

Mais cesse de

Ce n'est pas gagné.

Tu n'es pas bête du tout

Ça ne m'interesse pas non plus,
de tte façon on est touj le con d'un autre

simplement tu n'as pas envie de te mettre au PHP.

Disons que cette profusion de $ dans le code me met mal à l'aise ?

Tu fais
comme tu veux, mais n'en dégoûte pas les autres !

Le JS est souvent utilisé n'importe comment mais à part des
disfonctionnements ça ne porte pas à d'autres conséquences.
Pour le php il n'en va pas de même : les bons fonctionnements apparents
peuvent conduire à de graves conséquences.

Alors, oui, quand je vois du html pourri je gueule à l'arnaque quant au
php qui pourrait l'avoir pondu, et par voie de conséquence je doute des
compétences du gus qui manipule ce php et suis prêt à tout pour l'en
dégouter.

--
ASM

Bonjour,

Disons que cette profusion de $ dans le code me met mal à l'aise ?

On aime ou on aime pas certes, ça permet néanmoins de distinguer les

symbole de variable facilement. C'est un détail cosmétique. Perso je lui
reproche l'absence d'espaces de nommage qui pollue le langage par le
trop grand nombre de fonctions et le mixage fonctionnel/objet encore
trop transitionnel. Php délègue beaucoup (trop?) de discipline au
programmeur. C'est une force pour la souplesse, pour monter rapidement
quelques pages modestes avec 3 fonctions, mais le besoin d'un cadre de
travail (framework) se fait sentir sur des projets de plus grosse
dimension type progiciel.

Tu fais
comme tu veux, mais n'en dégoûte pas les autres !

Le JS est souvent utilisé n'importe comment mais à part des
disfonctionnements ça ne porte pas à d'autres conséquences.
Pour le php il n'en va pas de même : les bons fonctionnements apparents
peuvent conduire à de graves conséquences.

Oulala. J'ai retiré le [HS] du sujet pour ça. Les applications
deux-point-zéro placent de la "logique métier" coté navigateur et
déclenchent des actions avec XHR. Un bug JS et on envoie n'importe quoi,
on flood ... Évidemment, ça se blinde coté serveur, mais ça peut être
désagréable quand même. JS est critique s'il s'occupe de données métiers
(avec JSON, on fait des choses formidables).

Alors, oui, quand je vois du html pourri je gueule à l'arnaque quant au
php qui pourrait l'avoir pondu, et par voie de conséquence je doute des
compétences du gus qui manipule ce php et suis prêt à tout pour l'en
dégouter.

Et si vous lui expliquiez simplement ce qu'il faut faire ? Car vous
mettez très exactement le doigt sur la source du problème : il se situe
entre la chaise et le clavier, nulle par ailleurs dans ce cas. Je gueule
aussi à "l'arnaque" (si j'ai payé pour ça ;) ) quand je vois des
horreurs invalidables.

On peut râler sur php, c'est pas de sa faute si on lui fait générer du
html pourri. Je suis certains qu'on en trouve autant dans les autres
langages. Php est populaire chez les hébergeurs, donc plus de monde
programme ou essaye de programmer en php ; il est normal que les
technophiles amateurs (et les exécutants des décideurs pressés) s'y
essayent avec plus ou moins de succès et génèrent des goretteries. La
qualité vient en apprenant. Hé oui, il faut apprendre html et js avant
de prétendre le générer !

Avec l'avènement de css, ça devient quand même plus simple de générer un
code propre. Design et programmation sont des préoccupations
différentes, mais ont besoin l'une de l'autre, c'est une collaboration
qu'il faut savoir entretenir par l'échange de maquettes/prototypes par
exemple...


Bref : peace and love



--
FG

Bonjour,

Disons que cette profusion de $ dans le code me met mal à l'aise ?

On aime ou on aime pas certes, ça permet néanmoins de distinguer les

symbole de variable facilement.

Je ne vois pas en quoi ça facilite quoi que ce soit (on ne voit plus que
ça), en JS on n'a pas ça et on distingue tout aussi bien - et même
mieux, je trouve (pas de distraction).
Mais ... bon ... l'est un peu tard pour que je donne mon avis.

C'est un détail cosmétique.

C'est un peu pourquoi je mettais celui-là en avant comme excuse :
"Disons que ..."

Traduction : j'ai d'autres griefs qui à mon sens n'interressent pas les
foules, surtout celles du JS.

Le JS est souvent utilisé n'importe comment mais à part des
disfonctionnements ça ne porte pas à d'autres conséquences.
Pour le php il n'en va pas de même : les bons fonctionnements apparents
peuvent conduire à de graves conséquences.

Oulala. J'ai retiré le [HS] du sujet pour ça. Les applications
deux-point-zéro placent de la "logique métier" coté navigateur et
déclenchent des actions avec XHR.

Bon là on s'écarte un peu du JS (on fait intervenir le serveur).
J'entends par JS, celui utilisé uniquement côté client.
Si le JS commence à aller titiller le PHP, on en revient à mon idée
première : PHP = danger.

Qu'on solicite le serveur directement (php, cgi, asp ...) ou via XHR
même combat : html pourri -> mauvais programme côté serveur -> mauvais
programmeur -> retourne apprendre les bases.

Un bug JS

Si on ne requeste pas un truc intelligent (bout d'instructions serveur)
ça n'est vraiment pas plus grave qu'un lien erroné.

et on envoie n'importe quoi,

pas seulement, on peut allègrement multiplier les bugs des 2 côtés ...

on flood ... Évidemment, ça se blinde coté serveur, mais ça peut être
désagréable quand même. JS est critique s'il s'occupe de données métiers
(avec JSON, on fait des choses formidables).

Tu aurais un bon site didactique et surtout d'exemples en JSON ?
J'ai un peu regardé :
http://www.json.org/jsonfr.html
Où, suprise, une chaîne est encadrée de " exclusivement ! ?

Je n'ai pas entrevu d'alternative au JSON (contrairement au XHR)
Je veux dire : comment ça fonctionne t-il si JS désactivé ?

Alors, oui, quand je vois du html pourri je gueule à l'arnaque

Et si vous lui expliquiez simplement ce qu'il faut faire ?

Heu ... il y en a parfois une sacrée crasse ...

On peut râler sur php, c'est pas de sa faute si on lui fait générer du
html pourri.

C'est surtout essssstrèmement facile : une petite boucle sur un query de
BdD et on en remplit des lignes sinon des pages avec du crade hâtivement
bâclé, ou pire, du crade qu'on ne sait pas que c'en est.
On est tellement occupé à concocter son query que la syntaxe du résultat
vient bien en 5ième plan, et puis ... du moment qu'ça marche, hein ?

Je suis certain qu'on en trouve autant dans les autres langages.

On parle du php parce que c'est à la portée de n'importe qui, et que
c'était le sujet abordé.

Hé oui, il faut apprendre html et js avant de prétendre le générer !

C'est bien ce que je dis.

Et j'extrapole : comme je ne vois que le html, s'il est pourri,
j'imagine que ça ne doit pas être mieux en amont.

Avec l'avènement de css, ça devient quand même plus simple de générer un
code propre.

Déjà qu'ils méconnaissent le html, ça va pas aider pour les css.

Bref : peace and love

Disons comme ça.

Et parlons d'autre chose, alors ce JSON ?

--
ASM

François Girault wrote:

Bonjour,

Disons que cette profusion de $ dans le code me met mal à l'aise ?

On aime ou on aime pas certes, ça permet néanmoins de distinguer les

symbole de variable facilement. C'est un détail cosmétique. Perso je lui
reproche l'absence d'espaces de nommage

<aol />

C'est certainement (avec l'incohérence des APIs) un des problèmes
majeurs de PHP.

qui pollue le langage par le
trop grand nombre de fonctions et le mixage fonctionnel/objet encore
trop transitionnel.

s/fonctionnel/procédural/
La programmation fonctionnelle, c'est Haskell, Caml, Lisp etc...

Et accessoirement, le mélange procédural/objet/fonctionnel donne de très
bons résultats dans d'autres langages (Python et Common Lisp par
example...). Le problème de PHP est de "forcer" une couche objet sur un
langage essentiellement procédural (l'inverse semble fonctionner bien
mieux...). Accessoirement, s'inspirer du modèle objet de Java est
également très discutable...

On peut râler sur php, c'est pas de sa faute si on lui fait générer du
html pourri. Je suis certains qu'on en trouve autant dans les autres
langages. Php est populaire chez les hébergeurs, donc plus de monde
programme ou essaye de programmer en php ; il est normal que les
technophiles amateurs (et les exécutants des décideurs pressés) s'y
essayent avec plus ou moins de succès et génèrent des goretteries. La
qualité vient en apprenant. Hé oui, il faut apprendre html et js avant
de prétendre le générer !

Non ?-)

Et accessoirement, connaître un minimum le protocole HTTP, ça peut aider
aussi...


--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

ASM wrote:
(snip)

Oulala. J'ai retiré le [HS] du sujet pour ça. Les applications
deux-point-zéro placent de la "logique métier" coté navigateur et
déclenchent des actions avec XHR.

Bon là on s'écarte un peu du JS (on fait intervenir le serveur).

Et ? Ca reste du javascript, non ?

(snip)

Et parlons d'autre chose, alors ce JSON ?

JSON n'est rien de plus qu'un format de sérialisation "light". Ses

principaux intérêts sont que:
- c'est facile à générer depuis n'importe quel langage (côté serveur)
- c'est du javascript valide, il n'y a donc aucun parsing à faire (côté
client)
- c'est moins verbeux que XML (donc moins d'octets à transférer)
- c'est lisible et éditable par un être humain.


--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"

Bruno Desthuilliers wrote:

Et parlons d'autre chose, alors ce JSON ?

JSON n'est rien de plus qu'un format de sérialisation "light". Ses

principaux intérêts sont que:
- c'est facile à générer depuis n'importe quel langage (côté serveur)
- c'est du javascript valide, il n'y a donc aucun parsing à faire (côté
client)
- c'est moins verbeux que XML (donc moins d'octets à transférer)
- c'est lisible et éditable par un être humain.

Bonjour,

J'avais compris que JSON était un moyen de transférer des données par
XMLHttpRequest moins "volumineux" que XML. Et qu'il fallait de quoi
"coder" dasn un sens et "décoder" dans l'autre.

A vous lire j'ai l'impression d'avoir compris de travers ?