Je commence une r=E9flexion autour d'une migration de progiciels client
serveur vers J2EE.
Je ne souhaite pas un syst=E8me qui, lorsque =E0 la suite d'une
manipulation utilisateur qui implique un retour du logiciel apr=E8s
calcul ou recherche en BD, renvoie syst=E9matiquement ou tr=E8s souvent
"toute la page". Idem en cas de clic sur un onglet par exemple : bref,
je veux obtenir une navigation r=E9active, dans quasiment toutes les
siutations. Ce qui veut dire que les solutions =E0 base de
pr=E9remplissage des pages, permettant de g=E9rer quelques cas (saisie
d'un code article =3D> affichage du libelle instantan=E9) ne conviennent
pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui pr=E9c=E8de est av=E9r=E9, la suivante :
quelqu'un ou quelques uns ici peuvent ils essayer de lister
(id=E9alement avec avantages / inconv=E9nients) les diverses
possibilit=E9s offertes pour avoir ce genre d'ergonomie "quasi client
serveur", avec les contraintes suivantes :
- J2EE,
- Eclipse,
- composants open source si possible,
- pas de contrainte trop forte de navigateur (exemple XUL =3D Mozilla)
- temps de r=E9ponse tr=E8s bons, sachant que la puissance serveur "n'est
pas un probl=E8me" mais que par contre on peut avoir des PC moyens (mais
pas pourris).=20
jettes un oeil du cote de la techno jms en gros tres gros "c'est une file d'attente a base de msg ""email"""
Le monsieur a dit : "- temps de réponse très bons, "
-- ZebX - Mécano-boucher
Xavier MOGHRABI
renaud wrote:
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante : quelqu'un ou quelques uns ici peuvent ils essayer de lister (idéalement avec avantages / inconvénients) les diverses possibilités offertes pour avoir ce genre d'ergonomie "quasi client serveur", avec les contraintes suivantes :
- J2EE, - Eclipse, - composants open source si possible, - pas de contrainte trop forte de navigateur (exemple XUL = Mozilla) - temps de réponse très bons, sachant que la puissance serveur "n'est pas un problème" mais que par contre on peut avoir des PC moyens (mais pas pourris).
As-tu jeter un oeil à Eclipse Rich Client Platform : http://www.eclipse.org/rcp/
Ensuite pour faciliter l'installation et les mises à jours, on pourrait utiliser Java Web Start.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante :
quelqu'un ou quelques uns ici peuvent ils essayer de lister
(idéalement avec avantages / inconvénients) les diverses
possibilités offertes pour avoir ce genre d'ergonomie "quasi client
serveur", avec les contraintes suivantes :
- J2EE,
- Eclipse,
- composants open source si possible,
- pas de contrainte trop forte de navigateur (exemple XUL = Mozilla)
- temps de réponse très bons, sachant que la puissance serveur "n'est
pas un problème" mais que par contre on peut avoir des PC moyens (mais
pas pourris).
As-tu jeter un oeil à Eclipse Rich Client Platform :
http://www.eclipse.org/rcp/
Ensuite pour faciliter l'installation et les mises à jours, on pourrait
utiliser Java Web Start.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante : quelqu'un ou quelques uns ici peuvent ils essayer de lister (idéalement avec avantages / inconvénients) les diverses possibilités offertes pour avoir ce genre d'ergonomie "quasi client serveur", avec les contraintes suivantes :
- J2EE, - Eclipse, - composants open source si possible, - pas de contrainte trop forte de navigateur (exemple XUL = Mozilla) - temps de réponse très bons, sachant que la puissance serveur "n'est pas un problème" mais que par contre on peut avoir des PC moyens (mais pas pourris).
As-tu jeter un oeil à Eclipse Rich Client Platform : http://www.eclipse.org/rcp/
Ensuite pour faciliter l'installation et les mises à jours, on pourrait utiliser Java Web Start.
Je commence une réflexion autour d'une migration de progiciels client serveur vers J2EE.
Je ne souhaite pas un système qui, lorsque à la suite d'une manipulation utilisateur qui implique un retour du logiciel après calcul ou recherche en BD, renvoie systématiquement ou très souvent "toute la page".
C'est exactement un client web (léger) ça...
Idem en cas de clic sur un onglet par exemple : bref, je veux obtenir une navigation réactive, dans quasiment toutes les siutations. Ce qui veut dire que les solutions à base de préremplissage des pages, permettant de gérer quelques cas (saisie d'un code article => affichage du libelle instantané) ne conviennent pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ben non. C'est plutot l'inverse d'après ce que tu décris. C'est justement le "saisie d'un code article => affichage du libelle instantané" qui est plus délicat en web. (pour cela il faut utiliser ajax)
renaud wrote:
Bonjour à tous.
Je commence une réflexion autour d'une migration de progiciels client
serveur vers J2EE.
Je ne souhaite pas un système qui, lorsque à la suite d'une
manipulation utilisateur qui implique un retour du logiciel après
calcul ou recherche en BD, renvoie systématiquement ou très souvent
"toute la page".
C'est exactement un client web (léger) ça...
Idem en cas de clic sur un onglet par exemple : bref,
je veux obtenir une navigation réactive, dans quasiment toutes les
siutations. Ce qui veut dire que les solutions à base de
préremplissage des pages, permettant de gérer quelques cas (saisie
d'un code article => affichage du libelle instantané) ne conviennent
pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ben non. C'est plutot l'inverse d'après ce que tu décris.
C'est justement le "saisie d'un code article => affichage du libelle
instantané" qui est plus délicat en web.
(pour cela il faut utiliser ajax)
Je commence une réflexion autour d'une migration de progiciels client serveur vers J2EE.
Je ne souhaite pas un système qui, lorsque à la suite d'une manipulation utilisateur qui implique un retour du logiciel après calcul ou recherche en BD, renvoie systématiquement ou très souvent "toute la page".
C'est exactement un client web (léger) ça...
Idem en cas de clic sur un onglet par exemple : bref, je veux obtenir une navigation réactive, dans quasiment toutes les siutations. Ce qui veut dire que les solutions à base de préremplissage des pages, permettant de gérer quelques cas (saisie d'un code article => affichage du libelle instantané) ne conviennent pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ben non. C'est plutot l'inverse d'après ce que tu décris. C'est justement le "saisie d'un code article => affichage du libelle instantané" qui est plus délicat en web. (pour cela il faut utiliser ajax)
Hervé AGNOUX
renaud wrote:
Je commence une réflexion autour d'une migration de progiciels client serveur vers J2EE.
Moi il me semblait que, par définition, "client riche", c'était en dehors d'un navigateur web. Une application swing, par exemple. Une application swing, ou tout autre genre, peut parfaitement communiquer avec un serveur web.
Sur ce que tu dis, c'est à dire une bonne réactivité dans le cadre d'un navigateur web, il me semble que Ajax est bien adapté. Mais je ne suis pas sûr que cela fonctionne avec les principaux navigateurs web.
Cordialement.
-- Hervé AGNOUX http://www.diaam-informatique.com
renaud wrote:
Je commence une réflexion autour d'une migration de progiciels client
serveur vers J2EE.
Moi il me semblait que, par définition, "client riche", c'était en dehors
d'un navigateur web. Une application swing, par exemple. Une application
swing, ou tout autre genre, peut parfaitement communiquer avec un serveur
web.
Sur ce que tu dis, c'est à dire une bonne réactivité dans le cadre d'un
navigateur web, il me semble que Ajax est bien adapté. Mais je ne suis pas
sûr que cela fonctionne avec les principaux navigateurs web.
Je commence une réflexion autour d'une migration de progiciels client serveur vers J2EE.
Moi il me semblait que, par définition, "client riche", c'était en dehors d'un navigateur web. Une application swing, par exemple. Une application swing, ou tout autre genre, peut parfaitement communiquer avec un serveur web.
Sur ce que tu dis, c'est à dire une bonne réactivité dans le cadre d'un navigateur web, il me semble que Ajax est bien adapté. Mais je ne suis pas sûr que cela fonctionne avec les principaux navigateurs web.
Cordialement.
-- Hervé AGNOUX http://www.diaam-informatique.com
ludo06
Xavier MOGHRABI wrote:
renaud wrote:
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante : quelqu'un ou quelques uns ici peuvent ils essayer de lister (idéalement avec avantages / inconvénients) les diverses possibilités offertes pour avoir ce genre d'ergonomie "quasi client serveur", avec les contraintes suivantes :
- J2EE, - Eclipse, - composants open source si possible, - pas de contrainte trop forte de navigateur (exemple XUL = Mozilla) - temps de réponse très bons, sachant que la puissance serveur "n'est pas un problème" mais que par contre on peut avoir des PC moyens (mais pas pourris).
As-tu jeter un oeil à Eclipse Rich Client Platform : http://www.eclipse.org/rcp/
Ensuite pour faciliter l'installation et les mises à jours, on pourrait utiliser Java Web Start.
Tu peux aussi tester un interface Swing envoyee en XML, avec Swix
(http://www.swixml.org) par exemple (il y a un (debut) de framework MVC : SwixAT , http://www.swixat.org) . Exemple d'application bluffant: Le Bio Browser je Jonny Wray : http://www.jonnywray.com/java/ Lien direct: http://www.jonnywray.com/java/BioBrowser.jnlp
J'ai fait deux petites GUI qui fonctionnent tres bien avec (mais pas deployees aupres de clients, pour usage personnel), fais une recherche google dessus (et sur XUL pour voir d'autres alternatives).
C'est pour la partie "interface lourde", pour la partie affichage des informations reactives, effectivement ce serait bien d'avoir des systemes qui mettent a jour en temps reel les informations. J'essaie de programmer quelque chose un peu comme ca pour un projet en cours du soir, je suppose qu'il y a des solutions toutes faites (style utiliser le code d'azureus pour alimenter des objets affiches dans la gui en temps reel mais je divague :-).
-- Cordialement, Ludo - http://www.ubik-products.com --- "L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
Xavier MOGHRABI wrote:
renaud wrote:
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante :
quelqu'un ou quelques uns ici peuvent ils essayer de lister
(idéalement avec avantages / inconvénients) les diverses
possibilités offertes pour avoir ce genre d'ergonomie "quasi client
serveur", avec les contraintes suivantes :
- J2EE,
- Eclipse,
- composants open source si possible,
- pas de contrainte trop forte de navigateur (exemple XUL = Mozilla)
- temps de réponse très bons, sachant que la puissance serveur "n'est
pas un problème" mais que par contre on peut avoir des PC moyens (mais
pas pourris).
As-tu jeter un oeil à Eclipse Rich Client Platform :
http://www.eclipse.org/rcp/
Ensuite pour faciliter l'installation et les mises à jours, on pourrait
utiliser Java Web Start.
Tu peux aussi tester un interface Swing envoyee en XML, avec Swix
(http://www.swixml.org) par exemple (il y a un (debut) de framework MVC
: SwixAT , http://www.swixat.org) .
Exemple d'application bluffant: Le Bio Browser je Jonny Wray :
http://www.jonnywray.com/java/
Lien direct:
http://www.jonnywray.com/java/BioBrowser.jnlp
J'ai fait deux petites GUI qui fonctionnent tres bien avec (mais pas
deployees aupres de clients, pour usage personnel), fais une recherche
google dessus (et sur XUL pour voir d'autres alternatives).
C'est pour la partie "interface lourde", pour la partie affichage des
informations reactives, effectivement ce serait bien d'avoir des
systemes qui mettent a jour en temps reel les informations. J'essaie de
programmer quelque chose un peu comme ca pour un projet en cours du
soir, je suppose qu'il y a des solutions toutes faites (style utiliser
le code d'azureus pour alimenter des objets affiches dans la gui en
temps reel mais je divague :-).
--
Cordialement,
Ludo - http://www.ubik-products.com
---
"L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante : quelqu'un ou quelques uns ici peuvent ils essayer de lister (idéalement avec avantages / inconvénients) les diverses possibilités offertes pour avoir ce genre d'ergonomie "quasi client serveur", avec les contraintes suivantes :
- J2EE, - Eclipse, - composants open source si possible, - pas de contrainte trop forte de navigateur (exemple XUL = Mozilla) - temps de réponse très bons, sachant que la puissance serveur "n'est pas un problème" mais que par contre on peut avoir des PC moyens (mais pas pourris).
As-tu jeter un oeil à Eclipse Rich Client Platform : http://www.eclipse.org/rcp/
Ensuite pour faciliter l'installation et les mises à jours, on pourrait utiliser Java Web Start.
Tu peux aussi tester un interface Swing envoyee en XML, avec Swix
(http://www.swixml.org) par exemple (il y a un (debut) de framework MVC : SwixAT , http://www.swixat.org) . Exemple d'application bluffant: Le Bio Browser je Jonny Wray : http://www.jonnywray.com/java/ Lien direct: http://www.jonnywray.com/java/BioBrowser.jnlp
J'ai fait deux petites GUI qui fonctionnent tres bien avec (mais pas deployees aupres de clients, pour usage personnel), fais une recherche google dessus (et sur XUL pour voir d'autres alternatives).
C'est pour la partie "interface lourde", pour la partie affichage des informations reactives, effectivement ce serait bien d'avoir des systemes qui mettent a jour en temps reel les informations. J'essaie de programmer quelque chose un peu comme ca pour un projet en cours du soir, je suppose qu'il y a des solutions toutes faites (style utiliser le code d'azureus pour alimenter des objets affiches dans la gui en temps reel mais je divague :-).
-- Cordialement, Ludo - http://www.ubik-products.com --- "L'amour pour principe et l'ordre pour base; le progres pour but" (A.Comte)
Pierre Gilquin
WebObjects d'Apple http://www.apple.com/webobjects/ . Il s'agit d'un application server non J2EE qui peut etre deployer dans un container J2EE. Il contient un mapping objet-relationnel et à de manière integrée peut generer à partir de ce mapping des pages dynamiques pour un client léger ou distribuer les objets Java pour un client riche swing. Il fait aussi des Web services.
Pierre
"renaud" a écrit dans le message de news: Bonjour à tous.
Je commence une réflexion autour d'une migration de progiciels client serveur vers J2EE.
Je ne souhaite pas un système qui, lorsque à la suite d'une manipulation utilisateur qui implique un retour du logiciel après calcul ou recherche en BD, renvoie systématiquement ou très souvent "toute la page". Idem en cas de clic sur un onglet par exemple : bref, je veux obtenir une navigation réactive, dans quasiment toutes les siutations. Ce qui veut dire que les solutions à base de préremplissage des pages, permettant de gérer quelques cas (saisie d'un code article => affichage du libelle instantané) ne conviennent pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante : quelqu'un ou quelques uns ici peuvent ils essayer de lister (idéalement avec avantages / inconvénients) les diverses possibilités offertes pour avoir ce genre d'ergonomie "quasi client serveur", avec les contraintes suivantes :
- J2EE, - Eclipse, - composants open source si possible, - pas de contrainte trop forte de navigateur (exemple XUL = Mozilla) - temps de réponse très bons, sachant que la puissance serveur "n'est pas un problème" mais que par contre on peut avoir des PC moyens (mais pas pourris).
Merci d'avance... renaud
WebObjects d'Apple http://www.apple.com/webobjects/ .
Il s'agit d'un application server non J2EE qui peut etre deployer dans un
container J2EE.
Il contient un mapping objet-relationnel et à de manière integrée peut
generer à partir de ce mapping des pages dynamiques pour un client léger ou
distribuer les objets Java pour un client riche swing. Il fait aussi des Web
services.
Pierre
"renaud" <RenaudBB@gmail.com> a écrit dans le message de
news:1116936037.484752.291360@g47g2000cwa.googlegroups.com...
Bonjour à tous.
Je commence une réflexion autour d'une migration de progiciels client
serveur vers J2EE.
Je ne souhaite pas un système qui, lorsque à la suite d'une
manipulation utilisateur qui implique un retour du logiciel après
calcul ou recherche en BD, renvoie systématiquement ou très souvent
"toute la page". Idem en cas de clic sur un onglet par exemple : bref,
je veux obtenir une navigation réactive, dans quasiment toutes les
siutations. Ce qui veut dire que les solutions à base de
préremplissage des pages, permettant de gérer quelques cas (saisie
d'un code article => affichage du libelle instantané) ne conviennent
pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante :
quelqu'un ou quelques uns ici peuvent ils essayer de lister
(idéalement avec avantages / inconvénients) les diverses
possibilités offertes pour avoir ce genre d'ergonomie "quasi client
serveur", avec les contraintes suivantes :
- J2EE,
- Eclipse,
- composants open source si possible,
- pas de contrainte trop forte de navigateur (exemple XUL = Mozilla)
- temps de réponse très bons, sachant que la puissance serveur "n'est
pas un problème" mais que par contre on peut avoir des PC moyens (mais
pas pourris).
WebObjects d'Apple http://www.apple.com/webobjects/ . Il s'agit d'un application server non J2EE qui peut etre deployer dans un container J2EE. Il contient un mapping objet-relationnel et à de manière integrée peut generer à partir de ce mapping des pages dynamiques pour un client léger ou distribuer les objets Java pour un client riche swing. Il fait aussi des Web services.
Pierre
"renaud" a écrit dans le message de news: Bonjour à tous.
Je commence une réflexion autour d'une migration de progiciels client serveur vers J2EE.
Je ne souhaite pas un système qui, lorsque à la suite d'une manipulation utilisateur qui implique un retour du logiciel après calcul ou recherche en BD, renvoie systématiquement ou très souvent "toute la page". Idem en cas de clic sur un onglet par exemple : bref, je veux obtenir une navigation réactive, dans quasiment toutes les siutations. Ce qui veut dire que les solutions à base de préremplissage des pages, permettant de gérer quelques cas (saisie d'un code article => affichage du libelle instantané) ne conviennent pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante : quelqu'un ou quelques uns ici peuvent ils essayer de lister (idéalement avec avantages / inconvénients) les diverses possibilités offertes pour avoir ce genre d'ergonomie "quasi client serveur", avec les contraintes suivantes :
- J2EE, - Eclipse, - composants open source si possible, - pas de contrainte trop forte de navigateur (exemple XUL = Mozilla) - temps de réponse très bons, sachant que la puissance serveur "n'est pas un problème" mais que par contre on peut avoir des PC moyens (mais pas pourris).
Merci d'avance... renaud
Fabien Bergeret
renaud wrote:
Bonjour à tous.
Je commence une réflexion autour d'une migration de progiciels client serveur vers J2EE.
Je ne souhaite pas un système qui, lorsque à la suite d'une manipulation utilisateur qui implique un retour du logiciel après calcul ou recherche en BD, renvoie systématiquement ou très souvent "toute la page". Idem en cas de clic sur un onglet par exemple : bref, je veux obtenir une navigation réactive, dans quasiment toutes les siutations. Ce qui veut dire que les solutions à base de préremplissage des pages, permettant de gérer quelques cas (saisie d'un code article => affichage du libelle instantané) ne conviennent pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante : quelqu'un ou quelques uns ici peuvent ils essayer de lister (idéalement avec avantages / inconvénients) les diverses possibilités offertes pour avoir ce genre d'ergonomie "quasi client serveur", avec les contraintes suivantes :
- J2EE, - Eclipse, - composants open source si possible, - pas de contrainte trop forte de navigateur (exemple XUL = Mozilla) - temps de réponse très bons, sachant que la puissance serveur "n'est pas un problème" mais que par contre on peut avoir des PC moyens (mais pas pourris).
Merci d'avance... renaud
Client : swing ou swt
Serveur : serveur d'application light (Tomcat, communication Http) ou EJB (JBoss, communication RMI). J'ai mis en place la premiere pour ue application Web qui necessitait la mise en place d'un applet. Cette derniere communiquait avec le meme serveur d'application que le reste de l'appli Interet : archi standard, possibilite de changer de client (nvaigateur, xul ...)
renaud wrote:
Bonjour à tous.
Je commence une réflexion autour d'une migration de progiciels client
serveur vers J2EE.
Je ne souhaite pas un système qui, lorsque à la suite d'une
manipulation utilisateur qui implique un retour du logiciel après
calcul ou recherche en BD, renvoie systématiquement ou très souvent
"toute la page". Idem en cas de clic sur un onglet par exemple : bref,
je veux obtenir une navigation réactive, dans quasiment toutes les
siutations. Ce qui veut dire que les solutions à base de
préremplissage des pages, permettant de gérer quelques cas (saisie
d'un code article => affichage du libelle instantané) ne conviennent
pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante :
quelqu'un ou quelques uns ici peuvent ils essayer de lister
(idéalement avec avantages / inconvénients) les diverses
possibilités offertes pour avoir ce genre d'ergonomie "quasi client
serveur", avec les contraintes suivantes :
- J2EE,
- Eclipse,
- composants open source si possible,
- pas de contrainte trop forte de navigateur (exemple XUL = Mozilla)
- temps de réponse très bons, sachant que la puissance serveur "n'est
pas un problème" mais que par contre on peut avoir des PC moyens (mais
pas pourris).
Merci d'avance...
renaud
Client : swing ou swt
Serveur : serveur d'application light (Tomcat, communication Http) ou
EJB (JBoss, communication RMI).
J'ai mis en place la premiere pour ue application Web qui necessitait la
mise en place d'un applet. Cette derniere communiquait avec le meme
serveur d'application que le reste de l'appli
Interet : archi standard, possibilite de changer de client (nvaigateur,
xul ...)
Je commence une réflexion autour d'une migration de progiciels client serveur vers J2EE.
Je ne souhaite pas un système qui, lorsque à la suite d'une manipulation utilisateur qui implique un retour du logiciel après calcul ou recherche en BD, renvoie systématiquement ou très souvent "toute la page". Idem en cas de clic sur un onglet par exemple : bref, je veux obtenir une navigation réactive, dans quasiment toutes les siutations. Ce qui veut dire que les solutions à base de préremplissage des pages, permettant de gérer quelques cas (saisie d'un code article => affichage du libelle instantané) ne conviennent pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante : quelqu'un ou quelques uns ici peuvent ils essayer de lister (idéalement avec avantages / inconvénients) les diverses possibilités offertes pour avoir ce genre d'ergonomie "quasi client serveur", avec les contraintes suivantes :
- J2EE, - Eclipse, - composants open source si possible, - pas de contrainte trop forte de navigateur (exemple XUL = Mozilla) - temps de réponse très bons, sachant que la puissance serveur "n'est pas un problème" mais que par contre on peut avoir des PC moyens (mais pas pourris).
Merci d'avance... renaud
Client : swing ou swt
Serveur : serveur d'application light (Tomcat, communication Http) ou EJB (JBoss, communication RMI). J'ai mis en place la premiere pour ue application Web qui necessitait la mise en place d'un applet. Cette derniere communiquait avec le meme serveur d'application que le reste de l'appli Interet : archi standard, possibilite de changer de client (nvaigateur, xul ...)
cilovie
Un truc intéressant et prometteur : https://jdnc.dev.java.net
renaud wrote:
Bonjour à tous.
Je commence une réflexion autour d'une migration de progiciels client serveur vers J2EE.
Je ne souhaite pas un système qui, lorsque à la suite d'une manipulation utilisateur qui implique un retour du logiciel après calcul ou recherche en BD, renvoie systématiquement ou très souvent "toute la page". Idem en cas de clic sur un onglet par exemple : bref, je veux obtenir une navigation réactive, dans quasiment toutes les siutations. Ce qui veut dire que les solutions à base de préremplissage des pages, permettant de gérer quelques cas (saisie d'un code article => affichage du libelle instantané) ne conviennent pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante : quelqu'un ou quelques uns ici peuvent ils essayer de lister (idéalement avec avantages / inconvénients) les diverses possibilités offertes pour avoir ce genre d'ergonomie "quasi client serveur", avec les contraintes suivantes :
- J2EE, - Eclipse, - composants open source si possible, - pas de contrainte trop forte de navigateur (exemple XUL = Mozilla) - temps de réponse très bons, sachant que la puissance serveur "n'est pas un problème" mais que par contre on peut avoir des PC moyens (mais pas pourris).
Merci d'avance... renaud
Un truc intéressant et prometteur :
https://jdnc.dev.java.net
renaud wrote:
Bonjour à tous.
Je commence une réflexion autour d'une migration de progiciels client
serveur vers J2EE.
Je ne souhaite pas un système qui, lorsque à la suite d'une
manipulation utilisateur qui implique un retour du logiciel après
calcul ou recherche en BD, renvoie systématiquement ou très souvent
"toute la page". Idem en cas de clic sur un onglet par exemple : bref,
je veux obtenir une navigation réactive, dans quasiment toutes les
siutations. Ce qui veut dire que les solutions à base de
préremplissage des pages, permettant de gérer quelques cas (saisie
d'un code article => affichage du libelle instantané) ne conviennent
pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante :
quelqu'un ou quelques uns ici peuvent ils essayer de lister
(idéalement avec avantages / inconvénients) les diverses
possibilités offertes pour avoir ce genre d'ergonomie "quasi client
serveur", avec les contraintes suivantes :
- J2EE,
- Eclipse,
- composants open source si possible,
- pas de contrainte trop forte de navigateur (exemple XUL = Mozilla)
- temps de réponse très bons, sachant que la puissance serveur "n'est
pas un problème" mais que par contre on peut avoir des PC moyens (mais
pas pourris).
Un truc intéressant et prometteur : https://jdnc.dev.java.net
renaud wrote:
Bonjour à tous.
Je commence une réflexion autour d'une migration de progiciels client serveur vers J2EE.
Je ne souhaite pas un système qui, lorsque à la suite d'une manipulation utilisateur qui implique un retour du logiciel après calcul ou recherche en BD, renvoie systématiquement ou très souvent "toute la page". Idem en cas de clic sur un onglet par exemple : bref, je veux obtenir une navigation réactive, dans quasiment toutes les siutations. Ce qui veut dire que les solutions à base de préremplissage des pages, permettant de gérer quelques cas (saisie d'un code article => affichage du libelle instantané) ne conviennent pas.
On est donc si je ne m'abuse dans une logique de "client riche" ?
Ma question est, si ce qui précède est avéré, la suivante : quelqu'un ou quelques uns ici peuvent ils essayer de lister (idéalement avec avantages / inconvénients) les diverses possibilités offertes pour avoir ce genre d'ergonomie "quasi client serveur", avec les contraintes suivantes :
- J2EE, - Eclipse, - composants open source si possible, - pas de contrainte trop forte de navigateur (exemple XUL = Mozilla) - temps de réponse très bons, sachant que la puissance serveur "n'est pas un problème" mais que par contre on peut avoir des PC moyens (mais pas pourris).
