Je vais commencer à développer une application de gestion de base de
données (pour résumer).
J'hésite entre coder une véritable interface graphique (Swing + JSQL) ou bien
développer un modèle type tomcat + hibernate.
L'outil devra être déployé sur de nombreuses machines et différents OS,
et j'ai peur que la deuxième solution ne soit trop compliquée à
déployer, surtout pour des personnes non qualifiées.
véritable interface graphique (Swing + JSQL) ou bien développer un modèle type tomcat + hibernate.
Je ne vois pas ce qu'il y a à déployer en architecture client léger.
"architecture client léger" c'est une "page ouèbe" en langage non-consultant, non ?
il n'a pas été indiqué que le "soft client" devait vivre dans un navigateur.
Sylvain.
David
Le Thu, 08 Jun 2006 02:06:46 +0200, Sylvain a écrit :
"architecture client léger" c'est une "page ouèbe" en langage non-consultant, non ?
il n'a pas été indiqué que le "soft client" devait vivre dans un navigateur.
Si tu fais du tomcat, que veux tu faire d'autre ? Du XUL, une applet ? On est toujours dans un navigateur. Si après tu exposes des WebServices, tu peux mettre une interface lourde sur le poste client mais ça n'a aucun intérêt.
Donc je répète ma question : où est la problématique de déploiement avec tomcat ?
Le Thu, 08 Jun 2006 02:06:46 +0200, Sylvain a écrit :
"architecture client léger" c'est une "page ouèbe" en langage
non-consultant, non ?
il n'a pas été indiqué que le "soft client" devait vivre dans un
navigateur.
Si tu fais du tomcat, que veux tu faire d'autre ? Du XUL, une applet ? On
est toujours dans un navigateur. Si après tu exposes des WebServices, tu
peux mettre une interface lourde sur le poste client mais ça n'a aucun
intérêt.
Donc je répète ma question : où est la problématique de déploiement
avec tomcat ?
Le Thu, 08 Jun 2006 02:06:46 +0200, Sylvain a écrit :
"architecture client léger" c'est une "page ouèbe" en langage non-consultant, non ?
il n'a pas été indiqué que le "soft client" devait vivre dans un navigateur.
Si tu fais du tomcat, que veux tu faire d'autre ? Du XUL, une applet ? On est toujours dans un navigateur. Si après tu exposes des WebServices, tu peux mettre une interface lourde sur le poste client mais ça n'a aucun intérêt.
Donc je répète ma question : où est la problématique de déploiement avec tomcat ?
Christophe
David wrote:
"architecture client léger" c'est une "page ouèbe" en langage non-consultant, non ?
il n'a pas été indiqué que le "soft client" devait vivre dans un navigateur.
Si tu fais du tomcat, que veux tu faire d'autre ? Du XUL, une applet ? On est toujours dans un navigateur. Si après tu exposes des WebServices, tu peux mettre une interface lourde sur le poste client mais ça n'a aucun intérêt.
Donc je répète ma question : où est la problématique de déploiement avec tomcat ?
Simplement dans le déploiement de l'application ET de Tomcat. Même un application "serveur" doit être déployée au moins 1 fois sur un serveur. Si on vend cette application à plusieurs clients, il faut la déployer chez chaque client. Le plus compliqué étant les clients qui ont déjà un "serveur" (si si le poste de la secrétaire, il sert pas beaucoup, on peut en faire un serveur, pour pas réinvestir...), les autres on leur propose un serveur de notre cru, donc qu'on maitrise bien. Evidemment, là c'est plutôt pour les TPE-PME.
Pour répondre à la question, le déploiement d'une application "tomcat" est quand même bien plus simple puisqu'il n'y a qu'une seule installation à faire sur un serveur. Ensuite les utilisateurs utiliseront leur navigateur préféré. Et les mises à jour se limite à un déploiement sur le serveur tomcat, faut pas repasser sur tous les postes du client (Webstart aide un peu quand même).
La problèmatique étant de se "limiter" à des pages webs dont on ne maitrise pas toujours tout les composants (qu'il faut apprendre (html, css, javascript, et surtout les différences de comportement entre navigateur) , et qui limite les interactions avec le poste de l'utilisateur (pas d'accès à son disque , peut pas y mettre des fichiers, etc..).
Bref c'est une autre philosophie de developpement, et aussi d'utilisation. ça dépend des compétences des programmeurs et de ce que doit faire l'application.
David wrote:
"architecture client léger" c'est une "page ouèbe" en langage
non-consultant, non ?
il n'a pas été indiqué que le "soft client" devait vivre dans un
navigateur.
Si tu fais du tomcat, que veux tu faire d'autre ? Du XUL, une applet ? On
est toujours dans un navigateur. Si après tu exposes des WebServices, tu
peux mettre une interface lourde sur le poste client mais ça n'a aucun
intérêt.
Donc je répète ma question : où est la problématique de déploiement
avec tomcat ?
Simplement dans le déploiement de l'application ET de Tomcat.
Même un application "serveur" doit être déployée au moins 1 fois sur un
serveur. Si on vend cette application à plusieurs clients, il faut la
déployer chez chaque client. Le plus compliqué étant les clients qui ont
déjà un "serveur" (si si le poste de la secrétaire, il sert pas
beaucoup, on peut en faire un serveur, pour pas réinvestir...), les
autres on leur propose un serveur de notre cru, donc qu'on maitrise
bien. Evidemment, là c'est plutôt pour les TPE-PME.
Pour répondre à la question, le déploiement d'une application "tomcat"
est quand même bien plus simple puisqu'il n'y a qu'une seule
installation à faire sur un serveur. Ensuite les utilisateurs
utiliseront leur navigateur préféré. Et les mises à jour se limite à un
déploiement sur le serveur tomcat, faut pas repasser sur tous les postes
du client (Webstart aide un peu quand même).
La problèmatique étant de se "limiter" à des pages webs dont on ne
maitrise pas toujours tout les composants (qu'il faut apprendre (html,
css, javascript, et surtout les différences de comportement entre
navigateur) , et qui limite les interactions avec le poste de
l'utilisateur (pas d'accès à son disque , peut pas y mettre des
fichiers, etc..).
Bref c'est une autre philosophie de developpement, et aussi
d'utilisation. ça dépend des compétences des programmeurs et de ce que
doit faire l'application.
"architecture client léger" c'est une "page ouèbe" en langage non-consultant, non ?
il n'a pas été indiqué que le "soft client" devait vivre dans un navigateur.
Si tu fais du tomcat, que veux tu faire d'autre ? Du XUL, une applet ? On est toujours dans un navigateur. Si après tu exposes des WebServices, tu peux mettre une interface lourde sur le poste client mais ça n'a aucun intérêt.
Donc je répète ma question : où est la problématique de déploiement avec tomcat ?
Simplement dans le déploiement de l'application ET de Tomcat. Même un application "serveur" doit être déployée au moins 1 fois sur un serveur. Si on vend cette application à plusieurs clients, il faut la déployer chez chaque client. Le plus compliqué étant les clients qui ont déjà un "serveur" (si si le poste de la secrétaire, il sert pas beaucoup, on peut en faire un serveur, pour pas réinvestir...), les autres on leur propose un serveur de notre cru, donc qu'on maitrise bien. Evidemment, là c'est plutôt pour les TPE-PME.
Pour répondre à la question, le déploiement d'une application "tomcat" est quand même bien plus simple puisqu'il n'y a qu'une seule installation à faire sur un serveur. Ensuite les utilisateurs utiliseront leur navigateur préféré. Et les mises à jour se limite à un déploiement sur le serveur tomcat, faut pas repasser sur tous les postes du client (Webstart aide un peu quand même).
La problèmatique étant de se "limiter" à des pages webs dont on ne maitrise pas toujours tout les composants (qu'il faut apprendre (html, css, javascript, et surtout les différences de comportement entre navigateur) , et qui limite les interactions avec le poste de l'utilisateur (pas d'accès à son disque , peut pas y mettre des fichiers, etc..).
Bref c'est une autre philosophie de developpement, et aussi d'utilisation. ça dépend des compétences des programmeurs et de ce que doit faire l'application.
thomas_escolan
As-tu songé à Java WebStart ? Un client lourd accessible (et automatiquement déployé) depuis une adresse web.
Bonne continuation, Thomas.
As-tu songé à Java WebStart ? Un client lourd accessible (et
automatiquement déployé) depuis une adresse web.
As-tu songé à Java WebStart ? Un client lourd accessible (et automatiquement déployé) depuis une adresse web.
Bonne continuation, Thomas.
TestMan
Bonjour,
Je vais commencer à développer une application de gestion de base de données (pour résumer).
J'hésite entre coder une véritable interface graphique (Swing + JSQL) ou bien développer un modèle type tomcat + hibernate.
L'outil devra être déployé sur de nombreuses machines et différents OS, et j'ai peur que la deuxième solution ne soit trop compliquée à déployer, surtout pour des personnes non qualifiées.
Qu'en pensez-vous ?
Bonjour,
Pas facile de répondre. Combien de clients auras-tu ? Combien de base de données différentes tu cibles ? Quelles sont les capacités du réseau entre les postes clients et les bases ? Quelles est la configuration type, min et max des machines clients ? ...
Pleins de bonnes questions dont les réponses vont nous éclairer sur les voies possible.
A+ TM
Bonjour,
Je vais commencer à développer une application de gestion de base de
données (pour résumer).
J'hésite entre coder une véritable interface graphique (Swing + JSQL) ou bien
développer un modèle type tomcat + hibernate.
L'outil devra être déployé sur de nombreuses machines et différents OS,
et j'ai peur que la deuxième solution ne soit trop compliquée à
déployer, surtout pour des personnes non qualifiées.
Qu'en pensez-vous ?
Bonjour,
Pas facile de répondre.
Combien de clients auras-tu ? Combien de base de données différentes tu
cibles ? Quelles sont les capacités du réseau entre les postes clients
et les bases ? Quelles est la configuration type, min et max des
machines clients ? ...
Pleins de bonnes questions dont les réponses vont nous éclairer sur les
voies possible.
Je vais commencer à développer une application de gestion de base de données (pour résumer).
J'hésite entre coder une véritable interface graphique (Swing + JSQL) ou bien développer un modèle type tomcat + hibernate.
L'outil devra être déployé sur de nombreuses machines et différents OS, et j'ai peur que la deuxième solution ne soit trop compliquée à déployer, surtout pour des personnes non qualifiées.
Qu'en pensez-vous ?
Bonjour,
Pas facile de répondre. Combien de clients auras-tu ? Combien de base de données différentes tu cibles ? Quelles sont les capacités du réseau entre les postes clients et les bases ? Quelles est la configuration type, min et max des machines clients ? ...
Pleins de bonnes questions dont les réponses vont nous éclairer sur les voies possible.
A+ TM
Pierre-Alexandre Meyer
Bonjour,
Bonjour,
Pas facile de répondre. Combien de clients auras-tu ? Combien de base de données différentes tu cibles ? Quelles sont les capacités du réseau entre les postes clients et les bases ? Quelles est la configuration type, min et max des machines clients ? ...
En réalité, la difficulté de l'affaire, c'est que tout dépendra de la situation dans laquelle ce logiciel sera installé. Et ces situations sont très diverses !
Non seulement il devra faire office de client -- serveur dans des petits réseaux internes (a priori 3/4 machines tout au plus), mais devra aussi pouvoir être déployé sur une seule machine (bases+logiciel).
La configuration des machines est très variable, il s'agit généralement de PC de bureaux classiques, que l'on trouve actuellement dans le commerce.
Pleins de bonnes questions dont les réponses vont nous éclairer sur les voies possible.
Merci !
-- Pam
Bonjour,
Bonjour,
Pas facile de répondre.
Combien de clients auras-tu ? Combien de base de données différentes tu
cibles ? Quelles sont les capacités du réseau entre les postes clients
et les bases ? Quelles est la configuration type, min et max des
machines clients ? ...
En réalité, la difficulté de l'affaire, c'est que tout dépendra de la
situation dans laquelle ce logiciel sera installé. Et ces situations
sont très diverses !
Non seulement il devra faire office de client -- serveur dans des
petits réseaux internes (a priori 3/4 machines tout au plus), mais devra aussi
pouvoir être déployé sur une seule machine (bases+logiciel).
La configuration des machines est très variable, il s'agit généralement
de PC de bureaux classiques, que l'on trouve actuellement dans le
commerce.
Pleins de bonnes questions dont les réponses vont nous éclairer sur les
voies possible.
Pas facile de répondre. Combien de clients auras-tu ? Combien de base de données différentes tu cibles ? Quelles sont les capacités du réseau entre les postes clients et les bases ? Quelles est la configuration type, min et max des machines clients ? ...
En réalité, la difficulté de l'affaire, c'est que tout dépendra de la situation dans laquelle ce logiciel sera installé. Et ces situations sont très diverses !
Non seulement il devra faire office de client -- serveur dans des petits réseaux internes (a priori 3/4 machines tout au plus), mais devra aussi pouvoir être déployé sur une seule machine (bases+logiciel).
La configuration des machines est très variable, il s'agit généralement de PC de bureaux classiques, que l'on trouve actuellement dans le commerce.
Pleins de bonnes questions dont les réponses vont nous éclairer sur les voies possible.
Merci !
-- Pam
Pierre-Alexandre Meyer
Simplement dans le déploiement de l'application ET de Tomcat. Même un application "serveur" doit être déployée au moins 1 fois sur un serveur. Si on vend cette application à plusieurs clients, il faut la déployer chez chaque client. Le plus compliqué étant les clients qui ont déjà un "serveur" (si si le poste de la secrétaire, il sert pas beaucoup, on peut en faire un serveur, pour pas réinvestir...), les autres on leur propose un serveur de notre cru, donc qu'on maitrise bien. Evidemment, là c'est plutôt pour les TPE-PME.
Voilà exactement le problème.
Pour répondre à la question, le déploiement d'une application "tomcat" est quand même bien plus simple puisqu'il n'y a qu'une seule installation à faire sur un serveur. Ensuite les utilisateurs utiliseront leur navigateur préféré. Et les mises à jour se limite à un déploiement sur le serveur tomcat, faut pas repasser sur tous les postes du client (Webstart aide un peu quand même).
Comme je l'ai posté plus haut, le logiciel devra aussi être déployé dans le cas de très petites entreprises (cas de la secrétaire qui, cette année, a enfin reçu un ordinateur !). Ne serait-ce pas compliqué dans ce genre de cas, que de déployer un tomcat ?
-- Pam
Simplement dans le déploiement de l'application ET de Tomcat.
Même un application "serveur" doit être déployée au moins 1 fois sur un
serveur. Si on vend cette application à plusieurs clients, il faut la
déployer chez chaque client. Le plus compliqué étant les clients qui ont
déjà un "serveur" (si si le poste de la secrétaire, il sert pas
beaucoup, on peut en faire un serveur, pour pas réinvestir...), les
autres on leur propose un serveur de notre cru, donc qu'on maitrise
bien. Evidemment, là c'est plutôt pour les TPE-PME.
Voilà exactement le problème.
Pour répondre à la question, le déploiement d'une application "tomcat"
est quand même bien plus simple puisqu'il n'y a qu'une seule
installation à faire sur un serveur. Ensuite les utilisateurs
utiliseront leur navigateur préféré. Et les mises à jour se limite à un
déploiement sur le serveur tomcat, faut pas repasser sur tous les postes
du client (Webstart aide un peu quand même).
Comme je l'ai posté plus haut, le logiciel devra aussi être déployé dans
le cas de très petites entreprises (cas de la secrétaire qui, cette
année, a enfin reçu un ordinateur !). Ne serait-ce pas compliqué dans
ce genre de cas, que de déployer un tomcat ?
Simplement dans le déploiement de l'application ET de Tomcat. Même un application "serveur" doit être déployée au moins 1 fois sur un serveur. Si on vend cette application à plusieurs clients, il faut la déployer chez chaque client. Le plus compliqué étant les clients qui ont déjà un "serveur" (si si le poste de la secrétaire, il sert pas beaucoup, on peut en faire un serveur, pour pas réinvestir...), les autres on leur propose un serveur de notre cru, donc qu'on maitrise bien. Evidemment, là c'est plutôt pour les TPE-PME.
Voilà exactement le problème.
Pour répondre à la question, le déploiement d'une application "tomcat" est quand même bien plus simple puisqu'il n'y a qu'une seule installation à faire sur un serveur. Ensuite les utilisateurs utiliseront leur navigateur préféré. Et les mises à jour se limite à un déploiement sur le serveur tomcat, faut pas repasser sur tous les postes du client (Webstart aide un peu quand même).
Comme je l'ai posté plus haut, le logiciel devra aussi être déployé dans le cas de très petites entreprises (cas de la secrétaire qui, cette année, a enfin reçu un ordinateur !). Ne serait-ce pas compliqué dans ce genre de cas, que de déployer un tomcat ?
-- Pam
Hervé AGNOUX
Pierre-Alexandre Meyer wrote:
Bonjour,
Je vais commencer à développer une application de gestion de base de données (pour résumer).
J'hésite entre coder une véritable interface graphique (Swing + JSQL) ou bien développer un modèle type tomcat + hibernate.
L'outil devra être déployé sur de nombreuses machines et différents OS, et j'ai peur que la deuxième solution ne soit trop compliquée à déployer, surtout pour des personnes non qualifiées.
Pour moi la balance devrait pencher assez fortement vers une application swing.
N'en déplaise aux spécialistes habituels, les systèmes à base de web n'apporte que des problèmes, problèmes qui se justifient parfaitement lorsqu'on est sur... le web, mais dont je ne vois absolument pas ce qu'ils apportent lorsqu'on est dans un contexte plus local.
Avec le web il faut gérer le HTML, le CSS, le javascript ; les problèmes d'installation ne sont résolus que si l'on veut bien considérer qu'il y a un navigateur "normal" sur le poste client, auquel cas il faut gérer les cas de navigateur "spéciaux" qui ne manquent pas de se manifester à la surprise générale ; si, en plus, il faut prévoir une install automatique de la partie serveur sur la partie client...
Au contraire, avec java web start, les installations java se présentent facilement, que ce soit par le web ou par CD. L'installation d'une machine virtuelle peut se faire par une secrétaire. Les problèmes de portabilité sont quasi-inexistants. Si la base de données est distante, il suffit souvent de changer l'url du driver jdbc. Si jamais on veut du http pour un protocole d'échange de fichiers, on peut utiliser jetty. Si une sécurité plus forte est nécessaire, on peut utiliser le SSL, que le java standard gère très bien, et tous les systèmes de cryptographie, casse tête total en milieu web.
Donc swing me paraît largement la meilleure solution.
-- Hervé AGNOUX http://www.diaam-informatique.com
Pierre-Alexandre Meyer wrote:
Bonjour,
Je vais commencer à développer une application de gestion de base de
données (pour résumer).
J'hésite entre coder une véritable interface graphique (Swing + JSQL) ou
bien développer un modèle type tomcat + hibernate.
L'outil devra être déployé sur de nombreuses machines et différents OS,
et j'ai peur que la deuxième solution ne soit trop compliquée à
déployer, surtout pour des personnes non qualifiées.
Pour moi la balance devrait pencher assez fortement vers une application
swing.
N'en déplaise aux spécialistes habituels, les systèmes à base de web
n'apporte que des problèmes, problèmes qui se justifient parfaitement
lorsqu'on est sur... le web, mais dont je ne vois absolument pas ce qu'ils
apportent lorsqu'on est dans un contexte plus local.
Avec le web il faut gérer le HTML, le CSS, le javascript ; les problèmes
d'installation ne sont résolus que si l'on veut bien considérer qu'il y a
un navigateur "normal" sur le poste client, auquel cas il faut gérer les
cas de navigateur "spéciaux" qui ne manquent pas de se manifester à la
surprise générale ; si, en plus, il faut prévoir une install automatique de
la partie serveur sur la partie client...
Au contraire, avec java web start, les installations java se présentent
facilement, que ce soit par le web ou par CD. L'installation d'une machine
virtuelle peut se faire par une secrétaire. Les problèmes de portabilité
sont quasi-inexistants. Si la base de données est distante, il suffit
souvent de changer l'url du driver jdbc. Si jamais on veut du http pour un
protocole d'échange de fichiers, on peut utiliser jetty. Si une sécurité
plus forte est nécessaire, on peut utiliser le SSL, que le java standard
gère très bien, et tous les systèmes de cryptographie, casse tête total en
milieu web.
Donc swing me paraît largement la meilleure solution.
Je vais commencer à développer une application de gestion de base de données (pour résumer).
J'hésite entre coder une véritable interface graphique (Swing + JSQL) ou bien développer un modèle type tomcat + hibernate.
L'outil devra être déployé sur de nombreuses machines et différents OS, et j'ai peur que la deuxième solution ne soit trop compliquée à déployer, surtout pour des personnes non qualifiées.
Pour moi la balance devrait pencher assez fortement vers une application swing.
N'en déplaise aux spécialistes habituels, les systèmes à base de web n'apporte que des problèmes, problèmes qui se justifient parfaitement lorsqu'on est sur... le web, mais dont je ne vois absolument pas ce qu'ils apportent lorsqu'on est dans un contexte plus local.
Avec le web il faut gérer le HTML, le CSS, le javascript ; les problèmes d'installation ne sont résolus que si l'on veut bien considérer qu'il y a un navigateur "normal" sur le poste client, auquel cas il faut gérer les cas de navigateur "spéciaux" qui ne manquent pas de se manifester à la surprise générale ; si, en plus, il faut prévoir une install automatique de la partie serveur sur la partie client...
Au contraire, avec java web start, les installations java se présentent facilement, que ce soit par le web ou par CD. L'installation d'une machine virtuelle peut se faire par une secrétaire. Les problèmes de portabilité sont quasi-inexistants. Si la base de données est distante, il suffit souvent de changer l'url du driver jdbc. Si jamais on veut du http pour un protocole d'échange de fichiers, on peut utiliser jetty. Si une sécurité plus forte est nécessaire, on peut utiliser le SSL, que le java standard gère très bien, et tous les systèmes de cryptographie, casse tête total en milieu web.
Donc swing me paraît largement la meilleure solution.
-- Hervé AGNOUX http://www.diaam-informatique.com
jlp
"Hervé AGNOUX" a écrit dans le message de news:448850f0$0$8474$
Pierre-Alexandre Meyer wrote:
Bonjour,
Je vais commencer à développer une application de gestion de base de données (pour résumer).
J'hésite entre coder une véritable interface graphique (Swing + JSQL) ou bien développer un modèle type tomcat + hibernate.
L'outil devra être déployé sur de nombreuses machines et différents OS, et j'ai peur que la deuxième solution ne soit trop compliquée à déployer, surtout pour des personnes non qualifiées.
Pour moi la balance devrait pencher assez fortement vers une application swing.
N'en déplaise aux spécialistes habituels, les systèmes à base de web n'apporte que des problèmes, problèmes qui se justifient parfaitement lorsqu'on est sur... le web, mais dont je ne vois absolument pas ce qu'ils apportent lorsqu'on est dans un contexte plus local.
Avec le web il faut gérer le HTML, le CSS, le javascript ; les problèmes d'installation ne sont résolus que si l'on veut bien considérer qu'il y a un navigateur "normal" sur le poste client, auquel cas il faut gérer les cas de navigateur "spéciaux" qui ne manquent pas de se manifester à la surprise générale ; si, en plus, il faut prévoir une install automatique de
la partie serveur sur la partie client...
Au contraire, avec java web start, les installations java se présentent facilement, que ce soit par le web ou par CD. L'installation d'une machine virtuelle peut se faire par une secrétaire. Les problèmes de portabilité sont quasi-inexistants. Si la base de données est distante, il suffit souvent de changer l'url du driver jdbc. Si jamais on veut du http pour un protocole d'échange de fichiers, on peut utiliser jetty. Si une sécurité plus forte est nécessaire, on peut utiliser le SSL, que le java standard gère très bien, et tous les systèmes de cryptographie, casse tête total en milieu web.
Donc swing me paraît largement la meilleure solution.
-- Hervé AGNOUX http://www.diaam-informatique.com
+1 : pour JWS + Swing
Je n'arrive plus à comprendre cette folie de framework Rich Client ....
"Hervé AGNOUX" <herve.xx.agnoux@diaam-informatique.com.zz> a écrit dans le
message de news:448850f0$0$8474$636a55ce@news.free.fr...
Pierre-Alexandre Meyer wrote:
Bonjour,
Je vais commencer à développer une application de gestion de base de
données (pour résumer).
J'hésite entre coder une véritable interface graphique (Swing + JSQL) ou
bien développer un modèle type tomcat + hibernate.
L'outil devra être déployé sur de nombreuses machines et différents OS,
et j'ai peur que la deuxième solution ne soit trop compliquée à
déployer, surtout pour des personnes non qualifiées.
Pour moi la balance devrait pencher assez fortement vers une application
swing.
N'en déplaise aux spécialistes habituels, les systèmes à base de web
n'apporte que des problèmes, problèmes qui se justifient parfaitement
lorsqu'on est sur... le web, mais dont je ne vois absolument pas ce qu'ils
apportent lorsqu'on est dans un contexte plus local.
Avec le web il faut gérer le HTML, le CSS, le javascript ; les problèmes
d'installation ne sont résolus que si l'on veut bien considérer qu'il y a
un navigateur "normal" sur le poste client, auquel cas il faut gérer les
cas de navigateur "spéciaux" qui ne manquent pas de se manifester à la
surprise générale ; si, en plus, il faut prévoir une install automatique
de
la partie serveur sur la partie client...
Au contraire, avec java web start, les installations java se présentent
facilement, que ce soit par le web ou par CD. L'installation d'une machine
virtuelle peut se faire par une secrétaire. Les problèmes de portabilité
sont quasi-inexistants. Si la base de données est distante, il suffit
souvent de changer l'url du driver jdbc. Si jamais on veut du http pour un
protocole d'échange de fichiers, on peut utiliser jetty. Si une sécurité
plus forte est nécessaire, on peut utiliser le SSL, que le java standard
gère très bien, et tous les systèmes de cryptographie, casse tête total en
milieu web.
Donc swing me paraît largement la meilleure solution.
--
Hervé AGNOUX
http://www.diaam-informatique.com
+1 : pour JWS + Swing
Je n'arrive plus à comprendre cette folie de framework Rich Client ....
"Hervé AGNOUX" a écrit dans le message de news:448850f0$0$8474$
Pierre-Alexandre Meyer wrote:
Bonjour,
Je vais commencer à développer une application de gestion de base de données (pour résumer).
J'hésite entre coder une véritable interface graphique (Swing + JSQL) ou bien développer un modèle type tomcat + hibernate.
L'outil devra être déployé sur de nombreuses machines et différents OS, et j'ai peur que la deuxième solution ne soit trop compliquée à déployer, surtout pour des personnes non qualifiées.
Pour moi la balance devrait pencher assez fortement vers une application swing.
N'en déplaise aux spécialistes habituels, les systèmes à base de web n'apporte que des problèmes, problèmes qui se justifient parfaitement lorsqu'on est sur... le web, mais dont je ne vois absolument pas ce qu'ils apportent lorsqu'on est dans un contexte plus local.
Avec le web il faut gérer le HTML, le CSS, le javascript ; les problèmes d'installation ne sont résolus que si l'on veut bien considérer qu'il y a un navigateur "normal" sur le poste client, auquel cas il faut gérer les cas de navigateur "spéciaux" qui ne manquent pas de se manifester à la surprise générale ; si, en plus, il faut prévoir une install automatique de
la partie serveur sur la partie client...
Au contraire, avec java web start, les installations java se présentent facilement, que ce soit par le web ou par CD. L'installation d'une machine virtuelle peut se faire par une secrétaire. Les problèmes de portabilité sont quasi-inexistants. Si la base de données est distante, il suffit souvent de changer l'url du driver jdbc. Si jamais on veut du http pour un protocole d'échange de fichiers, on peut utiliser jetty. Si une sécurité plus forte est nécessaire, on peut utiliser le SSL, que le java standard gère très bien, et tous les systèmes de cryptographie, casse tête total en milieu web.
Donc swing me paraît largement la meilleure solution.
-- Hervé AGNOUX http://www.diaam-informatique.com
+1 : pour JWS + Swing
Je n'arrive plus à comprendre cette folie de framework Rich Client ....
