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

**Tomaka17** · 30/01/2013, 15h23

Ah non mon framework est encore mieux, puisqu'à chaque fois que tu sors du HTML qui contient un <form> il enregistre dans un cache la structure du formulaire.
Ensuite tu peux lui demander de vérifier que des données POST correspondent au formulaire de l'URL où tu es.

Par exemple si j'envoie "<form action="/prout"><input name="login" maxlength="50" /></form>" ça va automatiquement enregistrer un truc du genre "targetURL:'/prout',elements:{login:{maxlength:50}}" (je schématise, c'est pas ce format là en réalité).
Et dans le handler de /prout ça va charger ce fichier et vérifier que $_POST['login'] a une longueur inférieure à 50.

Les attributs à mettre dans les <input> correspondent à ceux du HTML5, donc en pratique le mec qui utilise mon framework n'a quasiment rien à faire.

**Skiant** · 30/01/2013, 15h27

Envoyé par Tomaka17

Les attributs à mettre dans les <input> correspondent à ceux du HTML5, donc en pratique le mec qui utilise mon framework n'a quasiment rien à faire.

Bien vu, ça, gratz.

**Tomaka17** · 30/01/2013, 15h31

Envoyé par tenshu

Pas formidable les pipe non ? :/

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

Ouai génial symfony, t'as 5000 lignes de code pour mettre un formulaire.
C'est le genre d'article que t'as linké qui m'a donné envie de bosser sur mon propre framework.

---------- Post added at 15h31 ---------- Previous post was at 15h27 ----------

En ce moment-même je bosse sur la partie template.
J'étais parti pour utiliser twig, mais non seulement c'est (très) lent mais en plus les trucs qui définissent leur propre syntaxe je suis pas fan.

Là avec mon framework tu écris tes templates directement en PHP, et ça appelle automatiquement htmlentities quand tu fais un echo.
Par exemple si le template c'est <html><body>Bonjour, <?php echo 'jo<n d&oe'; ?>. Ca va ?</body></html>
Il va te sortir en fait <html><body>Bonjour, jo<n d&oe. Ca va ?</body></html>

Je préfère ce genre de trucs tout con plutôt que de devoir écrire des tonnes de lignes de code et passer des heures à apprendre une syntaxe inventée de toute pièce.

Par contre j'ai pas encore trouvé comment j'allais faire pour retranscrire le système de block/extends de twig.
Je pourrais partir sur de simples fonctions, mais je préfère réfléchir avant s'il n'y a pas une meilleure méthode.

**Anon26492** · 30/01/2013, 15h41

Tu as bien raison.
Le meilleure moteur de template de PHP, c'est PHP

**tenshu** · 30/01/2013, 15h43

Envoyé par Mdt

Tu as bien raison.
Le meilleure moteur de template de PHP, c'est PHP

C'est vrai, même si twig est très bien.

**Alliante** · 30/01/2013, 15h44

Tu utilises les attributs HTML5 pour faire une validation PHP en fait ? Pas bête !

Les forms de Laravel : http://daylerees.com/2012/04/15/laravel-forms/
Pour le template ils utilisent Blade : http://daylerees.com/2012/04/07/laravel-blade/

**tenshu** · 30/01/2013, 15h44

Envoyé par Tomaka17

Ouai génial symfony, t'as 5000 lignes de code pour mettre un formulaire.
C'est le genre d'article que t'as linké qui m'a donné envie de bosser sur mon propre framework.

Un framework de form en objet je doute que ça puisse rester compact.

**Tomaka17** · 30/01/2013, 15h50

Faudrait que je me mette à bosser sérieusement sur la doc de mon framework histoire de montrer toutes les bonnes idées que j'ai eu en l'écrivant, mais comme disait je sais plus qui il y a quelques pages c'est vrai que c'est long et chiant à faire la doc.

Pareil pour les bases de données, j'étais parti sur une syntaxe du genre $database->schema->table->colonne
Evidemment ça sauvegarde les valeurs des autres colonnes aussi, afin d'éviter de faire une requête par colonne.
Tu pouvais par exemple écrire foreach($database->schema->table['prout > 12'] as $row) pour énumérer toutes les lignes dont la colonne prout est supérieure à 12.

Et si colonne était une clé étrangère tu pouvais écrire $database->schema->table->colonne->autre_colonne, avec autre_colonne qui venait de la seconde table correspondant à la clé étrangère.

D'ailleurs si mes souvenirs sont bons je vous avais montré ce code dans un pastebin à l'époque.

Le problème auquel j'avais pas pensé c'est que __toString() ne peut pas lancer d'exceptions. Du coup s'il y a une erreur dans le SQL ou autre tu te retrouves avec une critical error "toString cannot throw an exception".

**Awake** · 30/01/2013, 16h09

Les forms symfony sont ne pas spécialement longues ni complexes à écrire quand on connait, en général il s'agit une classe avec la description des champs. La validation des data user se fait en général sur le model (en annotation ou autre) ce qui est brillant au final puisque le model deviens aussi validable avec d'autres sources de données que le form (genre un autre form ou des datas générés aléatoirement pour faire des fixtures).

D'une manière générale vouloir tout réécrire c'est excellent pour apprendre mais les grosses librairies (doctrine, twig, symfony components) suivent mine de rien des bonnes pratiques de conception et d'optimisation, et sont particulièrement bien sécurisés/testées. Alors c'est vrai qu'il faut prendre le temps d'apprendre à les utiliser au mieux, mais se sera aussi le cas pour ceux qui décident d'utiliser ton framework perso.

**Skiant** · 30/01/2013, 16h25

Sinon, y'a des gens dans l'assemblée qui ont déjà utilisé le plugin ScrollSpy du Bootstrap ?
Ce petit fils de sa maman refuse obstinément de balancer l'event 'activate' ou d'ajouter la classe 'active' sur mes <li>.

J'ai sûrement fait un truc con (big up au chat de madame qui me réveille toutes les nuits en chouinant à la porte de la chambre pour avoir des câlins) mais évidemment pas moyen de trouver quoi.

Donc pour info :

Code HTML:

<body data-spy="scroll" data-target="#local-menu">

et plus loin :

Code HTML:

<ul class="nav local-menu maple affix" id="local-menu" data-spy="affix" data-offset-top="635">
	<li class="local-anchor"><a href="#whats-new">What's new</a></li>
	<li class="local-anchor"><a href="#crowd-funding">Crowd-funding</a></li>
	<li class="local-anchor"><a href="#preorder">Pre-order</a></li>
</ul>

Edit : J'ai trouvé. Donc pour ceux qui auraient un doute, le data-target doit impérativement être un parent du .nav, sinon ça ne marche pas.
J'ai ajouté un div#local-menu-wrap et j'ai mis ce div dans la target, et c'est passé. Voilà.

**Alliante** · 30/01/2013, 16h26

Envoyé par hijopr

Les forms symfony sont ne pas spécialement longues ni complexes à écrire quand on connait, en général il s'agit une classe avec la description des champs. La validation des data user se fait en général sur le model (en annotation ou autre) ce qui est brillant au final puisque le model deviens aussi validable avec d'autres sources de données que le form (genre un autre form ou des datas générés aléatoirement pour faire des fixtures).

D'une manière générale vouloir tout réécrire c'est excellent pour apprendre mais les grosses librairies (doctrine, twig, symfony components) suivent mine de rien des bonnes pratiques de conception et d'optimisation, et sont particulièrement bien sécurisés/testées. Alors c'est vrai qu'il faut prendre le temps d'apprendre à les utiliser au mieux, mais se sera aussi le cas pour ceux qui décident d'utiliser ton framework perso.

Yep, puis y a les IDE qui possèdent souvent des extensions dédiées au framework et qui facilitent pas mal la tâche

Mais des fois c'est cool aussi d'avoir un petit framework qui n'est pas une usine à gaz.

**Tomaka17** · 30/01/2013, 16h30

Envoyé par hijopr

D'une manière générale vouloir tout réécrire c'est excellent pour apprendre mais les grosses librairies (doctrine, twig, symfony components) suivent mine de rien des bonnes pratiques de conception et d'optimisation, et sont particulièrement bien sécurisés/testées. Alors c'est vrai qu'il faut prendre le temps d'apprendre à les utiliser au mieux, mais se sera aussi le cas pour ceux qui décident d'utiliser ton framework perso.

Justement je trouve les grosses librairies plutôt mal foutues car trop complexes à utiliser. Tu dis "il faut prendre le temps d'apprendre à les utiliser" comme si tu t'étais résigné du fait qu'un framework soit forcément complexe à utiliser. Moi je suis sûr que non.

Là par exemple mon core est vraiment simple à comprendre. Tu as des routes, chaque route correspond à une ou plusieurs URL ou patterns d'URL (ça c'est classique). Il y a un objet qui contient les infos de la requête, et un objet qui sert à sortir les données. Chaque route contient une liste de fonctions qui sont exécutées quand l'URL correspond, et chaque fonction peut arrêter la route ou indiquer que la route n'est pas la bonne. Et c'est tout.

Tu n'as pas besoin de créer de fichier pour configurer ta base de données, à la place tu définis le DSN et tout ce qu'il faut dans une de ces "before functions".
Tu n'as pas besoin de créer de fichier pour configurer ta méthode d'authentification, à la place tu le fais dans une de ces before functions.
Du coup tu ne créé et tu ne configures que les services dont tu as besoin.
Si tu veux que l'utilisateur fournisse du JSON, tu rajoutes une before function qui vérifie la validité de l'input et arrête la route en renvoyant une erreur 400 si ce n'est pas le cas.

Je sais que c'est pas très clair sans schéma, mais c'est vraiment simple à utiliser je trouve, et il n'y a pas de limite, tu peux ajouter autant de services que tu veux.

**Awake** · 30/01/2013, 17h01

Tu as refait Silex à ta sauce quoi ^^. C'est très bien et effectivement dans beaucoup de cas un microframework suffira pour les sites de petite/moyenne envergure. Par contre par rapport au temps d'apprentissage, je pensait plus à complet que complexe. Par exemple tu dis que les fichiers de configuration sont inutiles, mais c'est bien pratique pouvoir hériter de la configuration de prod pour lancer le site sur les serveurs de preprod en overriddant juste certains paramètres bien spécifiques par exemple, et de pas devoir avoir des fichiers .php différents pour les différents environnements (qu'il faudra faire super gaffe à pas écraser

).

Et c'est la même pour tous les composants, avec le module de console tu va pouvoir faire des barres de progression, mettre des couleurs ou appeler la commande directement via le code comme un service. Ce ne sont pas des fonctionnalités obligatoires mais bien pratiques, et qui rendent la doc, le nombre de lignes de code et l'apprentissage beaucoup plus longs.

Après symfony est loin d'être parfait hein, par exemple le système d'auth/security est un bordel sans nom qu'il vaux mieux réécrire en fonction des specs. Mais pour les projets de plus de 50k lignes de code, difficile de trouver mieux pour le moment ama.

**Tomaka17** · 30/01/2013, 17h10

Ben si tu veux j'ai des sortes de fichiers de configuration, mais ils contiennent simplement un tableau de fonction.

Par exemple un fichier environment.dev.php qui contient :

Code:

[
    include 'environment.common.php',
    function($debugPanelResponseFilter) { $debugPanelResponseFilter->enable(); },    // affiche un petit panneau de debuggage en bas de chaque page HTML
    function($cacheService) { $cacheService->disable(); },
    ...
]

Et un fichier environment.prod.php qui contient :

Code:

[
    include 'environment.common.php',
    function($serverCacheResponseFilter) { $serverCacheResponseFilter->setCacheDuration('2 hours'); },
    ...
]

Et sur chaque machine je mets un fichier environment.local.php ignoré par git et qui contient un include soit vers dev soit vers prod.

---------- Post added at 17h10 ---------- Previous post was at 17h07 ----------

Envoyé par hijopr

Mais pour les projets de plus de 50k lignes de code, difficile de trouver mieux pour le moment ama.

Evidemment je vois mal mon framework être utilisé un jour pour faire un gros site, mais je défends mon poulain

**MrBeaner** · 30/01/2013, 17h13

Je me perds un peu avec les identifiants (je les appelle comme ça, mais je sais pas si c'est vraiment pertinent).

id, name, class... C'est quoi la vraie différence ? J'ai cru comprendre que class c'est plutôt CSS, mais qu'on peut utiliser id (la syntaxe devient truc#id au lieu que truc.class). Pour name, je l'ai utilisé pour les form. Mais franchement, pourquoi je m'embêterais avec trois si un suffit (je penche pour id) ?

J'avais cru lire un article qui disait que name et id sont différents aussi.

**Anon26492** · 30/01/2013, 17h16

ID, Class, ce sont des selecteurs CSS.

Les ID sont uniques, les classes non.
Leur spécificité est différente.

Name sert surtout quand tu soumets un GET, la qs prend la forme &name=value

**Alliante** · 30/01/2013, 17h17

Envoyé par Tomaka17

Evidemment je vois mal mon framework être utilisé un jour pour faire un gros site, mais je défends mon poulain

Et le poulain il pourrait avoir une vraie doc pour voir si on peut lui faire courir Vincennes ?

Blague à part il faut des modules Apache particuliers ou un version de PHP spécifique ? Il ne me semble pas avoir vu de choses particulières sur Github.

**MrBeaner** · 30/01/2013, 17h20

Envoyé par Mdt

ID, Class, ce sont des selecteurs CSS.

Les ID sont uniques, les classes non.
Leur spécificité est différente.

Name sert surtout quand tu soumets un GET, la qs prend la forme &name=value

Okay, du coup name reste exclusif à HTML ? Et class et id peuvent si retrouver par contre ?

Ah ben okay, je comprends mieux la différence. Merci

En soi, je pourrais ne me contenter que de ces deux-là ?

**Anon26492** · 30/01/2013, 17h21

Name peut être utilisé comme selecteur via le selecteur d'attribut genre input[name='foo'], mais c'est moche niveau perf. (ce selecteur marche aussi pour les classes ou les ID hein, genre div[class='foo']. Tout aussi moche.)

En soi, les trois ont leur utilité, l'ID étant peut-être le moins utile (certains te diront de ne jamais utiliser d'ID, mais ils sont cons.)

**Tomaka17** · 30/01/2013, 17h23

Envoyé par Alliante

Blague à part il faut des modules Apache particuliers ou un version de PHP spécifique ? Il ne me semble pas avoir vu de choses particulières sur Github.

Pas de trucs spécifiques à part PHP 5.4
C'est un front controller donc il faut que tu rediriges toutes les requêtes (y compris les fichiers statiques si tu le souhaites) vers un seul script php.
Pour ça il faut mod_rewrite, ou alors que tu bidouilles en mettant ton index dans un répertoire vide et rediriger les erreurs 404 vers l'index.

Tout ce qu'il y a dans le readme fonctionne, c'est juste qu'entre temps j'ai changé quelques trucs. Par exemple cookiesService s'appelle cookiesContext maintenant. Tout ce qui dépend de la requête et de la réponse (cookies, session, authentification, etc.) j'ai appelé ça des contexts. Les services ce sont les trucs qui n'ont pas besoin de connaître de la requête ou la réponse (base de données, cache, xslt, etc.)
En interne les services, les filtres, les contexts, etc. tout est géré de la même façon. C'est juste une histoire de nom.

J'ai commencé à peupler ce truc, mais c'est encore assez vide.
Et puis les pages sur github utilisent jeckyll. Comme j'ai pas jeckyll je suis obligé de faire un commit et un push à chaque fois que je veux voir le résultat. Pour créer un design ça va être chiant.

**MrBeaner** · 30/01/2013, 17h27

Ah, je crois pas avoir abordé la sélection d'attributs. Mais je garde ça en tête, ça peut être utile. Pour celui qui apprend comme moi, l'info est là à ce propos :

https://developer.mozilla.org/en-US/...bute_selectors

Mais en soi, je pourrais laisser name de côté par défaut et lui préférer tantôt class, tantôt id.

**Tomaka17** · 30/01/2013, 17h29

Envoyé par MrBeaner

En soi, je pourrais ne me contenter que de ces deux-là ?

Name est indispensable pour les formulaires.
Par exemple sur ce forum l'encadré de texte dans lequel tu tapes ta réponse a un attribut name="message"
Du coup quand tu cliques sur "Envoyer la réponse", ça envoie ton message avec comme nom "message", et le serveur récupère ton message grâce à ce nom.

Mais si tu fais juste du CSS le name ne sert à rien.

**MrBeaner** · 30/01/2013, 17h34

Envoyé par Tomaka17

Name est indispensable pour les formulaires.
Par exemple sur ce forum l'encadré de texte dans lequel tu tapes ta réponse a un attribut name="message"
Du coup quand tu cliques sur "Envoyer la réponse", ça envoie ton message avec comme nom "message", et le serveur récupère ton message grâce à ce nom.

Mais si tu fais juste du CSS le name ne sert à rien.

Mais id et class marchent également pour form (en tout cas id, ça c'est sûr) ?

**tenshu** · 30/01/2013, 17h35

Vous pouvez utiliser [PHP][/PHP] pour pas qu'on se pète les yeux

**Awake** · 30/01/2013, 17h36

Le sélecteur par tagname est pratique aussi pour éviter de mettre des classes partout (#container span au lieu de #container .elements).

**tenshu** · 30/01/2013, 17h37

Envoyé par hijopr

Après symfony est loin d'être parfait hein, par exemple le système d'auth/security est un bordel sans nom qu'il vaux mieux réécrire en fonction des specs. Mais pour les projets de plus de 50k lignes de code, difficile de trouver mieux pour le moment ama.

Haha

c'était une blague récurrente quand j'étais encore dev sf "bon les gars j'ai tombé cette story super vite. Allez je finis le component security de sf".

**Anon26492** · 30/01/2013, 17h41

Envoyé par MrBeaner

Mais id et class marchent également pour form (en tout cas id, ça c'est sûr) ?

Si tu veux vraiment être peinard, tu gères tes form comme ça :

Code HTML:

<label for="nom">Votre Nom</label><input type="text" id="nom" name="nom" value="" required>
<label for="email">Votre email</label><input type="email" id="email" name="email" value="" required>

L'id te sert de selecteur CSS et fait le lien avec label for, ce qui est important pour l'accessibilité.
Le name te sert à traiter ton formulaire server-side.
Pour selectionner le label, tu as le choix entre label[for='email'] ou #nom+label (moins clair mais plus rapide et plus spécifique.)

**tenshu** · 30/01/2013, 17h45

Mdt tu connais un peu trop bien les sélecteurs CSS pour être quelqu'un de respectable

**Anon26492** · 30/01/2013, 17h46

Envoyé par tenshu

Mdt tu connais un peu trop bien les sélecteurs CSS pour être quelqu'un de respectable

Mes premiers sélecteurs CSS tournaient sous IE4

**Awake** · 30/01/2013, 17h48

Code:

<label for="nom">Votre Nom</label><input type="text" id="nom" name="nom" value="" required>

du coup

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

Outils de la discussion

Règles de messages