Discussion :

[Zebulon777]

Bonjour à tous,

Pour des raisons que je ne m'explique pas encore très bien, mais que je suppose être d'ordre budgétaire, nous utilisons Internet Explorer comme interpréteur de nos applications développées en HTML et Javascript.

Depuis plusieurs années, nous utilisons le FSO pour créer et manipuler des fichiers texte.
Ca fonctionne très bien, mais nous sommes "coincés" avec les ActiveX et donc avec Internet Exploer.
Il existe bien un module complémentaire pour les faire fonctionner sous Firefox (IETABPlus), mais ça ne nous satisfait pas.

Existe-il un autre moyen pour faire la même chose et fonctionnant avec le plus de navigateurs possibles, peut-être en JQuery, que je découvre depuis quelques jours, ou autre ?

En petit exemple du code utilisé, si jamais ça peut servir :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
WFichierMails = WActx_FSO.GetFolder(WCheminFicTXT).CreateTextFile(WNomFichierTXT);
WFichierMails.Writeline("### DEBUT;" + G_Version + " ###");
WFichierMails.WriteLine("### CONTENU:" + " ###" + G_CrLf + P_Contenu + G_CrLf);
WFichierMails.WriteLine("### FIN ###");
WFichierMails.close();

[SpaceFrog]

en gros le navigateur n'est pas fait pour avoir accès au système de fichier local ...
ce qui est plus que normal sur le plan de la sécurité
Pour développer des applications locales, les activeX étant propriétaires IE, je pense qu'il faudra limiter les utilisateurs à IE ...

[Bovino]

FileReader

[thelvin]

Hum, FileReader peut lire des fichiers s'ils ont été sélectionnés, mais il ne peut pas en écrire.
Il y aurait bien FileSystem API, mais géré seulement par webkit, déprécié, et qui n'écrit que dans un bac à sable réservé au domaine en cours. J'arrive même pas à aller chercher les fichiers qui s'y trouvent en dehors de JavaScript. (Autrement dit c'est utile que si vraiment on préfère un modèle fichier par rapport à localStorage.)

Quand j'ai des trucs de ce genre à faire par un navigateur, j'ai tendance à déléguer le stockage de fichier vers le serveur... Mais bon, pour ça il faut qu'il y ait un serveur avec un langage serveur. C'est souvent le cas quand on utilise un navigateur.

[sekaijin]

bonjours,

en fait IE au travers de certains activeX ouvre des gouffre beant dans la sécurité du poste.
c'est le cas avec FSO qui permet quasiment à n'importe qui d'écrire sur ton disque. et donc de te planter un cheval de troy ou autre cradware

M$ est le seul à avoir conservé cette possibilité. tous les autres acteurs considère qu'il est interdit dans une page web d'écrire sur le disque.

mais il arrive qu'on ait besoin de conserver quelques éléments sur le poste pour les réutiliser plus tard dans une page web.
pour cela il existe une vielle techno appelé cookie qui a fait ces preuves.
depuis html5 les localstorage offre une nouvelle possibilité plus évolué.

mais dans les deux cas il s'agit de stocker quelque chose dans l'espace utilisateur qui sera utilisé par le navigateur.

il ne s'agit pas comme avec FSO d'enregistrer un fichier sur le disque pour n'importe quel usage.
pour enregister sur le disque il y a le download

il faut considéré que la page dans le navigateur est un petit bout de l'application externe (sur le serveur) visible sur le poste client.
le navigateur fait de son mieux pour conserver cette étanchéitée.
un peu comme si tu avait un aquarum dans ton salon qui serait ouvert directement sur l'océan.
les poisons pouraient venir dans l'aquarum et repartir mais tu ne veux surtout pas que la vitre cède et inonde ton salon.
par contre tu apprécirais d'avoir un sas pour envoyer ou prélever quelque chose dans l'océan.

c'est ainsi que fonctionne normalement les navigateurs.

communément lorsque une page web produit localement des données et que celle-ci doivent être enregistrer sur le poste de l'utilisateur, on les envoie au serveur qui les retourne au client pour téléchargement.
on peut aussi utiliser les uri data: avec le mime type ad-hoc.

enfin reste une dernière possibilité qui consiste à revoir l'approche globale.

on peut avec des outils comme tideSDK packager une application web pour obtenir un exe.
lorsque on l'exécute (si on a correctement fixé les droit) on peut à la fois accéder au file system et au serveur web de l'appli.

cela ne pose pas de problème de sécurité vu que l'exé n'a pas accès à autre chose que l'appli et le poste local. pas de risque d'intrusion.

mais l'inconvénient est qu'il faut déployer l'exe sur les postes des utilisateurs.
A+JYT

[arnogues]

Si vous voulez à tout prix développer des applications desktop en utilisant HTML/CSS/Javascript, je vous recommande de vous tourner vers node-webkit dans ce cas.

Voici une petite vidéo de présentation faite par grafikart :

[thelvin]

Si vous voulez à tout prix développer des applications desktop en utilisant HTML/CSS/Javascript, je vous recommande de vous tourner vers node-webkit dans ce cas.

Je suis à peu près sûr qu'il n'y a aucun rapport. Il ne créera pas plus de fichiers, puisque c'est le navigateur qui ne le peut pas et que le serveur n'y changera rien.

Edit : et je me trompais