bonjour est'il possible de mettre des input hidden dans une iframe pour récuperer des valeurs ?
 
ex :  
<iframe src=...> <input type=hidden name=toto id=toto></iframe>
 
est-ce que je peux ainsi recuperer la valeur du input toto ?

Je vois pas l'intérêt !?!

assez compliquer a espliquer je vais faire au plus simple.
 
j'ai une page (page1) composée d'un dropdownlist et d'une iframe.
Page2 est la page qui est affichée dans page1 grace a l'iframe.
 
Je veux que quand l'utilisateur change la valeur de la dropdowlist l'iframe change. Seulement je vois pas comment recuperer ma valeur dans la page2 sachant qu'elle se trouve dans la page1.
 
j'etais claire ou pas ?

Pourquoi ne pas tout simplement faire un formulaire classique contenant ta dropdown dans la page 1 qui envoie ses données à une page s'affichant dans l'iframe?
 
Quota: les frames, c'est mal, faut éviter, ça amène beaucoup d'emmerdes pour bien peu d'avantages

 
et comment qu'on fait pour envoyer les données ?

   
 
Tu as déjà fait un formulaire?

Je vois pas où est le problème étant donné que la source de l'iframe est défini dans la page 1 tout comme l'est la dropdownlist.
Si la ddl change, tu changes la source de l'iframe et c tout !?!

A inclure dans l'iframe :
<script>
parent.myVar=document.getElementById("toto" ).value;
</script>

 
Suggestions à la con power

Ah vraiment ? Ben c'est con parce que ça marche

Désactive le javascript et dis moi si ça fonctionne encore  
 
D'ailleurs tu ne fais que récupérer une valeur, lui veut que le contenu de l'iframe dépende de la valeur qu'on affiche/met en place au niveau de la dropdown (il faudrait donc mettre du JS sur la dropdown et le hooker à l'iframe), il n'y a rien qui justifie de le faire en JS alors que les formulaires sont là pour ça

J'étais en train de relire, et j'avais bel et bien compris à l'envers. Faut dire que c'est plutôt mal expliqué Il faut donc faire le script dans l'autre sens, mais du coup c'est pas la peine effectivement vu qu'on connait les variables avant de charger la page.
 
Ceci dit :
- Combien de crétins ont un navigateur antérieur à 2001 ?
- Combien de crétins désactivent le javascript ?
- le javascript, c'est souvent indispensable pour des formulaires complexes ou des fonctionnalités bizarres.
- les iframes, c'est BIEN. C'est juste qu'il faut les utiliser uniquement quand on en a besoin, et c'est au poil (vive le remote scripting). Sinon autant éviter effectivement. Par contre les frames tout court, c'est plutôt mal effectivement.
   
 

Un certain nombre de personnes surfant depuis leur boite peuvent n'avoir accès qu'à des navigateurs antédilluviens, ou très spécifiques (IE5/Mac, NS4.7, un vieux Mozilla type 1.2, ...). Tu n'as aucune idée de ce que les gens utilisent ou de leur contexte, et les gens souffrant de handicaps n'ont bien souvent pas de choix à ce niveau. Sans parler des navigateurs utilisés sur les nouveaux périphériques (PDA, portables)...
 
Et je ne parle même pas des gens utilisant Lynx ou Links (fyi la dernier version stable de Lynx date de 2004, donc ton 2001...)

Environ 10% des gens naviguent sur le net avec le javascript totalement ou partiellement désactivé

non  
Rendre le Javascript indispensable à l'utilisation d'un site est d'une stupidité sans nom, et permet accessoirement de s'assurer de l'impossibilité pour les moteurs de recherche de l'indexer correctement  
De plus le JS, aussi bien fait soit-il, n'est jamais complètement cross-browsers (ne serait-ce que parce que certains navigateurs ont un support du JS aléatoire voir nul, et que certains utilisateurs ou certaines boites désactivent le javascript [si un admin système n'est pas trop con, il va éviter de laisser ce genre de trucs à ses utilisateurs lambdas])

   
Les problèmes des frames et des iframes sont strictement les mêmes, les iframes sont tout aussi stupides que les frames et à n'utiliser que dans certains cas bien précis en faisant extrèmement attention au contenu de chaque frame avec des liens (des vrais, pas des JS à la con) vers le frameset lui même.
Non, les iframes c'est pas "bien".

No comment, suffisament HS. (et relis ce que je dis)
 
   
 

Tu dis que les iframes c'est "bien", ce n'est pas le cas
Surtout quand tu dis juste derrière que les frames c'est "mal", dans la mesure ou c'est strictement la même chose (la mise en page étant plus difficile avec les iframes)

L'iframe j'ai pas le choix de toute facon.
bon le mieux est que je vous donne ma page :
 

 
donc la source de la iframe contient l'adresse d'une page + un certain nombre de parametre. Le nombre de param peut etre très grand, donc j'ai peur que la taille de la source soit limitée et c'est pour ca que j'aimerai passer par des input hidden
 
 
Ensuite je travail avec asp.Net et  c# si je mets un input hidden entre les balises iframes, j'arrive pas a récuprer cette valeur. D'ou ma question est-ce qu'on peut recuperer ou passer des valeur de cette facon dans les iframes ???

InGuN :
Pour info IE 5.5 ou meme IE 6 date de quand ? (Je parle pas des mises a jour de secu hein ).
 
Sinon concernant le "remote scripting" tu n'as pas besoin d'iframes.
Soit tu utilises un technique recente, genre XMLHttpRequest. Soit tu utilises d'autres techniques, j'en connais au moins 3 autres (voire meme 4 en fait) et ces dernieres ne font pas intervenir les iframes ni les frames

c'est quoi le remote scripting ? et les methode que tu connais ?

Le remote scripting est le fait de "faire une requete" sans recharger la page et ensuite afficher le resultat de cette derniere dans la page (toujours sans la recharger).
 
Afin de faire ca, il existe plusieurs techniques, toutes utilisent le javascript (donc cette technique doit etre optionnelle pour le fonctionnement d'un site, et non obligatoire).
 
Personnellement je connais ca comme techniques :

C'est de loin la "meilleure" technique.
 

Avantages : On peut avoir une sorte de "retour" boolean.
On peut avoir un resultat concis, pas besoin de metre du html dans un cookie, on recupere tout de suite la valeur souhaitee.
Inconveniens : Besoin des cookies. Les cookies sont limites en taille, donc attention.

Inconvenients : Il faut imperativement inserer le script dans le head du document, sinon cela peut ne pas fonctionner sur certains navigateurs.
Le script doit implementer une methode de mise a jour de la page mere (ou une sorte de "callback" ).
 

Avantages : En theorie on a pas besoin de JS, on pourrait faire tout le travail du cote de l'applet java.
Avec un applet java on pourrait creer un connexion persistante, donc plus besoin de faire des requetes tout le temps pour savoir si qqch a change. L'applet serait informe uniquement lors des mises a jours.
Desaventages : Il faut la JVM d'installe.
 

desole mais j'ai rien compris
 
en plus moi je peux recharger la page ;-)