Le "S.O.C project" est un générateur de formulaires avec tous les nouveautés d'HTML5.
A quoi cela peut-il bien servir ?
A... (roulements de tambours)... générer des formulaires !
C'est donc encore un clone de PhpMyAdmin et consorts en moins bien...
Je vous arrête tout de suite, c'est un générateur de formulaires et uniquement cela, pas un gestionnaire de bases de données !
C'est tout ?
C'est déjà pas mal !
C'est pourtant pas difficile de créer un formulaire.
Je suis tout à fait d'accord, ce n'est pas DIFFICILE de créer UN formulaire.
Prenons pour exemple une de mes réalisations, à savoir une de mes boutiques en lignes, et observons les produits. Ils sont stockés dans une base de données, chaque produit peut être décrit selon 30 à 40 champs (poids, nom, quantité, etc...).
Si l'on fait une interface d'administration, il faut donc créer un formulaire de 30 à 40 champs, c'est à dire faire grosso modo 30 à 40 fois la même chose (et idem pour les requêtes SQL).
D'accord, je vois où vous voulez en venir ! Vous ne seriez pas un peu fainéant à tout hasard ?
D'un certain point de vue, oui, je suis un horrible fainéant, disons, que je préfère "bien travailler pour moins travailler". Imaginez qu'il faille faire 20 formulaires à 50 champs chacun.
Certes, ce n'est pas difficile, mais c'est pénible, car il faudra faire grosso modo (20*50=)1000 fois la même manipulation.
Et les requêtes SQL deviennent aussi très longues... sans compter les erreurs humaines (oubli d'un champ, faute de frappe, etc...), bref, cela devient proprement ingérable.
En effet, je comprends mieux. Cet utilitaire fait le "sale boulot", si j'ose m'exprimer ainsi ?
Tout à fait !
Pourquoi il y a toutes ces informations en plus du formulaire ?
Ces "informations" sont des pense-bêtes pour moi (notamment la connexion en ASP, difficile de retenir un charabia pareil...), de plus, le but est de générer aussi les requêtes en SQL, basées sur les champs du formulaire. (imaginez une requête d'update avec 50 champs, et vous comprendrez comme cela peut être pratique)
En quel langage est-ce fait ? Comment cela fonctionne-t-il ?
Le S.O.C project est créé en PHP. C'est assez simple : d'après le nombre de champs demandés, un formulaire est généré. Ensuite, d'après les choix effectués (select, textarea, etc...), le code est pondu à la volée. (si le "i-ème" champ demandé est un "select", alors on écrit le code du "select", etc...)
Mais pourquoi avoir créé cet utilitaire alors que d'autres existent sur le net et offrent beaucoup de possibilités ?
C'est là justement le problème : ils offrent à mon avis presque TROP de possibilités, et ne sont pas adaptés à mon besoin. Je n'ai pas besoin d'un grand niveau de complexité mais plutôt d'un traitement automatique de certaines tâches répétitives.
Super, moi qui suis débutant, je vais donc pouvoir créer de gros formulaires avec ?
Que cela soit clair, c'est avant tout un outil dont le but est de générer du code, destiné aux développeurs web et non à des personnes débutantes. Ce n'est pas un "Dreamweaver à formulaires".
Certes, cela fait quasiment 80% du boulot avec en plus pas mal d'indications, mais ça ne remplacera pas les connaissances...
Une minute, vous me parlez d'exemples à 50 champs, mais la version que j'ai essayée ne me permet que 25 champs ! Info ou intox ?
En effet, la version disponible sur le net est légèrement limitée, par contre, je peux vous certifier que la version "chez moi" n'est aucunement limitée, je peux traiter des formulaires de n'importe quelle taille. (2000 champs par exemple)
Je précise bien : c'est un utilitaire créé par moi-seul et dans l'unique but de m'aider. Si j'ai mis une démo sur le net, c'était juste pour avoir quelques retours et des idées d'internautes avisés.
Le code généré est-il valide ?
Oui et non.
La base du code généré est en XHTML bien valide, néanmoins, il vous faudra des connaissances pour en être sûr.
Par exemple, l'attribut "name" de la balise <form> est déprécié en XHTML Strict.
Si vous remplissez le champ name du formulaire, le S.O.C project ne va pas vous prévenir en vous disant "Attention, l'attribut que vous avez utilisé est déprécié en XHTML Strict !"... (il ne faut pas pousser non plus)
On va dire donc qu'il y a une très forte probabilité que le code soit valide.
A quoi sert cette option de stylage ?
Elle génère simplement une feuille de style (CSS), ce qui permet de donner un peu de "couleurs" au formulaires générés !
(si vous avez des styles de formulaires plaisants, n'hésitez pas à me les communiquer d'ailleurs)
Et les CSS sont valides ?
Bien sûr ! (si vous ne les rendez pas invalides en les modifiant vous-même)
A quoi servent les balises <thead> et consorts dans la mise en page par tableau centré ?
Ces éléments servent à améliorer l'accessibilité du tableau utilisé, pour plus de détails, allez faire un tour sur Openweb, ils ont écrit un article expliquant tout cela bien mieux que ce que je ne le ferai ici. (le lien vous emmène vers cet article)
Je ne comprends pas à quoi peut bien servir le 2ème formulaire ???
En fait, quand on fait une interface d'administration d'un site, il peut être utile de pouvoir modifier une nouvelle que l'on a ajouté (par exemple à cause d'une faute d'orthographe).
Ce 2ème formulaire est un début de réponse à ce besoin.
Ce 2ème formulaire est un début de réponse à ce besoin. C'est-à-dire ?
Et bien, les champs de type text, hidden et textarea sont déjà pris en compte dans ce formulaire. Faites un essai, vous comprendrez mieux !
A quoi servent ces options de protection ASP/PHP ?
Très simple, à protéger vos requêtes SQL (injections SQL) et à gérer les apostrophes magiques en PHP.
Cela ne change rien pour les champs de type select par exemple, il faut encore se taper le code. Pourquoi n'est-ce pas complet à ce niveau-là ?
Tout simplement par manque de temps !
En effet, le code ASP ou PHP manque, mais j'ai déjà pensé à une manière de l'implémenter...
Bref un peu de patience !
Hé une minute, j'ai essayé les requêtes SQL, et elles ne fonctionnent pas ! Comment cela se fait ?
Encore une fois, je le précise, le S.O.C project ne peut pas remplacer des connaissances de développeur.
Pourquoi je dis cela ? Tout simplement parce que les requêtes sont créées selon un certain "format" (pour des champs de type texte), et que ce format peut ne pas convenir à d'autres types de données.
Par exemple, une requête de suppression (DELETE FROM news WHERE id='" & sqlencode(id) & "';) générée pour fonctionner avec de l'ASP et une base de type Access peut tout à fait ne pas fonctionner si le champ est de type numérique, car les quotes devront être retirées.
C'est le même cas si on a un champ de type date dans une base Access, il faudra remplacer les quotes par des dièses.(#)
Encore une fois, ces requêtes sont mises à titre indicatif, et surtout pour ne pas avoir à écrire celle de sélections et de mises à jour, qui peuvent être très longues dans certains cas (par exemple 50 champs).
Pourra-t-on bientôt espérer une version non limitée sur le net ?
J'hésite encore, mais je pense que cela sera le cas quand ce projet sera pleinement fini.
Et il sera fini quand ?
Heu... quand il sera fini ? Comme je le développe à temps perdu, je suis incapable de donner une date précise.
Plus sérieusement, il manque encore quelque fonctionnalités importantes.
Lesquelles ?
Les 1ères idées qui me viennent à l'esprit sont :
La version 1.0 a amené de nouveaux attributs et types HTML5, et je compte bien suivre le développement de ce futur standard, si de nouveaux attributs ou types sont proposés, ils seront ajoutés/enlevés/adaptés. D'ailleurs, les prochaines mises à jour concerneront ces attributs.
Il n'y a pas d'aperçu des formulaires générés.
Le 2ème formulaire n'est pas encore opérationnel complètement.
Et cette liste est loin d'être exhaustive...
Le code source n'est-il pas effroyable pour ce genre de programme ?
Je ne sais pas ce que c'est un code "effroyable", mais par contre, je reconnais que la version 0.8 avait bien compliqué le code, j'ai donc dû le simplifier quelque peu, quitte à ce que ce soit légèrement plus lourd. (quelque octets supplémentaires n'ont jamais fait de mal à la compréhension...)
J'ai une idée pour compléter ce projet ! Où puis-je l'envoyer ?
Vous pouvez me l'envoyer ici : e-mail.
N'hésitez pas à me donner vos idées, je n'ai surtout pas la prétention de dire que j'ai pensé à tout pour ce projet, loin de là !
J'ai constaté un bug !
Vous pouvez me le signaler ici : e-mail.
N'hésitez pas à me prévenir, j'ai encore moins la prétention de dire que j'ai pondu quelque chose de parfait !
Ce projet est nul/inintéressant/mal conçu/j'ai fait mieux/(mettez ici la gueulante bien constructive que vous souhaitez) !
C'est votre droit le plus intime de penser cela, et vous pouvez même m'envoyer un mail pour pointer les faiblesses de manière constructive.
Toutefois, si c'est râler juste pour le bon plaisir de râler, vous avez également le droit :
de passer votre chemin,
de ne pas utiliser cet utilitaire,
de faire comme si il n'existait pas,
de faire mieux vous-même comme un grand !
Puis-je vous donner un coup de main pour le coder ?
Honnêtement, c'est très gentil, mais non.
C'est plus un amusement pour moi qu'autre chose, donc je préfère le faire moi-même.
Question subsidiaire : que signifie le sigle SOC ?
Ah, ça je le dévoilerai quand je l'aurai fini !
Sachez en tout cas que c'est un sigle récursif... et que c'est une blague en français !