Journal : Cherche solutions aux formulaires électroniques multiplateformes
Posté par ohmer (page perso, ) le 07 avril 2008
Hello,
Depuis quelques semaines, je cherche une solution de remplacement pour nos formulaires électroniques utilisés à l'interne. Nous utilisons depuis plusieurs années MSO (surtout Excel et un peu Word avec quelques macros (très) basiques) pour développer nos formulaires.
Oui, je le sais, ce ne sont pas du tout des logiciels pour faire des formulaires, mais c'était une solution simple à mettre en place et qui marchait bien jusqu'à maintenant.
Notre parc informatique est devenu très hétérogène avec le temps avec des postes Mac, Windows et depuis quelques temps Linux a aussi fait son apparition chez quelques usagers. Il est donc important que la lecture (et le remplissage du form) soit possible sur ces 3 plateformes. Pour la création du formulaire, ce n'est pas très important même si ça serait souhaitable.
Premier problème avec notre solution actuelle, Microsoft a eu la bonne idée de supprimer le support VBA (qui était déjà très limité sur Mac) de MSO 2008. La cohabitation Windows/Mac qui fonctionnait bien jusqu'à maintenant est compromise avec ce changement. Garder tout le parc informatique Mac en MSO 2004 n'est pas une solution, car il souffre de gros problèmes de performances sur les Mac Intel.
Deuxième problème, MSO et OOo ne traite pas les champs de formulaire de la même façon (entre autre pour désigner les composants d'un groupe de boutons radio). Il est donc impossible de faire cohabier MSO et OOo, sans devoir faire 2 versions des formulaires.
Bref, il faut se tourner vers autre chose.
La première solution qui m'est venu en tête, c'est d'utiliser des documents PDF avec des champs éditables. Mais j'ai pas trouvé de logiciels simples à utiliser par un non-technicien. Je me suis perdu à quelques reprises sur le site de Adobe, mais j'ai tourné en rond plus qu'autre chose. J'ai essayé le support xform de OOo avec l'export PDF, mais ce n'est pas du tout concluant.
La seconde solution serait d'écrire une application Web et de stocker l'information dans une base de données. Le problème, c'est que ça prendrait un technicien à chaque fois pour designer un formulaire. Pas pratique.
Autres suggestions ou je suis condamné à tourner en rond éternellement ? ;)
Depuis quelques semaines, je cherche une solution de remplacement pour nos formulaires électroniques utilisés à l'interne. Nous utilisons depuis plusieurs années MSO (surtout Excel et un peu Word avec quelques macros (très) basiques) pour développer nos formulaires.
Oui, je le sais, ce ne sont pas du tout des logiciels pour faire des formulaires, mais c'était une solution simple à mettre en place et qui marchait bien jusqu'à maintenant.
Notre parc informatique est devenu très hétérogène avec le temps avec des postes Mac, Windows et depuis quelques temps Linux a aussi fait son apparition chez quelques usagers. Il est donc important que la lecture (et le remplissage du form) soit possible sur ces 3 plateformes. Pour la création du formulaire, ce n'est pas très important même si ça serait souhaitable.
Premier problème avec notre solution actuelle, Microsoft a eu la bonne idée de supprimer le support VBA (qui était déjà très limité sur Mac) de MSO 2008. La cohabitation Windows/Mac qui fonctionnait bien jusqu'à maintenant est compromise avec ce changement. Garder tout le parc informatique Mac en MSO 2004 n'est pas une solution, car il souffre de gros problèmes de performances sur les Mac Intel.
Deuxième problème, MSO et OOo ne traite pas les champs de formulaire de la même façon (entre autre pour désigner les composants d'un groupe de boutons radio). Il est donc impossible de faire cohabier MSO et OOo, sans devoir faire 2 versions des formulaires.
Bref, il faut se tourner vers autre chose.
La première solution qui m'est venu en tête, c'est d'utiliser des documents PDF avec des champs éditables. Mais j'ai pas trouvé de logiciels simples à utiliser par un non-technicien. Je me suis perdu à quelques reprises sur le site de Adobe, mais j'ai tourné en rond plus qu'autre chose. J'ai essayé le support xform de OOo avec l'export PDF, mais ce n'est pas du tout concluant.
La seconde solution serait d'écrire une application Web et de stocker l'information dans une base de données. Le problème, c'est que ça prendrait un technicien à chaque fois pour designer un formulaire. Pas pratique.
Autres suggestions ou je suis condamné à tourner en rond éternellement ? ;)
> Lire le journal (19 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #920680.
Run by 
Cette page a été générée par Templeet en 0.0433s (dont 0.004 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Plomino ?
Peut etre que Plomino conviendrait à ce que tu demandes ?
Demo (en Flash oncécépalibre) :
http://www.brehault.net/plomino/flashdemo
Il y a eu une news il y a peu :
https://linuxfr.org/2008/04/02/23927.html
Bon courage dans la recherche de solution...
[^]Re: Plomino ?
Ça semble intéressant.
C'est la première fois que j'installe une app Zope/Plone, donc pas trop évident au départ mais j'y suis arrivé.
J'ai cherché un semblant de communauté sur le site officiel (forums, ml...), je n'ai rien trouvé. Ça existe ?
D'après le num de téléphone, c'est une entreprise française qui semble être derrière ça, mais aussitôt que mon form contient un accent, ça plante lors de l'affichage de celui-ci... à moins que le problème soit du côté de Zope/Plone ? J'avoue que je n'en sais rien.
[^]Re: Plomino ?
Je me réponds à moi même. J'ai reçu le réponse à un mail envoyé au responsable du site. Pour ceux que ça intéresse, voici sa réponse :
c'est un problème habituel sous Plone
le plus simple est de mettre votre encodage par défault à utf-8
pour cela, aller dans
Plone-3.0.6/Python-2.4.4/lib/python2.4/site-packages
et créez un fichier nommé sitecustomize.py avec le code suivant:
import sys
sys.setdefaultencoding('utf-8')
et relancer zope