Pour l'instant les données sont hébergés sur un serveur kinto que jheberge et il faut me faire confiance.
Dans la futur je souhaite chiffrer les données avec une clé inconnue du serveur (https://github.com/Kinto/formbuilder/issues/89) ce qui permettra d'avoir moins besoin de faire confiance à l'hébergeur.
En attendant, un paragraphe descriptif de comment les données sont stockées et avec quelles garanties serait utile :)
Est-il possible de l'héberger facilement sur du Cloud Foundry ?
Je ne connais pas la plate-forme, donc je ne sais pas quoi te répondre. Je suppose que ça doit être faisable mais pour l'instant c'est du terrain inconnu !
As-tu prévu de proposer de saisir une date ou des plages horaires sur certaine dates pour organiser des events ?
C'est quelque chose qui est actuellement discuté et devrai être présent dans les futures versions.
Si tu parle des uiSchema qui sont attachés alors la réponse est non actuellement. Il me semble que certaines personnes sont en train e travailler sur le sujet, mais impossible de remettre la main sur un quelconque lien !
Non ce n'est pas nécessaire. D'ailleurs actuellement ce n'est pas le cas (le serveur kinto utilisé est hébergé ailleurs que les fichiers statiques). Cela est possible grâce à l'utilisation de CORS.
Deux points donc à discuter: le fait de définir les dépendances clairement (1) et le fait d'avoir des applications clientes en JavaScript pur dans le navigateur (2).
Effectivement j'aurais du l'indiquer dans la dépèche :-) Ceci dit, au niveau du serveur tu n'a pas besoin d'installer du node.js, tu peux simplement servir des fichiers statiques, ce qui permet de l'installer très facilement un peu partout. Node.js est utilisé pour développer et tu en aura besoin si tu souhaite contribuer au projet par contre.
J'ai personnellement foi (peut être à tort) dans un avenir ou les applications sont écrites pour des navigateurs qui exécutent du JavaScript.
La raison principale que j'y vois est les interfaces résultantes qui ont tendance à être plus faciles à appréhender par les utilisateurs (plus facile de faire de l'interaction avec les utilisateurs sur certains aspects).
Je vois bien sur des faiblesses associées à ce modèle, notamment pour les personnes qui ont noscript installées (ce qui est le cas par default dans TorBrowser par exemple). D'ailleurs, si on souhaite aller plus loin dans cette discussion, ce qui me dérange est principalement le fait que les applications Web ne sont pas signées et validées par quiconque avant de s'afficher aux utilisateurs, ce qui pose des soucis de sécurité dans un cas d'attaque MITM ou d'un serveur compromis.
Ce problème n'est malheureusement pas résolu sur le Web et se passer de JavaScript est un pansement: il faut s'attaquer au souci plutôt. En attendant, je préfère faire avec :)
Effectivement, c'est quelque chose qui peut-être très utile, mais ça ne fait pas partie du périmètre fonctionnel de la première version du projet.
Aussi, le modèle de données proposé par le backend est assez flexible pour ajouter des dépendances ou ce genre de choses, mais le frontend n'expose rien de tel pour l'instant. Comme on dit, on préfère faire des pas de bébé, y aller petit à petit pour avoir quelque chose qui réponds à un besoin specifique (avoir des formulaires simples, sans trop de règles de validation) dans un premier temps, auquel on ajoutera du sucre visuel et fonctionnel par la suite.
C'est effectivement ce qui est prévu (utilisation des champs HTML5 pour la validation + validation coté JS via Daybed.js). On en est pas encore là mais l'objectif est bel et bien défini.
Pour XForms on ne s'est pas encore posé la question mais ça pourrait avoir du sens effectivement. En tout cas pour l'instant on essaye de garder le périmètre fonctionnel simple donc c'est pas pour tout de suite :)
J'ai ajouté des bugs dans notre bug tracker quand ils n'étaient pas déjà entrés [0] et je viens de pousser un correctif qui devrait régler le souci des champ d'éditions qui sont visibles en mme temps (mais le code n'est pas encore déployé)
On avait pas vu pour le problème du required et quelques autres dont tu as fait part donc je viens d'ajouter des entrées dans le bugtracker [1].
[^] # Re: alternative à google form comme formbuilder ?
Posté par alexis.m . En réponse à la dépêche « Fourmilieres », un générateur de formulaires qui permet de reprendre la main sur vos données. Évalué à 1.
Il y a un lien vers le dépôt github en question dans la dépêche et sur la page d'accueil du site.
Pour la traduction, c'est un chantier en cours (il s'agit de la première version publiée) :)
[^] # Re: alternative à google form comme formbuilder ?
Posté par alexis.m . En réponse à la dépêche « Fourmilieres », un générateur de formulaires qui permet de reprendre la main sur vos données. Évalué à 1.
Oui c'est le même. Je l'appelle "Fourmilieres" parce-que je pense que c'est plus facile à retenir pour les francophones
[^] # Re: La présentation oublie des infos essentielles
Posté par alexis.m . En réponse à la dépêche « Fourmilieres », un générateur de formulaires qui permet de reprendre la main sur vos données. Évalué à 2.
Très bonne remarque. Il est prévu de pouvoir choisir le serveur de stockage depuis l'interface (cf https://github.com/Kinto/formbuilder/issues/20)
Pour l'instant les données sont hébergés sur un serveur kinto que jheberge et il faut me faire confiance.
Dans la futur je souhaite chiffrer les données avec une clé inconnue du serveur (https://github.com/Kinto/formbuilder/issues/89) ce qui permettra d'avoir moins besoin de faire confiance à l'hébergeur.
En attendant, un paragraphe descriptif de comment les données sont stockées et avec quelles garanties serait utile :)
Merci pour les retours !
[^] # Re: Super idée !!!!
Posté par alexis.m . En réponse à la dépêche « Fourmilieres », un générateur de formulaires qui permet de reprendre la main sur vos données. Évalué à 1.
Je ne connais pas la plate-forme, donc je ne sais pas quoi te répondre. Je suppose que ça doit être faisable mais pour l'instant c'est du terrain inconnu !
C'est quelque chose qui est actuellement discuté et devrai être présent dans les futures versions.
https://github.com/Kinto/formbuilder/issues/114
[^] # Re: json schema form
Posté par alexis.m . En réponse à la dépêche « Fourmilieres », un générateur de formulaires qui permet de reprendre la main sur vos données. Évalué à 1.
Si tu parle des uiSchema qui sont attachés alors la réponse est non actuellement. Il me semble que certaines personnes sont en train e travailler sur le sujet, mais impossible de remettre la main sur un quelconque lien !
[^] # Re: La présentation oublie des infos essentielles
Posté par alexis.m . En réponse à la dépêche « Fourmilieres », un générateur de formulaires qui permet de reprendre la main sur vos données. Évalué à 1.
"Et je rappelle que "Fourmilieres" a planté chez moi, même en activant le JavaScript."
Est ce que tu peux m'en dire plus ? Comment est ce que je peux reproduire le problème ? Merci !
[^] # Re: La présentation oublie des infos essentielles
Posté par alexis.m . En réponse à la dépêche « Fourmilieres », un générateur de formulaires qui permet de reprendre la main sur vos données. Évalué à 1.
Non ce n'est pas nécessaire. D'ailleurs actuellement ce n'est pas le cas (le serveur kinto utilisé est hébergé ailleurs que les fichiers statiques). Cela est possible grâce à l'utilisation de CORS.
[^] # Re: La présentation oublie des infos essentielles
Posté par alexis.m . En réponse à la dépêche « Fourmilieres », un générateur de formulaires qui permet de reprendre la main sur vos données. Évalué à 10.
Bonjour,
Deux points donc à discuter: le fait de définir les dépendances clairement (1) et le fait d'avoir des applications clientes en JavaScript pur dans le navigateur (2).
Effectivement j'aurais du l'indiquer dans la dépèche :-) Ceci dit, au niveau du serveur tu n'a pas besoin d'installer du node.js, tu peux simplement servir des fichiers statiques, ce qui permet de l'installer très facilement un peu partout. Node.js est utilisé pour développer et tu en aura besoin si tu souhaite contribuer au projet par contre.
J'ai personnellement foi (peut être à tort) dans un avenir ou les applications sont écrites pour des navigateurs qui exécutent du JavaScript.
La raison principale que j'y vois est les interfaces résultantes qui ont tendance à être plus faciles à appréhender par les utilisateurs (plus facile de faire de l'interaction avec les utilisateurs sur certains aspects).
Je vois bien sur des faiblesses associées à ce modèle, notamment pour les personnes qui ont noscript installées (ce qui est le cas par default dans TorBrowser par exemple). D'ailleurs, si on souhaite aller plus loin dans cette discussion, ce qui me dérange est principalement le fait que les applications Web ne sont pas signées et validées par quiconque avant de s'afficher aux utilisateurs, ce qui pose des soucis de sécurité dans un cas d'attaque MITM ou d'un serveur compromis.
J'avais d'ailleurs écrit quelque chose à ce sujet il y a quelques temps: https://blog.notmyidea.org/web-distribution-signing.html
Ce problème n'est malheureusement pas résolu sur le Web et se passer de JavaScript est un pansement: il faut s'attaquer au souci plutôt. En attendant, je préfère faire avec :)
[^] # Re: Framaforms ?
Posté par alexis.m . En réponse à la dépêche « Fourmilieres », un générateur de formulaires qui permet de reprendre la main sur vos données. Évalué à 4.
Très bonne idée: des discussions sont en cours (on ne connaît pas encore l'issue de celles ci par contre)
[^] # Re: Interface
Posté par alexis.m . En réponse au journal Un générateur de formulaire qui vise à remplacer google forms. Évalué à 3.
Effectivement, c'est quelque chose qui peut-être très utile, mais ça ne fait pas partie du périmètre fonctionnel de la première version du projet.
Aussi, le modèle de données proposé par le backend est assez flexible pour ajouter des dépendances ou ce genre de choses, mais le frontend n'expose rien de tel pour l'instant. Comme on dit, on préfère faire des pas de bébé, y aller petit à petit pour avoir quelque chose qui réponds à un besoin specifique (avoir des formulaires simples, sans trop de règles de validation) dans un premier temps, auquel on ajoutera du sucre visuel et fonctionnel par la suite.
[^] # Re: Types de champ
Posté par alexis.m . En réponse au journal Un générateur de formulaire qui vise à remplacer google forms. Évalué à 2.
Carrement !
C'est effectivement ce qui est prévu (utilisation des champs HTML5 pour la validation + validation coté JS via Daybed.js). On en est pas encore là mais l'objectif est bel et bien défini.
[^] # Re: Modèle de données pour les formulaires
Posté par alexis.m . En réponse au journal Un générateur de formulaire qui vise à remplacer google forms. Évalué à 1.
on n'utilise pas de base de données relationnelle en fait, c'est CouchDB ou Redis pour l'instant.
[^] # Re: Modèle de données pour les formulaires
Posté par alexis.m . En réponse au journal Un générateur de formulaire qui vise à remplacer google forms. Évalué à 2.
Pour l'instant on utilise un modèle custom, avec un travail en cours pour supporter json schema https://github.com/spiral-project/daybed/pull/195
Pour XForms on ne s'est pas encore posé la question mais ça pourrait avoir du sens effectivement. En tout cas pour l'instant on essaye de garder le périmètre fonctionnel simple donc c'est pas pour tout de suite :)
[^] # Re: Joli mais pas très intuitif
Posté par alexis.m . En réponse au journal Un générateur de formulaire qui vise à remplacer google forms. Évalué à 4.
Merci pour les retours, on va tenter d'améliorer l'interface !
[^] # Re: bugs
Posté par alexis.m . En réponse au journal Un générateur de formulaire qui vise à remplacer google forms. Évalué à 3.
J'ai ajouté des bugs dans notre bug tracker quand ils n'étaient pas déjà entrés [0] et je viens de pousser un correctif qui devrait régler le souci des champ d'éditions qui sont visibles en mme temps (mais le code n'est pas encore déployé)
On avait pas vu pour le problème du required et quelques autres dont tu as fait part donc je viens d'ajouter des entrées dans le bugtracker [1].
Merci pour les retours !
[0] https://github.com/spiral-project/formbuilder/issues
[1] https://github.com/spiral-project/formbuilder/issues/23, https://github.com/spiral-project/formbuilder/issues/24, https://github.com/spiral-project/formbuilder/issues/25