Geckozone

Comme les administrateur peuvent avoir besoin d'effectuer plusieurs actions, ils ne désirent pas nécésairement perdrent les résultats de leurs recherche.

C'est d'ailleurs un des principal points qu'ils m'ont demandé qui justifie la nouvelle refonte de mon paneau d'administration. Il veulent pouvoir avoir le contrôle: Parfois il veulent ouvrir le lien dans la fenêtre courrante, parfois dans une nouvelle, parfois en onglet.

Sauf que le contexte me force à utiliser un formulaire qui possède plusieurs voies de sortie.

Pour le moment, j'ai mis de coté l'aspect formulaire et je modifie dymiquement les liens (vu que CE formulaire ne passe que l'ID du comptes à traiter). Mais dans le cas de situation similaire, sur des formulaire plus complexe, cette solution ne sera pas applicable, alors la question se pose réellement tant et aussi longtemps que les navigateurs ne seront pas plus efficace.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0

Je suis désolé, je ne vois vraiment pas en quoi tu as besoin de tout ça

Reprenons, tu as un formulaire pour rechercher un utilisateur. Il sort une liste de liens vers les utilisateurs

Code : Tout sélectionner

* titi
* toto

Lorsqu'il suit le lien "titi", l'admin a plusieurs choix entre les liens

Code : Tout sélectionner

- Modifier le compte
- Supprimer le compte
- Bloquer le compte
- Envoyer un message
- Visualiser le compte
- Voir la boite de message du compte
- Vérifier les accès liés du compte

À part pour le bouton "Rechercher", je ne vois pas pouquoi tu as des boutons de formulaire. Dans "Modifier le compte", d'accord, mais dans ces listes de liens ?
Ce n'est pas parce qu'il y a de l'ajax qu'il faut transformer les liens en boutons de formulaire.

Après c'est à l'utilisateur de savoir s'il veut conserver la recherche en ouvrant chaque utilisateur dans un nouvel onglet ou pas, ce n'est plus ton problème à toi il me semble

À la rigueur, tu peux avoir un cookie pour stocker la dernière recherche, mais franchement, on arrive à la limite du raisonnable là

Je pense que ton problème c'est d'utiliser un bouton de formulaire pour faire une action de lien

[/url]

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1) Gecko/20061010 Firedragon Firefox/2.0

Après c'est à l'utilisateur de savoir s'il veut conserver la recherche en ouvrant chaque utilisateur dans un nouvel onglet ou pas, ce n'est plus ton problème à toi il me semble Clin d'oeil

Heu, c'est une blague la, tu fais exprès de me narguer ? ou tu n'a vraiment pas compris que depuis 1 page de réponse je veux que l'utilisateur AI le choix et que le problème c'est qu'actuellement IL NE PEUX PAS avoir le controle.

Donc, pour revenir au sujet:

Bon, donc expliquez-moi comment tu vous allez faire pour -et sans modifier les boutons de formulaire- envoyer le formulaire à 12 différentes page en passant en paramêtre l'utilisateur sélectionné dans la liste

Exemple (Code tappé à la volé pour l'exemple):

Code : Tout sélectionner

<script type="text/javascript">
   function goSearch(){
       //Requête AJAX qui place les résultat dans le DIV id='searchResult'
       //Note: J'ai déjà placé des résultats manuellement pour l'exemple
   }

   function sendTo(page){
       $('form1').action = "/admin/" + page;
       $('form1').submit();
   }
</script>
<form method="post" action="">
    <input id="userName" type="text" name="name" value="" />
    <input type="button" onclick="goSearch();" name="search" value="Search" />
</form>

<form id="form1" method="post" action="possibilité de 12 pages différentes">
   <div id="searchResults">
      <input type="radio" name="id" value="521523" /> John <br />
      <input type="radio" name="id" value="185273" /> Bob <br />
      <input type="radio" name="id" value="372393" /> Richard <br />
   </div>
   <a href="#" onclick="sendTo('modify');">Modifier</a>
   <a href="#" onclick="sendTo('delete');">Supprimer</a>
   <a href="#" onclick="sendTo('block');">Bloquer</a>
   <a href="#" onclick="sendTo('sendMsg');">Envoyer un message</a>
</form>

Cette solution fonctionne, le formulaire est envoyé en post aux bonnes pages. Cependant, il est IMPOSSIBLE pour l'utilisateur de décider s'il veux ouvrir le formulaire dans une nouvelle fenêtre, dans la page courrante ou dans un onglet. (Cet exemple s'ouvrira UNIQUEMENT dans la page courrante. Si vous essayez de l'ouvrir dans un nouvel onglet ou dans une nouvelle page, c'est le HREF qui sera pris en compte, aucun envoi de formulaire ne sera fait.)

^^ Bon, vous avez une solution concrète, parceque depuis 1 page vous ne faite que de remettre en doute la nécéssité, sans jamais donner de solution.... c'est très peu constructif (et je deviend aggressif devant ce genre d'attitude).

(Une chance que je cherche pas une solution à un problème réellement complexe, parcequ'ici, avant de vous avoir justifié et expliqué suffisamment que le problème est bien réel pour que vous me croyez, j'aurais trouvé 15 réponses pertinentes sur developpez.net (ou sur n'importe quel autre forum)... Sérieusement j'ai jamais vu un tel entêtement à ne pas vouloir trouver une solution. C'est chiant de se faire dire que le problème se pose pas quand je l'ai devant moi.)

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0

Je pense comme Calimo, pas besoin de bouton et de formulaire dans ce cas, des liens avec des paramètres get serait plus appropriés :
<a href="modify.php?id=521523">Modifier</a>
<a href="delete.php?id=521523">Supprimer</a>
<a href="block.php?id=521523">Bloquer</a>
...

FMaz a écrit :
Après c'est à l'utilisateur de savoir s'il veut conserver la recherche en ouvrant chaque utilisateur dans un nouvel onglet ou pas, ce n'est plus ton problème à toi il me semble Clin d'oeil
Heu, c'est une blague la, tu fais exprès de me narguer ?

Non, pas du tout, c'est juste que je cherche à comprendre et que franchement, jusque là, tu n'avais exposé que des idées vagues.

Maintenant, avec cet exemple, je vois ce que tu veux faire. Tu vas certainement hurler, mais

Il faut bien se rendre compte que le HTML ne peut pas faire d'interfaces riches. On parle de XUL (le langage XML utilisé pour construire l'interface de Firefox) comme d'un langage d'interface riche, justement parce qu'il permet plus de choses (des menus etc.). Le HTML est horriblement pauvre en possibilités. Et ce n'est pas parce qu'Ajax a été inventé que ça change quoi que ce soit. Tout comme tu ne rouleras jamais à 200 km/h avec une 2CV, et tu ne mettras jamais un film qualité DVD sur une disquette. Je prend des exemples exagérés, mais c'est ça !

Code : Tout sélectionner

<form method="post" action="search_user.php">
    <input id="userName" type="text" name="name" value="" />
    <input type="submit" name="search" value="Search" />
</form>

Page search_user.php :

Code : Tout sélectionner

<div id="searchResults">
      <a href="user_details.php?user=521523"> John </a>
      <a href="user_details.php?user=185273"> Bob </a>
      <a href="user_details.php?user=372393"> Richard </a>
</div>

user_details.php :

Code : Tout sélectionner

<a href="user_modify?user=372393">Modifier</a>
<a href="user_delete?user=372393">Supprimer</a>
<a href="user_block?user=372393">Bloquer</a>
<a href="user_msg?user=372393">Envoyer un message</a>

Bon, tu l'auras compris, je n'aime pas ajax (en terme d'utilisateur, je veux dire, je trouve les interfaces ajax absolument affreuses, dramatiquement compliquées et hermétiques pour la plupart, cassant pas mal d'acquis en terme d'ergonomie (notamment l'impossibilité de faire un marque-page ou même un simple "retour arrière").

Si tu y tiens malgré tout, il faut enregistrer un évènement onchange sur ton set de boutons radio qui change le contenu des liens plus bas (pas besoin d'ajax)

Code : Tout sélectionner

<script>
function ChangeLinks {
	// récupère la valeur du bouton radio sélectionnée
	// modifie les liens en conséquence
}
</script>

<input type="radio" name="id" value="521523" onchange="ChangeLinks(521523) /> John <br />
<input type="radio" name="id" value="185273"onchange="ChangeLinks(85273) /> Bob <br />
<input type="radio" name="id" value="372393" onchange="ChangeLinks(372393) /> Richard <br />
   </div>
   <a href="modify.php?user=">Modifier</a>
   <a href="delete.php?user=">Supprimer</a>
   <a href="block.php?user=">Bloquer</a>
   <a href="msg.php?user=">Envoyer un message</a>

Ça ne fonctionnera pas sans javascript, contrairement à la solution que je propose plus haut (environ 10% des utilisateurs du net ont javascript désactivé). Au moins les adeptes du clavier pourront-ils utiliser l'interface

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1) Gecko/20061010 Firegecko Firefox/2.0

Edit: complètement grillé par martin, au moins on est du même avis

Ah sinon j'oubliais, pour récupérer les résultats de la recherche, il y a aussi le bon vieux bouton précédent (c'est vrai qu'avec Ajax, c'est une fonction qui se perd bien souvent

)

Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1) Gecko/20061010 Firegecko Firefox/2.0

Si tu lis un de mes message précédent sur la première page, je dis que c'est la seule solution que c'est trouvé pour me dépanner sans pénaliser l'administrateur:

Modifier l'attribue HREF du lien et envoyer tout ca en GET.

Dans ce cas-ci, ce n'est qu'un ID, mais dans le cas de formulaire plus complexe, ca risque d'être ... compliqué (vue qu'une URL à une taille limite de 256 chr pour respecter les standards il me semble)

De plus, le AJAX est actuellement mal utilisé, c'est vrai. Mais regarde des applications comme GMail, c'est très bien intégré.
Dans mon cas, la recherche et les résultat ET les actions sur les résultats sont sur la meme page. Si tu veux faire une nouvelle recherche, pas besoin de faire précédent (et si tu fais précédent, tu tombera sur la page... précédente, sans problème)

Ajax est très utile pour des cas comme:
- les cas d'auto-complétion,
- recherche simple (mon cas),
- validation avant l'envoi (rien de plus chiant que d'avoir une erreur après avoir remplis 75 champs et faire précédent et que tout soit perdu (généralement les pass et le code/image de validation antibot.)
- vérification s'il y a des nouveau message, si oui, recharger la page

Bref, je pense au contraire que Ajax à un excellent potentiel, mais comme le javascript à ses débuts, les gens l'utilisent actuellement à n'importe quel sauce (un peu comme les curseurs javascript avec des lettres qui suivent: innutile, lourd, souvent buggé)

Bref, jusqu'ici, dans 100% de mes interface fesant appel à Ajax, le bouton précédent ne perturbe pas la navigation du site.

Ça ne fonctionnera pas sans javascript, contrairement à la solution que je propose plus haut (environ 10% des utilisateurs du net ont javascript désactivé). Au moins les adeptes du clavier pourront-ils utiliser l'interface

Considérant que je programme actuellement la 4ieme version de mon moteur de JEU en ligne, si un utilisateur n'à pas la dernière version des navigateurs courrant (IE, FireFox, Opera, etc), les cookies et javascript d'activé, il ne peut pas jouer (il est averti avant)

Avec des fonctionnalité de Drag and Drop pour la gestion de l'inventaire, des maps dynamique pour certains, des infobulles un peu partout, javascript est un pré-requis pour mes visiteurs dans mon cas.

(Ce n'est pas comme si c'était un site d'information pour downloader un driver: c'est un jeu en ligne... Déjà heureux que j'ai pas de Flash en plus (quoi que...))

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0

FMaz a écrit :Bon, donc expliquez-moi comment tu vous allez faire pour -et sans modifier les boutons de formulaire- envoyer le formulaire à 12 différentes page en passant en paramêtre l'utilisateur sélectionné dans la liste

Je te l'ai dit plus haut mais je répète, tu peux mettre plusieurs boutons submit à ton formulaire avec des valeurs différentes.

Quelque chose comme :

Code : Tout sélectionner

<input type="submit" name="action" value="action1">
<input type="submit" name="action" value="action2">
...
<input type="submit" name="action" value="action9">

Là il te suffit dans le script de réception du formulaire de vérifier le paramètre "action" et de faire le traitement en conséquence (ce script est le contrôleur dans un site basé sur le modèle MVC).

Comme je l'ai aussi dit plus haut, je ne veux pas mettre une page de redirection. (Principalement parceque ca pose des problèmes d'utilisation du bouton précédent)

Je ne pense pas non plus que de grouper une douzaine de pages très distintes soit une bonne idée, ni une bonne modélisation objet de ma structure.

Par exemple, le gestion du lieu dans lequel le "personnage" se trouve.
Grouper un lieu et un personnage dans un meme fichier n'est pas jolie dutout.
Le formulaire doit vraiment s'envoyer vers des destinations différentes.

Hum, je viend de penser à un truc... assez non conventionnel, mais bon, dites-moi ce que vous en pensez:

Code : Tout sélectionner

<form method="post" action="page1.php">
  <form method="post" action="page2.php">
    <form method="post" action="page3.php">
      <form method="post" action="">
        <input type="radio" name="id" value="123134" />
        <input type="radio" name="id" value="234213" />
        <input type="radio" name="id" value="134234" />
        <input type="radio" name="id" value="564676" />
      </form>
      <input type="submit" value="Modifier"/>
    </form>
    <input type="submit" value="Envoyer Message"/>
  </form>
  <input type="submit" value="Autre truc"/>
</form>

Une telle approche est possible ?

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0

FMaz a écrit : Une telle approche est possible ?

non

FMaz a écrit :Dans ce cas-ci, ce n'est qu'un ID, mais dans le cas de formulaire plus complexe, ca risque d'être ... compliqué

On réagit au cas concret que tu nous soumets...

Si il y a des infos qui perdurent le long de plusieurs pages, à mon avis c'est le rôle des sessions de s'en charger.

FMaz a écrit :Je ne pense pas non plus que de grouper une douzaine de pages très distintes soit une bonne idée, ni une bonne modélisation objet de ma structure.

la cible du formulaire peut être unique, çà ne t'empêche pas d'être modulaire dans ta programmation (include, par ex).

Plus globalement, tu as choisis d'utiliser une technologie, html, tu es bien obligé de faire avec ses contraintes. Visiblement tu essaies d'utiliser un lien, pour soumettre un formulaire en post, et tu voudrais qu'il ait quand même le comportement d'un lien. Faut choisir, c'est un lien avec get, ou un submit avec post, avec leurs comportements respectifs côté client.

martin a écrit :
FMaz a écrit : Une telle approche est possible ?
non

... c'était qu'une idée...

martin a écrit :
FMaz a écrit :Dans ce cas-ci, ce n'est qu'un ID, mais dans le cas de formulaire plus complexe, ca risque d'être ... compliqué
On réagit au cas concret que tu nous soumets...
Si il y a des infos qui perdurent le long de plusieurs pages, à mon avis c'est le rôle des sessions de s'en charger.

Stocker n'importe quoi en session c'est mal. Surtout si c'est le résultat d'une recherche (qui n'à rien à avoir et n'est pas suffisamment statique pour être stocké (donc rechargé) en session.. gaspille de mémoire, saturation du serveur)
Je n'ai pas de cas concret en ce moment, donc je m'attend pas à ce que vous comprenniez. (parcequ'il semble que sans concret, vous ne puissiez pas envisager un problème)

martin a écrit :
FMaz a écrit :Je ne pense pas non plus que de grouper une douzaine de pages très distintes soit une bonne idée, ni une bonne modélisation objet de ma structure.
la cible du formulaire peut être unique, çà ne t'empêche pas d'être modulaire dans ta programmation (include, par ex).

En effet, sauf que ca ne respecte absolument pas une modélisation correcte. C'est du bricolage amateur.

martin a écrit : Plus globalement, tu as choisis d'utiliser une technologie, html, tu es bien obligé de faire avec ses contraintes. Visiblement tu essaies d'utiliser un lien, pour soumettre un formulaire en post, et tu voudrais qu'il ait quand même le comportement d'un lien. Faut choisir, c'est un lien avec get, ou un submit avec post, avec leurs comportements respectifs côté client.

Tiens donc, on passe de "mais ta pas besoin de..." à "contrainte"... intéressant comme évolution, dommage que ca prend 2 pages pour en arriver la. Bon, sur ce, j'en ai assez. Depuis le début j'ai ma solution de toute facon. Je voulais juste tester le forum.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0

FMaz a écrit :
martin a écrit :
FMaz a écrit :Je ne pense pas non plus que de grouper une douzaine de pages très distintes soit une bonne idée, ni une bonne modélisation objet de ma structure.
la cible du formulaire peut être unique, çà ne t'empêche pas d'être modulaire dans ta programmation (include, par ex).
En effet, sauf que ca ne respecte absolument pas une modélisation correcte. C'est du bricolage amateur.

Ça n'a absolument rien d'un bricolage amateur, l'utilisation d'un contrôleur est le modèle utilisé dans la plupart des applications Web (dont Google Mail).

FMaz a écrit :Depuis le début j'ai ma solution de toute facon. Je voulais juste tester le forum.

tu m'excuseras, si il te prenait l'envie de poursuivre l'expertise, ce sera sans moi, ici ou ailleurs, j'ai autre chose à foutre que de me faire prendre pour un c**.

Et, entre nous, si ta programmation est mise en péril par le fait que tu ne puisses pas forcer l'ouverture d'un nouvel onglet, on peut émettre l'idée que de nous prendre de si haut est légèrement incongru.

beurk :þ

Geckozone

javascript: ouvrir dans un nouvel onglet