Reprise du message précédent :

 
T'as cassé ma joie salaud

 
Juste au moment où Harko va rouler des pelles ? Comme c'est bizarre.
Fais gaffe mon garçon, j'ai la modération en MP, et par chez nous on n'aime pas trop les voleurs et les fils de pute.

 
Merde, je suis démasqué

Ben dis donc ça poste pas mal depuis ce matin...
 
Sinon une question pour moi...si personne à la soluce ici, je chercherais une autre cat...Mais bon
 
Là je vais faire un sous domaine de mon site :
 
blog.domaine.fr qui pointe sur www.domaine.fr/blog
 
ça c'est bon.
 
Mais voilà quand je serais sur blog, parfois je devrais mettrais des images avec des scripts PHP dans www.domaine.fr/images et non pas www.domaine.fr/blog/images
 
Dans mon script je devrais récupérer en dur le lien du domaine initial c'est possible ?
 
Bon finalement, je vais poster ça dans PHP
 
Thx

Tiens, j'ai une question bête.
 
Mettons que j'ai un formulaire, avec un <select> de taille fort respectable alimenté par une base de données (donc value = code dans la table, et on affiche le libellé).
La finalité du formulaire est un enregistrement dans la base de données du choix de l'utilisateur, donc le code.
 
Problème : Entre les deux, on veut afficher un récapitulatif des choix...Est-ce que vous prenez la peine d'éviter une nouvelle requête pour récupérer le libellé, et si oui, comment?

sauve en SESSION ...

oui, sauf que tu ne transmets que le code à ton script qui valide le formulaire, pas le libellé, là, à la base, dans mon machin.

tu peux t'éclater à faire value="id-texte" et splitter ensuite dans ton code

Oué, mais c'est quand même horriblement moche.

utilise une frame
De toute façon, t'as bien une méthode/fonction qui affiche le libellé correspondant au code, donc tu t'en sers

je suis d'accord, mais si tu veux surtout pas refaire de requête...
tu peux aussi utiliser un JS pour stocker le texte dans un input hidden

huhu ne suppose rien à propos de mon code je te prie. Et encore moins à propos du machin que je suis en train d'essayer de patcher proprement pour ne pas rajouter de la merde sur le tas de bouse séchée existant...

C'est la seule soluce que j'ai trouvée aussi, le JS. Et requête de l'autre coté si le paramètre hidden est vide...mais je me demandais si quelqu'un de plus intelligent que moi aurait un truc plus joli.

(figure 1 : truc en JS qui améliore un peu le bouzin, mais qui n'est pas indispensable pour le bon fonctionnement de l'appli.)

Ça change rien au problème Si tu veux faire apparaitre un champ faut quand même passer par JS. Sauf si tu recharges toute ta page suivant le bouton radio choisi (et encore, t'es obligé de mettre un submit à côté pour valider le changement). Donc mieux vaut s'abstenir et laisser les champs apparents.

Je sais que c'est con, et je sais que le JS est censé être là juste pour améliorer l'usage. Sauf que j'ai dev un semainier qui permet de sélectionner des plages horaires avec la souris (drag&drop).

Donc pour se passer du semainier, il faudrait des input text pour la date, l'heure de début et l'heure de fin de la plage. Sauf que là encore, impossible d'ajouter des plages à la volée. Donc il faudrait soit un textarea, en espérant que l'user entre correctement les dates et heure de debut/fin de la plage (1 par ligne), et là on peut toujours rêver, soit avoir un input text pour la date, un pour l'heure de debut de la plage, l'heure de fin, un bouton submit pour la valider et en proposer une autre etc...

Donc pour le moment ça sera JS obligatoire (le JS ne sera absolument pas nécessaire pour tout le reste, càd la visualisation, la recherche etc...). Je n'ai pas l'intention de laisser ça comme ça. De toute façon je suis assez sensible à l'accessibilité. Mais dans ce cas présent, je pense que c'est la meilleure solution.

En principe, je fais l'inverse. Je dev un site "100% JS-free", avec les contrôle d'entrée etc... et une fois que je suis sûr que le site est bien fait et sécurisé j'ajoute la couche JS.

Bon sinon j'ai une question :
Jusqu'à présent, en MySQL, je n'utilisais pas de requêtes préparée. J'avais même un peu oublié que ça existait. Donc j'ai relu des trucs à ce sujet et au final je me pose une question. La question ne sera pas "quel intérêt d'utiliser des requêtes préparées", mais plutôt l'inverse : "dans quel cas ne pas les utiliser", vu que ça m'a l'air plus sécurisé, plus simple et plus propre...

dans certains cas, et selon la db, une requete "ordinaire" sera plus performante.
enfin, je devine (peut être mal) que tu parles de sgbd/sql là hein?

(skoi un semainier? )

 
J'oublie tjs de préciser C'est corrigé.

 
LMMJVSD §

C'est peut-être pas le bon terme. Mais en gros j'ai mes jours de la semaine, en 8 colonnes (les 7 jours de la semaine + 1 jour de la semaine suivante), chaque colonne représente 24h.

En cliquant avec la souris (sur la colonne du mercredi 7 mars par exemple) au niveau de 13h15 et en glissant jusqu'à 18h30 on créé une plage horaire.

Et ouais... Déjà côté serveur, tu dois avoir une URL qui accèpte la méthode POST avec les valeurs, et qui ferait la vérification. Donc que ce soit entré par l'user ou par un script, ça ne devrait rien changer... Même chose pour le formulaire, devrait être disponible...

 
Ça envoie une série de timestamps ... donc bon, demander à l'user d'entrer les timestamps brut ça risque de pas le faire

Ouais mais non en fait
- Tu fous tes inputs comme tu veux
- Dans ton onload de ta page tu masques le input text (display: none)
- Et quand tu cliques sur le bouton radio tu affiches le input text.
Du coup, ne pas avoir de JS n'est pas bloquant, puisque l'utilisateur voit le champ input (et tu marques du texte genre "dans ce cas spécifiez dans le champ suivant" pour préciser que ce champ n'est à remplir que si tu coches la case).
 

Impossible d'ajouter des plages à la volée ? Ben tu ajoutes des plages une à une, avec un rafraîchissement de la page. C'est chiant, mais c'est la bonne manière pour que ce ne soit pas bloquant.
On n'a jamais dit que faire un site accessible était simple comme bonjour.
 
Ceci étant dit, c'est le genre d'interface riche (et je suppose, pour une application spéciale) pour laquelle le besoin d'accessibilité est plus discutable, je pense.

Revoit ton application

c'est jamais bien ce que les autres font de toute façon

Ah oué ok, j'avais mal compris pour le coup des champs cachés. Dans ce cas en effet...

Concernant les plages ajoutées une à une, c'est ce qui est prévu par la suite Mais pour le moment non.

Mayçaybiensur

Parce que tu vois un meilleur moyen que les timestamps pour envoyer des informations de temps toi ?

C'est pas faux

Salut à tous,  
dites je voudrais creer un formulaire tout bete, du type :
Nom: ______       Sexe : M/F   (à choisir)  
 
et faire en sorte que chacune de ces entrées soit listées sur une page dans un tableau par exemple!
C'est possible?

 
J'en doute Ça me semble un peu compliqué et usine à gaz ton truc

En fait non c'est tout con, comme des commentaires sur un site web, chaque fois que quelqu'un ecrit ca rajoute une ligne.
Mais il faut passer en php/mysql pour ca? (j'y connais guère)

Le contenu de ce message a été effacé par son auteur

Le JS, c'est bien mangez-en et ceux qui désactivent le JS, bah ils assument et basta.
Pareil pour les cookies.
Ceux qui veulent pas faire l'effort il voudrait pas qu'on mette les images en ASCII-Art aussi pendant qu'on y est pour être sûr qu'ils voient les images ?

Au contraire, ce sont ceux qui font l'effort de désactiver le JS  
 
Et accessoirement, il y a, ne t'en déplaises, des gens dont les admins réseau désactivent le JS pour des raisons de sécurité  
 
Maintenant je sais que tu t'en fous, mais bon...

au cas où, encore une fois : google n'a pas de JS.
et encore une fois : il y a des navigateurs (PDA, tel portable (demande à harko), lecteurs d'écrans pour aveugles...) qui n'ont pas non plus le JS (ou très limité).... après, si pour toi les minorités sont à écarter, ou si ton site ne risque pas de les toucher, c'est un autre problème.

On ne sais jamais qui peut passer sur un site ou en avoir besoin, rendre un site inaccessible c'est toujours écarter les minorités ou considérer qu'elles ne méritent pas de pouvoir vériter le site

 

 
 
www.google.fr :
 

Il parlait du googlebot, du crawler de google

Et accessoirement, tu noteras que www.google.com est parfaitement utilisable sans Javascript

Sauf que Google ne suit de toutes façons pas les formulaires.  
Donc que tu fasses un input caché ou quoi, Google il s'en tape comme de sa première capote.
 
Non mais ça va, vous êtes pas obligé de rebondir, j'avais juste envie de le dire, c'est tout, globalement j'fais un effort.

je viens de comprendre pourquoi je n'arrive pas à me logger depuis Opera Mini en cliquant sur "Répondre"

T'es au courant qu'il y a un dérivé de safari sur ton téléphone

Mézoci:
La durée de vie (#26), la présence et l'objectif des cookies (#28) sont indiqués sur le site.
Et pour être complet: les cookies portent un nom explicite qui permet d'identifier sans équivoque le site sur lequel ils ont été émis. (#27)
 
 

ASCII-Art j'en doute(*) mais un alt="texte de remplacement" sera toujours le bienvenu
 
 
(*) l'ASCII-Art dans un lecteur d'écran c'est ... Comme les titres!!!!!! de topic????? *-*-*-=_=-°-°-

c'est bien ce que je disais
 
ceci dit, faire un site accessible sur un sujet inaccessible (par exemple adapter un site sur un jeu vidéo aux non-voyants) c'est un peu inutile, je pense