[Intranet]téléchargement de fichier local

Version imprimable

06/06/2006, 22h04
Regis.C

[Intranet]téléchargement de fichier local

Bonjour à tous,

je suis en course sur un projet dont le langage n'est pas encore arretté.
Connaissant pas trop mal Java (j'ai développé plusieurs applis, mais aucune orientée web) je me demande si le langage serait adapté au cahier des charges :

Le client souhaite que l'appli soit sur l'intranet, et c'est ça qui me fait un peu peur...
En effet, l'appli devra
- Lire un fichier local de plusieurs kilos sur le poste des utilisateurs connectés
- Effectuer des calculs statistiques assez importants sur les données du fichier
- Rendre ses résultat dans un ou plusieurs fichiers sur le poste des utilisateurs à l'endroit de l'arborescence de leur choix.

Je pensais donc à une appli installée sur un serveur d'appli, avec une interface web entre l'appli et les users.

Mais :
1) Est-il simple (et possible) de lire un fichier sur le poste du user et de renvoyer un ou plusieurs fichiers sur le poste local ?
2) quel type d'interface entre l'appli et le user dois-je utiliser (applet, jsp, ?)
Et est ce bien l'architecture à mettre en place (une servlet principale peut-être ?)

Bref, tous les avis et surtout les experiences sont les bienvenues pour m'aider dans ma reflexion et mon questionnement.

Après une recherche sur le forum, j'entend également parler de JAva Web Start mais je ne connais pas...
Régis.
07/06/2006, 11h39
g_rare

Citation:

Envoyé par Regis.C

1) Est-il simple (et possible) de lire un fichier sur le poste du user et de renvoyer un ou plusieurs fichiers sur le poste local ?

En HTML : "<input type='file'/>" pour uploader un fichier du poste local !
En Java : une JSP de download avec le type (.txt, .csv ,...) de ton fichier en entête de la page HTML générée (l'ouverture avec l'éditeur de ta plateforme est gérée par le navigateur du client) !

Citation:

Envoyé par Regis.C

2) quel type d'interface entre l'appli et le user dois-je utiliser (applet, jsp, ?)
Et est ce bien l'architecture à mettre en place (une servlet principale peut-être ?)

Struts est pas mal comme approche MVC : une seule Servlet en point d'entrée, qui <<dispatche>> sur une JSP-cible en fonction de règles simples !

;)
07/06/2006, 11h46
bbclone

si tout doit se realiser sur le poste client, pourquoi une application web?
07/06/2006, 14h33
Regis.C

Citation:

Envoyé par bbclone

si tout doit se realiser sur le poste client, pourquoi une application web?

1) Pour que tous les utilisateurs puisse acceder à l'application sans pour autant devoir l'installer sur leur poste.
2) Pour maintenir une seule application sur le serveur plutot que 100 appli ou plus installées en local
3) Permettre l'utilisation de l'appli sur tous les sites de l'entreprise répartis en France
4) Pouvoir disposer de fichier de configuration inaccessible aux utilisateurs car situés sur le serveur
...
je continue ?:roll: :lol:
07/06/2006, 23h22
bbclone

tu peut continuer si tu veut... je vois toujour pas l'interet de l'application web.

une application swing deployer en Java Web Start devrait faire l'affaire.
non?
07/06/2006, 23h59
Regis.C

ET si tu prend le temps de relire mon post de départ tu pourras lire:

Citation:

Envoyé par Regis.C

...Bref, tous les avis et surtout les experiences sont les bienvenues pour m'aider dans ma reflexion et mon questionnement.

Après une recherche sur le forum, j'entend également parler de JAva Web Start mais je ne connais pas...
Régis.

Effectivement, il se peut qu'une appli standard lancée en JWS fasse l'affaire, c'était aussi le sens de la question : Quelle techno utiliser ?...

Mais merci quand même pour ton avis.

Régis. ;-)
08/06/2006, 10h37
adiGuba

Salut,

Java Web Start pourrait être une solution. En fait cela dépend de tes contraintes sur le poste client...
Pour rappel JWS est juste un système de déploiement d'applications Java.

Citation:

Envoyé par Regis.C

1) Pour que tous les utilisateurs puisse acceder à l'application sans pour autant devoir l'installer sur leur poste.

Avec JWS l'application est téléchargé automatiquement et mise à jours si neccessaire.
L'utilisateur n'a rien de plus à faire que de cliquer sur une URL... Et tu peux même créer une icone sur le bureau/menu pour lancer l'application plus simplement...

Citation:

Envoyé par Regis.C

2) Pour maintenir une seule application sur le serveur plutot que 100 appli ou plus installées en local

L'application est stocké sur un serveur Web et deployé automatiquement. Tu n'a donc qu'une seule application à maintenir (si ton appli reste bien portable et n'utilises pas de spécificité propre à un système).

Citation:

Envoyé par Regis.C

3) Permettre l'utilisation de l'appli sur tous les sites de l'entreprise répartis en France

Tous les sites qui auront accès au serveur Web auront accès à l'application...

Citation:

Envoyé par Regis.C

4) Pouvoir disposer de fichier de configuration inaccessible aux utilisateurs car situés sur le serveur

Le fichier de configuration peut très bien être dans le jar, et donc téléchargé avec le code...

La seule contrainte de JWS comparé à une application Web, c'est qu'il est neccessaire qu'un JRE récent (1.4 ou plus) soit installé sur tous les postes clients...
Il est possible d'utiliser un JRE 1.3 mais alors il faut installer JWS à part (il n'est inclus que depuis le 1.4).

Donc si tous les postes clients ont une JVM installé, ou qu'il est possible d'n installer, JWS peut être un bon choix : tu peux developper une application Swing et utiliser toutes l'API Java (en signant ton application pour obtenir les droits).

Mais si les postes clients ne possèdent pas de JVM et/ou ne peuvent pas en installer, alors une application Web reste le meilleur choix puisqu'un navigateur suffit amplement)...
08/06/2006, 14h17
g_rare

Citation:

Envoyé par adiGuba

Le fichier de configuration peut très bien être dans le jar, et donc téléchargé avec le code...

La question était plutôt : "pouvoir disposer de fichier de configuration INaccessible aux utilisateurs car situés sur le serveur" ! :aie:

Donc je ne sais pas (perso) ; la question reste en suspens.
;)
08/06/2006, 21h29
Regis.C

Citation:

Envoyé par g_rare

La question était plutôt : "pouvoir disposer de fichier de configuration INaccessible aux utilisateurs car situés sur le serveur" ! :aie:

Donc je ne sais pas (perso) ; la question reste en suspens.
;)

Merci g_rare, la question était effectivement bien celle-là.
En fait le public cible cherchera à modifier les paramètres (on connait les loustiques, ils l'ont déjà fait sur l'ancienne application développée en Fortran).
Le client souhaite donc une application où seul un administrateur pourra modifier les paramètres, et que les fichiers de paramètrage soient donc innaccessibles à l'utilisateur lambda.

Je ne sais pas s'il est possible d'interdire le lancement de l'appli hors-ligne (?), ça pourrait sans doute résoudre le problème puisque l'utilisateur est obligé d'utiliser la version lancée via la page web.
08/06/2006, 21h45
bbclone

avec jws tu peux interdire l'utilisation du mode offline.

pour les fiichier de config sils sont dans des jar et si tu obfusce tes jar je crois pas q'un user lambda va aller esayer de modifier des trucs dedans. (un fichier texte obfusquer ne change pas ;-) je sais mais t'immagine un user qui trouve que des fichier avec des noms bizzares dans le jar ca fait peur a un user lambda.

sinon tu peut toujour mettre tout tes parametre dans une interface
sans le code ca va etre difficile de modifier l'interface la recompiler et le remettre dans le jar.
08/06/2006, 23h15
adiGuba

Si tu empêches le mode hors-ligne et que le Jar en local ne correspond pas à celui sur le serveur, il devrait être totalement rechargé (à vérifier toutefois je n'en suis pas sûr à 100%). Il ne devrait pas y avoir de problème à utiliser un simple fichier à l'intérieur du Jar...

Si ce n'est pas le cas il suffit de charger un fichier depuis une URL sur le serveur...

a++
08/06/2006, 23h34
bbclone

> Si ce n'est pas le cas il suffit de charger un fichier depuis une URL sur le serveur...

tu pourait aussi downloader le fichier en local si tu y accede sur une simple url changer le fichier comme tu veut et le faire utiliser en changeant ton fichier host par exemple. le probleme est juste deplacer ;-)

pour le jar qui est pas de la meme version que sur le serveur, c'est le principe de jws. un jar est recharger quand la date est differente de celle de la version sur le server.

le mode offline est utiliser pour les applications qui n'ont pas besoin de reseau.
tu telecharge une fois l'application sur un portable par exemple et tu veux l'utiliser dans le metro sur la route...
la si ya pas de reseau il lance quand meme l'application avec la version que tu as utiliser la derniere fois.
si il ya du reseau il verifie quand meme que la version n'est pas a jour et telecharge la mise a jour si il doit.

je sais pas si je suis clair la :aie:
08/06/2006, 23h52
adiGuba

Citation:

Envoyé par bbclone

tu pourait aussi downloader le fichier en local si tu y accede sur une simple url changer le fichier comme tu veut et le faire utiliser en changeant ton fichier host par exemple. le probleme est juste deplacer ;-)

Dans ce cas, si le mode offline n'est pas autorisé, JWS n'arriverait pas à lancer l'appli car il ne se connectera pas au serveur :aie:

Ensuite il faudrait que l'utilisateur s'installe un serveur web en local... on est loin de la simple manipulation de fichier...

Si c'est vraiment le cas, on peut carrément utiliser une Servlet sur le serveur qui enverra un fichier *.class sérializé...

a++
09/06/2006, 00h56
Regis.C

Citation:

Envoyé par adiGuba

Dans ce cas, si le mode offline n'est pas autorisé, JWS n'arriverait pas à lancer l'appli car il ne se connectera pas au serveur :aie:

Alors jws est pour moi !:mrgreen:
Bon, pemière étape passée.
2ème étape, faire un jar de l'appli, la liée avec une page html et un fichier jnlp => étape passée ce soir.
Lancement en local =>déclenchement de JWS, mais l'appli n'est pas sur le serveur donc echec (normal).

J'ai donc essayé de poser mes fichiers (et une appli de test) sur mon espace perso (donc un serveur) et là patatra : ça ne marche pas du tout :

http://fxgroup.club.fr/jws/index.html

En cliquant sur le lien, on tombe sur le jnlp (que j'ai recopié sur un exemple de développez...).
Pourquoi cela ne fonctionne pas ?
Une piste ?
09/06/2006, 10h13
adiGuba

Citation:

Envoyé par Regis.C

En cliquant sur le lien, on tombe sur le jnlp (que j'ai recopié sur un exemple de développez...).
Pourquoi cela ne fonctionne pas ?
Une piste ?

Le fichier est servit avec un content-type "text/plain". Or les navigateurs se base sur le content-type pour savoir quoi faire du fichier, et dans ce cas comme il s'agit de texte il sera affiché dans transformation quelquonque...

Il faut donc que tu modifies ton serveur web pour qu'il associe l'extension jnlp avec le content type application/x-java-jnlp-file qui devrait proposer l'ouverture avec JWS...

Si tu ne peux pas modifier la config du serveur Web, tu peux également utiliser du PHP/JSP/ASP pour spécifier le content-type. Par exemple en JSP il te suffit d'ajouter au début du fichier le code suivant :

Code:

<%@ page contentType="application/x-java-jnlp-file" %>

a++
09/06/2006, 14h38
Regis.C

Citation:

Envoyé par adiGuba

Par exemple en JSP il te suffit d'ajouter au début du fichier le code suivant :

Code:

<%@ page contentType="application/x-java-jnlp-file" %>

a++

Je peux ajouter cette ligne directement dans mon fichier jnlp, html ?
09/06/2006, 15h15
adiGuba

Citation:

Envoyé par Regis.C

Je peux ajouter cette ligne directement dans mon fichier jnlp, html ?

Non tu l'ajoutes dans un fichier JSP

Il te faut bien sur un serveur J2EE. Si ce n'est pas le cas, quel type de langages coté server tu peux utiliser ???

a++
09/06/2006, 20h16
Regis.C

En fait je souhaitais simplement tester une appli en jws sur le serveur de mon FAI, mais apparement le serveur en question n'est pas configuré...
On va dire que je testerai "en live" lorsque je serai dans le projet.

Merci à tous pour les infos en tout cas.

Régis. ;-)
09/06/2006, 21h29
bbclone

> Dans ce cas, si le mode offline n'est pas autorisé, JWS n'arriverait pas à lancer l'appli car il ne se connectera pas au serveur

sauf si tu lui fait croire qu'il doit se connecter a un autre serveur dans lequel tu as un peu chipoter pour lui mettre les bon fichier dans les bon dossier.
je l'ai deja fait pour demontrer des faille de jws ;-)

sinon installer un serveur web est vraiment tres simple comme operation.
je travaille sur linux et avec apt-get je l'ai dans les 5 sec
et je crois que sous WinXp tu as un choix dans le panneau de config pour installer IIS je crois?

mais ta raison c'est plus le user lambda qui va faire ce genre de manip :-)
09/06/2006, 22h00
Regis.C

Citation:

Envoyé par bbclone

> Dans ce cas, si le mode offline n'est pas autorisé, JWS n'arriverait pas à lancer l'appli car il ne se connectera pas au serveur

sauf si tu lui fait croire qu'il doit se connecter a un autre serveur dans lequel tu as un peu chipoter pour lui mettre les bon fichier dans les bon dossier.
je l'ai deja fait pour demontrer des faille de jws ;-)

sinon installer un serveur web est vraiment tres simple comme operation.
je travaille sur linux et avec apt-get je l'ai dans les 5 sec
et je crois que sous WinXp tu as un choix dans le panneau de config pour installer IIS je crois?

mais ta raison c'est plus le user lambda qui va faire ce genre de manip :-)

On va dire que les élements à rassembler pour contourner le soft et aller modifier les paramètres sont un peu plus complexes qu'ils ne l'étaient avec l'ancienne appli (qui date d'une trentaine d'année).
Je pense qu'en utilisant JWS avec le mode off-line non-autorisé, les petits malins ont de quoi se calmer et ils n'essayeront même pas forcément de savoir quelle techno (JWS) est utilisée.