Modifier une TextBox
Le
Gloops
Bonjour tout le monde,
Quelqu'un a-t-il une idée de pourquoi ce code fonctionne bien sous IE, =
mais pas sous Firefox ?
Depuis un input type="image" situé dans une cellule d'un tableau, je =
veux diminuer de 10 la valeur dans un input type="text" situé dans la=
troisième cellule de la même ligne du tableau.
Firefox affiche "debut", et puis c'est tout.
Je n'ai pas vu de réserve quant à Firefox dans la doc de parentNode n=
i
celle de childNodes.
onclick="javascript:alert('debut');var
txb=this.parentNode.parentNode.childNodes[2].childNodes[1];alert(txb.id=
);txb.value=txb.value
- 10;"
A toutes fins utiles voici le code de la cellule cible :
<td id="td3">
<div class="ajax__slider_h_rail" tabindex="-1"
id="ctl00_ContentPlaceHolder1_AffichePlat1_SliderExtender1_railElement"=
>
<div class="ajax__slider_h_handle" style="overflow: hidden; position=
:
absolute; left: 140px;">
<img
src="WebResource.axd?d=dDANfV61VaIqaNbHeMm4KsVQem1mMTMElT9vyWt-2hJIB7=
wEdQ2PdH3JSuZPv03VwbaEZn0Xtl9h2CSXwzK5xpkELXCprZTAAvBRWOwcNlZm6lde1gndK87=
g_sUXh56YUY0yUkmDNsYMSO1M0oIkYghX4PgD3Op-mkLoztN8aO9EORm20&t=633398=
816400000000"
id="ctl00_ContentPlaceHolder1_AffichePlat1_SliderExtender1_handleImage"=
>
</div>
</div>
<input style="display: none;"
name="ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire"
value="100"
onchange="javascript:setTimeout('__doPostBack('ctl00$ContentPlaceHolde=
r1$AffichePlat1$txbCuissonLineaire','')',
0)" onkeypress="if (WebForm_TextBoxKeyHandler(event) == false) retu=
rn
false;" id="ctl00_ContentPlaceHolder1_AffichePlat1_txbCuissonLineaire" =
type="text">
</td>
Quelqu'un a-t-il une idée de pourquoi ce code fonctionne bien sous IE, =
mais pas sous Firefox ?
Depuis un input type="image" situé dans une cellule d'un tableau, je =
veux diminuer de 10 la valeur dans un input type="text" situé dans la=
troisième cellule de la même ligne du tableau.
Firefox affiche "debut", et puis c'est tout.
Je n'ai pas vu de réserve quant à Firefox dans la doc de parentNode n=
i
celle de childNodes.
onclick="javascript:alert('debut');var
txb=this.parentNode.parentNode.childNodes[2].childNodes[1];alert(txb.id=
);txb.value=txb.value
- 10;"
A toutes fins utiles voici le code de la cellule cible :
<td id="td3">
<div class="ajax__slider_h_rail" tabindex="-1"
id="ctl00_ContentPlaceHolder1_AffichePlat1_SliderExtender1_railElement"=
>
<div class="ajax__slider_h_handle" style="overflow: hidden; position=
:
absolute; left: 140px;">
<img
src="WebResource.axd?d=dDANfV61VaIqaNbHeMm4KsVQem1mMTMElT9vyWt-2hJIB7=
wEdQ2PdH3JSuZPv03VwbaEZn0Xtl9h2CSXwzK5xpkELXCprZTAAvBRWOwcNlZm6lde1gndK87=
g_sUXh56YUY0yUkmDNsYMSO1M0oIkYghX4PgD3Op-mkLoztN8aO9EORm20&t=633398=
816400000000"
id="ctl00_ContentPlaceHolder1_AffichePlat1_SliderExtender1_handleImage"=
>
</div>
</div>
<input style="display: none;"
name="ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire"
value="100"
onchange="javascript:setTimeout('__doPostBack('ctl00$ContentPlaceHolde=
r1$AffichePlat1$txbCuissonLineaire','')',
0)" onkeypress="if (WebForm_TextBoxKeyHandler(event) == false) retu=
rn
false;" id="ctl00_ContentPlaceHolder1_AffichePlat1_txbCuissonLineaire" =
type="text">
</td>
J'y suis. L'espace qui se trouve au début de la cellule est compté so us
Firefox (pas sous IE) comme son élément n° 0, ce qui décale la su ite, et
qui fait donc que txbCuissonLineaire est l'élément n° 2 alors que s ous
IE c'est l'élément n° 1.
Pour avoir le même script sous IE et Firefox, j'ai remplacé le
childNodes[1] de la fin du chemin par getElementsByTagName (à la casse
près car je le cite de mémoire) comme ceci :
getElementsByTagName("input")[0]
et ça marche.
Alors après si il y a de la prose à raconter pour comprendre pourquoi
l'espace de début est compté comme un élément sous Firefox et pas sous
IE, ça j'ignore.
Maintenant que le script fonctionne, ça me laisse un peu de temps pour
m'intéresser à des messages de la console Firefox dont l'intérêt
n'apparaissait pas central pour déboguer.
La console attire mon attention sur la notion de reflow.
Les anglophones pourront en savoir plus là :
https://developers.google.com/speed/articles/reflow
Pour résumer, le navigateur doit recalculer la taille et la position
d'éléments de la page pour qu'ils tiennent compte les uns des autres. La
durée du reflow s'accroît du fait de la superposition d'éléments, et de
l'usage de chemins relatifs dans le DOM.
Justement, ma page utilise ces deux éléments, puisque :
1/ la zone de saisie texte est masquée par un contrôle Slider de l'Aj ax
Control Toolkit, afin de faciliter la saisie en visualisant la valeur
numérique au prorata du segment minimum/maximum
2/ pour le support clavier je recours à l'évaluation relative de la
position d'un élément, par rapport à celui qui déclenche une comm ande.
Sur une machine très lente qui doit jouer à la fois les rôles de se rveur
et de machine cliente, j'obtiens le repositionnement du slider sur son
rail en presque une seconde, un peu moins si la manÂœuvre est renouvelé e
plusieurs fois. Plusieurs pressions successives ne donnent lieu au déla i
qu'une fois, le curseur étant observé à sa position initiale puis à sa
position finale.
J'ai donc l'impression d'avoir fait une concession nécessaire pour
obtenir un meilleur confort de saisie.
Au demeurant, j'ai placé, pour le mettre au point, un contrôle
d'affichage d'article (en fait de plat pour un restaurant), je vais
probablement découvrir d'autres points intéressants maintenant que la
question va être de placer plusieurs exemplaires de ce contrôle sur l a
page, puisque c'est à ce prix que je propose un choix au client final.
Maintenant que le script fonctionne, ça me laisse un peu de temps pour
m'intéresser à des messages de la console Firefox dont l'intérêt
n'apparaissait pas central pour déboguer.
La console attire mon attention sur la notion de reflow.
Les anglophones pourront en savoir plus là :
https://developers.google.com/speed/articles/reflow
Pour résumer, le navigateur doit recalculer la taille et la position
d'éléments de la page pour qu'ils tiennent compte les uns des autres. La
durée du reflow s'accroît du fait de la superposition d'éléments, et de
l'usage de chemins relatifs dans le DOM.
Justement, ma page utilise ces deux éléments, puisque :
1/ la zone de saisie texte est masquée par un contrôle Slider de l'Aj ax
Control Toolkit, afin de faciliter la saisie en visualisant la valeur
numérique au prorata du segment minimum/maximum
2/ pour le support clavier je recours à l'évaluation relative de la
position (dans l'arbre DOM) d'un élément, par rapport à celui qui
déclenche une commande.
Sur une machine très lente qui doit jouer à la fois les rôles de se rveur
et de machine cliente, j'obtiens le repositionnement du slider sur son
rail en presque une seconde, un peu moins si la manÂœuvre est renouvelé e
plusieurs fois. Plusieurs pressions successives ne donnent lieu au déla i
qu'une fois, le curseur étant observé à sa position initiale puis à sa
position finale.
J'ai donc l'impression d'avoir fait une concession nécessaire pour
obtenir un meilleur confort de saisie.
Au demeurant, j'ai placé, pour le mettre au point, un contrôle
d'affichage d'article (en fait de plat pour un restaurant), je vais
probablement découvrir d'autres points intéressants maintenant que la
question va être de placer plusieurs exemplaires de ce contrôle sur l a
page, puisque c'est à ce prix que je propose un choix au client final.
(supersedes pour corrections)
c'est quand même curiousss qu'un nombre s'écrive 'début' !!
qu'est-ce qu'on a à faire de ces complications-DOM-nodes alors qu'on a à
dispo le JS simplissime propre aux formulaires ?
(avec son avantage quant à la vitesse, à ce que j'ai cru comprendre)
Ha? Paske tout ce verbiage ne représente qu'un petit td ?
en très laid JavaScript de nos grand' mères :
<img src="1.jpg" alt="bouton"
onclick="ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire.value
= 'blabla';" />
L'image est entre les 2 balises "form" du formulaire.
Quelle était la question ?
Car enfin ... on aimerait connaitre le contenu du texte à passer à
ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire
histoire de voir à voir
Ha? c'est une simple opération ?
Mézalors il faut bien se souvenir que la valeur d'un input/text est du
"texte" et non pas un "nombre" même si elle est '23'
et donc,
maybe :
<img src="1.jpg" alt="bouton"
onclick="var c =
ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire; c.value -=
10;" />
ou:
<img src="1.jpg" alt="bouton"
onclick="var c =
ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire; c.value =
c.value*1-10;" />
En délayé (plus propre ?) :
var c =
this.form.elements['ctl00$ContentPlaceHolder1$AffichePlat1$txbCuissonLineaire'];
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Pas lu l'article mais ... si tout est dimensionné d'avance (ou stylé
proprement *) il ne doit pas il y avoir beaucoup de reflow, ou, en tous
cas, pas beaucoup de délai perceptible à la réorganisation de l'affichage.
Sauf,
sauf,
sauf,
à utiliser des tables pour la mise en forme
surtout,
surtout,
avec IE qui les digère très mal
(pas trop essperimenté les versions >7)
*
On style tout pour l'objet invisible, et il passe ensuite en visible par JS
Pareil pour display 'none'/'block'
Ne concerne le "dynamisme" (changement progressif). Encore que ... avec
le HTML.5 ?
Mébon ... pas de table, pas de table et pas de table !!!
(pour un resto ... pas idéal ! ;-) )
d'où l’intérêt de se servir d'une fonction qui sera réutilisée pour
chaque groupe concerné par le phénomène dont une tentative d'explication
est donnée ci-après.
rhen compris à rhen compris à cette histoire de segmentation
ni de "numérique" pour des plats culinaires ?!
Boudiou !
V'là t'encore pire !
C'est quoi cette histoire de "support clavier" ?
déjà : quoi t'est-ce "support" ?
ensuite, le clavier ?
- celui virtuel des tablettes et phones ?
- celui du Mac ? du PC ?
- de quelles races ces claviers ? (US, PU, ES, FR-CA ? FR-FR ? ...)
Le serveur, en local, est immédiat ! (calculs, échanges, toussa)
Boudiou !!!!
c'est plus que lent ça là dis donc !
Doit y avoir plein de temporisations JS ou d'effets de styles ?
Y a combien d'aller/retour avec le serveur pour élastiquer cette zone de
saisie ?
(l'Ajaxionnage est-il d'à propos ? réellement ? et si oui, est-il
optimisé ?)
??? rien compris
une pression sur "quoi" ?
Je ne comprends pas qu'il faille 1 seconde pour traiter le contenu du
champ de texte (puisque ce n'est fait qu'une fois en fin de saisie).
Ou alors c'est voulu ? Pour des effets smooth d'affichages ?
Au passage je ne vois pas comment est déterminée la fin de la saisie, la
« position finale ».
un contrôle d'affichage ?
ou de choix ?
Pour le contrôle d'affichage, je ne vois pas trop comment ça peut
fonctionner.
Et quel affichage ?
celui de mon iPhone ? de mon NetBook 7" ? mon 27" ? les 8 à 900px de
large auxquels je force mes navigateurs ?
C'est au prix du contrôle des clients que tu leur proposes des choix ?
(s'il prend de la salade en entrée, les épinards lui seront refusés au
plat suivant ?)
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
d'où l’intérêt, dès que c'est possible, d'atteindre les machins par
leurs *name* pour les éléments de *form*
(on peut aussi les atteindre par leurs rang dans la collection de ces
éléments)
c'est la méthode la plus simple si on ne connait pas d'avance les noms
des éléments
function diminue(){
var part = this.parentNode; // le parent en franchissant l’écueil du
while(part.tagName != 'TD') part = part.parentNode // node fantôme
var cible = part.getElementsByTagName('INPUT')[0].
cible.value = cible.value*1-10;
}
Ben paske ...
les navigateurs consciencieux se créent ce node (contrairement à cet IE
dissipé)
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Je rappelle mes réponses précédentes (23/08/14) et leurs liens
Réponses qui évoquaient déjà ce problème de node invisible.
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
De ce côté ça a l'air à peu près correct, pour la machine que c 'est.
Là, si je voulais des boutons à gauche et à droite du curseur, la t able
m'évitait des heures et des heures de recherche ...
Ah, IE6 ... C'est vrai qu'il me sort (depuis le WebBrowser sur les
clients lourds) des erreurs sur certains sites, qui ont répondu d'entré e
ah non je ne vais pas me fatiguer à assurer la compatibilité avec ç a ...
Du coup j'ai ajouté un champ dans la table pour mémoriser pour chaque
site si on autorise les messages de débogage.
Enfin là ce n'est pas le projet dont je parlais au début.
Tu veux dire qu'on risque de gagner du temps si je mets une plus grande
largeur à la cellule qui contient le slider et sa textbox ?
Tiens c'est possible, ça ...
Ah, le HTML 5 ...
ça fait un bout de temps que j'ai repéré qu'il faudra que je passe un
peu de temps là-dessus. Le CSS 3 aussi.
Je vois que Monsieur a de l'humour :)
N'empêche, pour gérer la réservation des tables, il fallait que je crée
... une table dans la base. Je l'ai appelée TableDeRestau, sinon bonj our
les confusions ... Y compris pour le système.
Le plus souvent, quand on commande son plat, on le demande saignant,
moyen ou bien cuit. J'ai appelé ça la cuisson par paliers. Je propose
aussi au restaurateur qu'un plat puisse être proposé avec une cuisson
linéaire, c'est-à-dire que le degré de cuisson demandé par le cli ent va
être exprimé par un nombre. Ce mode de gestion de la cuisson est asso rti
d'un maximum à saisir en même temps que le choix du mode de cuisson. Si
c'est 100, le degré de cuisson choisi par le client sera un pourcentage ,
de la cuisson maximale (quasi carbonisé). Sinon on peut imaginer que ç a
soit un nombre de minutes.
Moui, ce n'était pas très clair.
Alors donc, le curseur sert à choisir un niveau de cuisson, entre 0 et
le maximum. Avec le curseur c'est facile à choisir à la souris.
Au clavier, comme la zone de saisie est masquée, nada. Alors, j'ai mis
deux boutons avec des scripts. Celui de gauche diminue le degré de
cuisson choisi de 10, et celui de droite l'augmente de 10. Cela jusqu'à
la limite, mais ça c'est le Slider qui le gère.
Bon alors ça ça marche très bien quand le composant est tout seul s ur la
page.
Bien entendu, il s'agit de présenter plusieurs plats. Pour ça sur
ASP.Net on a quelque chose qui s'appelle une DataList. C'est bien, ça
m'affiche mes différents plats, sauf que là la plate-forme bloque les
scripts clients de peur que ça soit des scripts pirates. Il y a une
commande pour les autoriser, mais j'ai dû me planter dessus, j'attends
que quelqu'un me réponde dans le forum adapté.
Hum ... Si tu voyais la machine que c'est tu comprendrais.
Pour charger le navigateur j'attends une minute.
C'est vrai qu'il faut un aller-retour pour gérer ça, car le slider de
l'AjaxControlToolkit ne gère pas son contenu en local. J'ai mis un
moment à réaliser ça.
Du coup ça va plus vite de déclencher le script plusieurs fois, comme ça
il n'y a qu'un aller-retour pour donner la position finale.
Les boutons que j'ai mis pour augmenter ou diminuer la valeur du degré
de cuisson.
Ce qu'il faut gérer, c'est la position du curseur.
J'ai d'abord cherché à le faire en local, mais ce truc n'a pas de
propriété value. C'est le postback qui le repositionne.
En fait j'ai fini par m'apercevoir que c'est un peu plus sophistiqué qu e
ça. J'ai créé une structure avec un plat, un degré de cuisson, un numéro
de variante et une quantité. Le plat est désigné dans cette structu re
par son numéro, et le composant d'affichage affiche le nom, la
description, la photo et les différentes variantes. Il permet aussi de
retourner le numéro de variante sélectionné ainsi que le degré de
cuisson sélectionné.
Maintenant que j'ai su afficher tout ça, il reste à autoriser les
scripts côté client sinon je ne suis pas avancé. Mais ça, ça re lève du
forum ASP.Net.
Pour le moment j'ai fait attention d'utiliser des div float plutôt que
des tableaux, pour qu'on puisse afficher sur un petit écran. Après, j e
me doute qu'il y aura d'autres points qu'il faudra que j'aborde pour
vraiment assurer la compatibilité avec les téléphones portables.
De la mise en boîte, pas vrai ?
:)
C'est ce que j'ai fini par faire. Avec seulement un composant sur la
page, ça marche très bien.
Il restera à tester avec plusieurs composants sur la page, puisque pour
le moment les scripts clients sont bloqués.
C'est cohérent avec la réputation de IE d'être un peu fantaisiste a vec
l'implémentation des standards. Je serais bien en peine de développer plus.
Il sert à quoi ce nÂœud au fait ?
Ah, oui, c'est à cette occasion que j'ai appris que dans la page
ASP.Net, il faut se méfier du sens de "Visible". Visible="false"
signifie absent de la page sur le navigateur client. Donc, logiquement,
inaccessible aux scripts clients.