Design & Développement web - Le topic des canards qui mangent des cookies

[Tomaka17]

Et non c'est pas super relou a écrire

Imaginons que j'ai un truc en REST qui prend en entrée un très gros JSON et qui est censé l'écrire dans la base de données.

Je fais comment ? Je me connecte à la "vraie" base de données, je simule l'écriture, je vérifie si ça s'est bien écrit comme il faut, et je rollback ?
Le côté "vraie base de données" me fait peur, même si ce n'est pas une peur justifiée.


En fait le problème c'est que les tests, c'est censé tester des petits morceaux de code. Par exemple si t'as un code qui calcule des factorielles, des racines carrés, une matrice, etc. c'est facile d'écrire un test et d'écrire le test avant la fonction.

Par contre si on imagine un site web, t'as un code qui sauvegarde dans la base de données et un autre code qui lit la base de données. Dans un monde idéal, il faudrait considérer que ces deux codes sont inséparables et les tester en même temps, ce qui n'est pas possible vu qu'en général le code qui lit va te sortir les infos dans une purée de HTML.
Après tout ça ne concerne que ce code-là de savoir comment et où sont stockées les infos. Certes ça ne risque pas de changer souvent, mais pour moi ce n'est pas censé rentrer dans le cadre d'un test de vérifier qu'une nouvelle entrée dans la base de données a été créée.

[tenshu]

Pour le JSON tu peux faire une vraie requête, ou simuler plusieurs entrées de json différent "y compris mals formatés".
Et ensuite tu test que les données ont bien été insérées dans ta base.
Une fois que c'est fait tu rollback.

[Anon26492]

http://browserfame.com/1079/opera-ice

the fuck ?

[darkgrievous]

Outlook.com and Hotmail Allow No Margins

Outlook.com has discontinued support for:

margin
margin-top
margin-right
margin-bottom
margin-left

[Skiant]

Oh, quelle bonne idée.

[Tomaka17]

L'avenir de l'email, c'est le text/plain

[moimadmax]

http://browserfame.com/1079/opera-ice

the fuck ?

Par contre je viens de regarder la vidéo, et j'ai pas entendu le moment ou il dit qu'il abandonne presto. Bien que sur IOS ça pourrait se comprendre car il me semble qu'apple interdit les navigateurs.

[Anon26492]

L'avenir de l'email, c'est le text/plain

Ça serait pas une mauvaise chose

---------- Post added at 15h57 ---------- Previous post was at 15h54 ----------

Par contre je viens de regarder la vidéo, et j'ai pas entendu le moment ou il dit qu'il abandonne presto. Bien que sur IOS ça pourrait se comprendre car il me semble qu'apple interdit les navigateurs.

C'est plus subtil que ça : Apple t'impose l'utilisation de son moteur JS. Ce qui revient en pratique à interdire tout navigateur n'utilisant pas Webkit et le moteur JS maison, à l'exception d'Opera Mini qui fait son rendering coté server.

Beaucoup plus vicieux, Apple réserve le bon moteur JS à son navigateur. Les apps utilisent la version daubée du moteur JS. Ça explique en grande partie les perfs pourraves des applications HTML5 balancés dans un conteneur natif sur l'appstore (les gens intelligents du fond me diront à raison que si t'as besoin des perfs de nitromachin, c'est que ton app est trop lourde. I concur.)

[tenshu]

Pour Opera Mini, il me semble pas que tout le rendu se fasse côté serveur, c'est surtout les images qui sont dégrossies chez eux.
Si je me rappelle bien ils ont eux chaud, Apple voulait purger leur navigateur (bien bien plus rapide à l'époque que safari mobile), mais pour pas faire genre c'est de la concurrence déloyale et comme il es resté confidentiel, bah ils l'ont laissé.
D'ailleurs il n'a pas été mis à jour pendant plus d'un an et depuis il garde pas mal de truc pourris (genre la page qui se rafraichie quand on passe d'une champs d'un form à un autre).

Pour ce qui est du reste Apple garde la dernière version du moteur JS pour sa gueule, les autres utilisent la version précédente.
Mais bon c'est pas très flagrant, surtout sur les dernières versions : cf chrome vs safari mobile.

[moimadmax]

C'est parce qu'Opera mini n'a pas de moteur Javascript, ou un très limité. Du coup c'est pour cela que ça recharge quand tu modifies un form. C'est parce que normalement la modif de ce form doit modifier autre chose dans la page. D'où le reload.

Aaaah Apple. C'est vraiment une mentalité de Merde.

[Skiant]

Aaaah Apple. C'est vraiment une mentalité de Merde.

C'est peu de le dire.

[Anon26492]

Voilà. Opera Mini gère bien le JavaScript (et donc le rendu) coté serveur. Il n’envoie qu'un "snapshot" instantané de la page au client. Ça se voit assez bien sur certains sites.

[moimadmax]

Mais du coup, ils on eu où l'info qu'Opera abandonne presto sur mobile ?
Je vais re-regarder la vidéo plus attentivement ce soir.
Peut être qu'il ont réussi à faire plier Apple.
Et les autres mettront combien de temps pour sortir un navigateur équivalent, et en vendant le truc comme une navigation innovante.

[Anon26492]

ALA redesign.

De manière assez amusants, le résultat est très moyen sur ma N7 avec le header mal placé et une font trop petite.

[GrandFather]

De manière assez amusants, le résultat est très moyen sur ma N7 avec le header mal placé et une font trop petite.

Problème de header également avec IE9, par contre la police est correcte. Ca la fout un tout petit peu mal...

[Anon26492]

Visiblement le header, c'est fait pour. Design feature

[MrBeaner]

Bon, l'examen de Web se rapproche et j'ai envie de consolider tous ces nouveaux concepts abordés en cours (trop vaguement selon moi) en complétant mes notes à l'aide des infos sur le web. Je pensais utiliser le MDN mais, comme il semble que ce soit les mêmes qui font Web Plateform Docs, je sais pas trop où me diriger (j'ai pas non plus envie d'utiliser les deux, j'aurais pas forcément le temps).

Je penche pour le MDN parce que l'autre c'est un wiki à priori. Mais je pense que vous êtes plus à même de me conseiller, nan ?

Ou alors je me fourvoie et je dois retourner sur W3Schools

[Skiant]

MDN c'est un Wiki aussi. C'est juste que le Web Platform Docs, il est plus récent et donc pas forcément rempli.
Si tu veux consolider tes bases, j'te conseillerai d'aller voir les trainings sur Code Academy, les tutos de la branche HTML/CSS/JS sont pas mal du tout, pour ce que j'en ai touché.

[Tomaka17]

C'est un peu vague aussi "j'ai envie de consolider tous ces nouveaux concepts".
Par exemple c'est pas en cherchant au hasard sur le MDN que tu trouveras comment aligner un block au milieu ou comment centrer un truc verticalement.

[MrBeaner]

Oui c'est vrai, excuse-moi. C'est juste que je cherchais une bonne source d'infos (comme MDN ou WPD) pour clarifier certains trucs qui sont dans mes notes. Rien de bien folichon en fait, mon cours n'abordait que les rudiments de HTML, CSS et Javascript. Juste en guise de complément.

Mais je pense rester sur le MDN du coup vu que l'autre est en alpha (quoi que l'introduction au langage HTML y est bien foutu).

[MrBeaner]

Au fait, je comprends pas trop l'illustration de <colgroup> qui est donnée sur MDN :

https://developer.mozilla.org/en-US/.../Element/table

<!-- Table with colgroup -->
<table>
  <colgroup span="4" class="columns"></colgroup>
  <tr>
    <th>Countries</th>
    <th>Capitals</th>
    <th>Population</th>
    <th>Language</th>
  </tr>
  <tr>
    <td>USA</td>
    <td>Washington D.C.</td>
    <td>309 million</td>
    <td>English</td>
  </tr>
  <tr>
    <td>Sweden</td>
    <td>Stockholm</td>
    <td>9 million</td>
    <td>Swedish</td>
  </tr>
</table>
 
<!-- Table with colgroup and col -->
<table>
  <colgroup>
    <col class="column1">
    <col class="columns2plus3" span="2">
  </colgroup>
  <tr>
    <th>Lime</th>
    <th>Lemon</th>
    <th>Orange</th>
  </tr>
  <tr>
    <td>Green</td>
    <td>Yellow</td>
    <td>Orange</td>
  </tr>
</table>

Comment on peut créer plusieurs groupes de colonnes du coup (et les différencier) ? Je comprends pas...

EDIT : c'est surtout pour les "class", les span je crois comprendre que c'est le nombre de colonnes comprises dans le groupe (mais à partir de quand ? De 0 par défaut ? Et si on veut un groupe à partir de la colonne 6 ?)

[elkoo]

C'est pas très compliqué, dans <colgroup> si tu veux englober certaines colonnes tu ajoutes des <col> et en effet tu joues sur le span, le <col> suivant agira sur la ou le groupe de colonnes suivante (toujours en fonction du span) et oui ça commence à la première colonne. Pour commencer à la 6eme tu fais donc ça : http://codepen.io/anon/pen/CzvGr

[MrBeaner]

Okay. Merci. C'était pas très clair

[Tomaka17]

Tiens je me demande comment vous gérez la validation de formulaire en PHP.

Imaginons que l'utilisateur remplisse un formulaire, qu'il rentre un mauvais input, et qu'il valide le formulaire en envoyant un POST vers une page PHP.
Je ne parle pas du fait de déterminer si oui ou non les valeurs sont correctes. Je parle de l'étape après. On sait qu'une valeur est incorrecte et on veut afficher un message d'erreur.
Je vois quatre solutions :

- afficher directement le formulaire avec les messages d'erreur en retour de la requête POST, mais de manière générale ça n'est pas propre car si tu rafraichis la page ben ça refait l'action

- faire une redirection 303 vers l'url du formulaire avec des paramètres GET, par exemple rediriger vers "/formulaire?erreur=Vous avez mal entré tel truc&champs1=2&champs2=bonjour&champs3=lorem ipsum", mais ça n'est pas propre d'afficher ça en clair dans l'URL

- la même chose mais avec un seul paramètre GET du genre "/formulaire&values=cc414bfc9c00475b59c87595299ff31d " avec une clé qui correpond à une liste de valeurs stockées server-side, mais ça n'est pas génial car on ne sait pas quand supprimer les informations server-side

- stocker le message d'erreur et les valeurs des champs dans la session server-side, faire une redirection 303 vers le formulaire et ressortir le message d'erreur à ce moment-là, mais ça n'est pas non plus propre car ça dépend du navigateur ; si moi navigateur j'envoie le POST mais que je ne suis pas la redirection et qu'à la place j'ouvre une autre page ben j'aurai le message d'erreur affiché là bas


Est-ce que j'en ai oublié une ?
J'ai longtemps utilisé la dernière méthode, mais là j'essaye de revoir un peu mes fondamentaux.

[Anon26492]

C'est un peu le seul domaine où je trouve l'Ajax vraiment justifié. Pour les utilisateurs sans JS, tu fallback sur une des méthodes citées.

Sinon visiblement désormais y'a moyen d'utiliser le localstorage pour ça.

[Alliante]

Tiens je me demande comment vous gérez la validation de formulaire en PHP.

Imaginons que l'utilisateur remplisse un formulaire, qu'il rentre un mauvais input, et qu'il valide le formulaire en envoyant un POST vers une page PHP.
Je ne parle pas du fait de déterminer si oui ou non les valeurs sont correctes. Je parle de l'étape après. On sait qu'une valeur est incorrecte et on veut afficher un message d'erreur.
Je vois quatre solutions :

- afficher directement le formulaire avec les messages d'erreur en retour de la requête POST, mais de manière générale ça n'est pas propre car si tu rafraichis la page ben ça refait l'action

- faire une redirection 303 vers l'url du formulaire avec des paramètres GET, par exemple rediriger vers "/formulaire?erreur=Vous avez mal entré tel truc&champs1=2&champs2=bonjour&champs3=lorem ipsum", mais ça n'est pas propre d'afficher ça en clair dans l'URL

- la même chose mais avec un seul paramètre GET du genre "/formulaire&values=cc414bfc9c00475b59c87595299ff31d " avec une clé qui correpond à une liste de valeurs stockées server-side, mais ça n'est pas génial car on ne sait pas quand supprimer les informations server-side

- stocker le message d'erreur et les valeurs des champs dans la session server-side, faire une redirection 303 vers le formulaire et ressortir le message d'erreur à ce moment-là, mais ça n'est pas non plus propre car ça dépend du navigateur ; si moi navigateur j'envoie le POST mais que je ne suis pas la redirection et qu'à la place j'ouvre une autre page ben j'aurai le message d'erreur affiché là bas


Est-ce que j'en ai oublié une ?
J'ai longtemps utilisé la dernière méthode, mais là j'essaye de revoir un peu mes fondamentaux.

Chouette un topac de mangeurs de cookies, je m'incruste

Pour ma part je renvoie le formulaire sur lui même avec une clé générée et une session pour éviter le XSS et ensuite je valide le tout en PHP avec des fonctions custom ou les fonctions crées exprès pour la validation, la méthode 1 donc.

Le refresh ne me gêne pas plus que ça car tu as une popup du browser pour le signaler.

Avec le JS y a toujours bien un petit malin qui passera outre même si les validations sont plus sexys

Sinon c'est vrai que l'Ajax prend ici tout son sens.

Ensuite comme ça doit te les casser de refaire sans cesse les mêmes trucs ben tu finis par utiliser un framework genre Laravel et tu te poses plus de questions

[Tomaka17]

Ensuite comme ça doit te les casser de refaire sans cesse les mêmes trucs ben tu finis par utiliser un framework genre Laravel et tu te poses plus de questions

Le truc c'est que j'écris mon propre framework
(la doc n'est pas à jour)

[tenshu]

Chouette un topac de mangeurs de cookies, je m'incruste

Pour ma part je renvoie le formulaire sur lui même avec une clé générée et une session pour éviter le XSS et ensuite je valide le tout en PHP avec des fonctions custom ou les fonctions crées exprès pour la validation, la méthode 1 donc.

Le refresh ne me gêne pas plus que ça car tu as une popup du browser pour le signaler.

Avec le JS y a toujours bien un petit malin qui passera outre même si les validations sont plus sexys

Sinon c'est vrai que l'Ajax prend ici tout son sens.

Ensuite comme ça doit te les casser de refaire sans cesse les mêmes trucs ben tu finis par utiliser un framework genre Laravel et tu te poses plus de questions

Pareil,

Mega warning quand vous faite un re-fill des champs avec le contenu saisit à la soumission.
Comme vous le savez tout ce qui vient du client est forcement (au moins en théorie ) evil.

Donc gaffe.

[Alliante]

Le truc c'est que j'écris mon propre framework
(la doc n'est pas à jour)

Donc tu n'as pas de problème avec tes formulaires, tu fais des petits

$rules = array(
'name' => 'required|max:50',
'email' => 'required|email|unique:users',
);

et c'est magique, ton framework fait tout le sale boulot

Blague à part j'y jetterai un œil tiens.

[tenshu]

Pas formidable les pipe non ? :/

Celui de sf si ça peut t’inspirer Tomaka : http://symfony.com/fr/doc/current/book/forms.html