Un framework AJAX

Alexandre Touret <atouret.NOSPAM@free.fr> wrote:

Bonjour,
je dois migrer une architecture de type Struts 1.2.x, Spring,
hibernate tournant sur Oracle AS 10.13 vers une archi WEB 2.0 (AJAX).

Quel est l'objectif ?
C'est pour un test d'archi ou pour améliorer une appli existante ?

Bon dans l'absolu, je n'ai qu'à virer struts,

pourquoi ?

Backbase : la rolls, super cher mais ca tape.

Par curiosité vu ton commentaire je suis allé voir: c'est extremement lourd,
et ça crashe en 3 clicks...
Moi je mets un zéro pointé: pas de ça dans mes appli.
(J'avais pensé exactement pareil en testant Rialto, sauf que Rialto est
gratuit)

Personnellement je fais du struts + hibernate + dojo.
Inconvénients de dojo:
- aucune documentation "utilisable", il faut tout faire à partir des démos
- lent à charger lorsqu'on a un paquet de widgets (plusieurs centaines dans
mon cas)

Avantages:
- génial pour l'utilisateur quand c'est utilisé judicieusement
- très facile à intégrer dans une appli existante
- ça marche bien

Personnellement, plutot que de me bloquer avec un framework, je préfère
utiliser des librairies moins intrusives
genre ajaxtags http://ajaxtags.sourceforge.net/ qui ne remettent pas en
cause mon architecture et que j'utilise uniquement lorsque j'ai un besoin
foncitonnel réel.
Mais tout dépend de l'objectif de l'appli.

Alexandre Touret <atouret.NOSPAM@free.fr> wrote:

Bonjour,
je dois migrer une architecture de type Struts 1.2.x, Spring, hibernate
tournant sur Oracle AS 10.13 vers une archi WEB 2.0 (AJAX). Bon dans
l'absolu, je n'ai qu'à virer struts, mais pour quoi et remplacer par des
composants supportants AJAX?J'ai différencié différentes approches

J'ai vu différents FRAMEWORKS tenant la route

Approche JSF:
Dynafaces + JMaki (opensource), support de netbeans
Backbase : la rolls, super cher mais ca tape.

Approche RPC
Une approche intéressante mais qui à l'inconvénient de se séparer du
modèle J2EE
GWT; +/- incompatible avec des POJOS Hibernate
Echo2

Maintenant, je dois faire le choix.... et la je vous demandrai bien
votre avis :-D

Une problématique qui m'intéresse, vu que je suis un peu dans le même
cas (si ce n'est que je pars d'une architecture Spring, Hibernate,
Tapestry 3.x). Il y a des choses intéressantes du côté de Tacos, mais
hélas pour mon projet impossible de passer par là car ça suppose de
passer sur Tapestry 4.x, ce qui implique un java 1.5.x minimum, or le
client du projet impose un JRE 1.4.2 et pas plus pour le moment...

Je n'ai donc pas de solution miracle pour le moment, mais je ne
chercherai de toutes manières pas à virer Tapestry autant que possible
vu le volume de pages qu'il y a dans l'application (le passage sur AJAX
étant plutôt progressif dans mon cas). A moins que toute solution
envisageable l'impose de toutes manières, mais là je crains que ça soit
plutôt le passage en architecture AJAX qui soit remis en cause.


--
Christophe Franco

Lionel wrote:

Quel est l'objectif ?
C'est pour un test d'archi ou pour améliorer une appli existante ?

Bon dans l'absolu, je n'ai qu'à virer struts,

pourquoi ?
Personnellement, je trouve struts deprecie. Maintenant que JSF est ds

les specifications de SUN J2EE >1.4, il est interessant de passer a une
architecture plus d actualite (shale,jsf,...). Quand j ai mis en place
cette archi il y a pres de deux ans, JSF n etait pas encore disponible
sur le serveur d applications utilisé (Oracle AS). Je ne souhaitais pas
m encombrer d une integration de framework JSF dans un conteneur de
servlet dont la spec n etait pas assez avancee.

De plus, je cherche a ameliorer la couche presentation existante ds un
premier temps en ajoutant pas mal de composants asynchrones (AJAX) ceci
afin d ameliorer les perfs d une part. D autre part, je cherche aussi a
doter les developpeurs de composants reellement reutilisables (tableau
avec tris sur les colonnes, calendrier, autocompletion,...)

Backbase : la rolls, super cher mais ca tape.

Par curiosité vu ton commentaire je suis allé voir: c'est extremement lourd,
et ça crashe en 3 clicks...
Moi je mets un zéro pointé: pas de ça dans mes appli.
(J'avais pensé exactement pareil en testant Rialto, sauf que Rialto est
gratuit)
heeuuu perso j ai navigue ds l explorer il y a qq jours et vu les

composants qu ils proposent, cela permettrait de realiser des
formulaires JSF de la meme maniere que des clients lourd . Mais bon

Personnellement je fais du struts + hibernate + dojo.
Inconvénients de dojo:
- aucune documentation "utilisable", il faut tout faire à partir des démos
- lent à charger lorsqu'on a un paquet de widgets (plusieurs centaines dans
mon cas)

Avantages:
- génial pour l'utilisateur quand c'est utilisé judicieusement
- très facile à intégrer dans une appli existante
- ça marche bien
J ai regarde un petit peu, ca a l air pas mal en effet.

Personnellement, plutot que de me bloquer avec un framework, je préfère
utiliser des librairies moins intrusives
genre ajaxtags http://ajaxtags.sourceforge.net/ qui ne remettent pas en
cause mon architecture et que j'utilise uniquement lorsque j'ai un besoin
foncitonnel réel.
Mais tout dépend de l'objectif de l'appli.

Je comprends bien ton point de vue, ds mon cas, je pense que le mieux.
Ce dont j ai le plus peur c est de partir sur un Framework de type GWT
ou Echo2 qui se detache completement de l archi standard preconisée par
SUN (JSF).

Menfin voila, en tout cas merci pr ton point de vue, je m en vais
regarder de plus pres dojo et ajaxtags

Alexandre

Christophe Franco wrote:

Une problématique qui m'intéresse, vu que je suis un peu dans le même
cas (si ce n'est que je pars d'une architecture Spring, Hibernate,
Tapestry 3.x). Il y a des choses intéressantes du côté de Tacos, mais
hélas pour mon projet impossible de passer par là car ça suppose de
passer sur Tapestry 4.x, ce qui implique un java 1.5.x minimum, or le
client du projet impose un JRE 1.4.2 et pas plus pour le moment...

Je n'ai donc pas de solution miracle pour le moment, mais je ne
chercherai de toutes manières pas à virer Tapestry autant que possible
vu le volume de pages qu'il y a dans l'application (le passage sur AJAX
étant plutôt progressif dans mon cas). A moins que toute solution
envisageable l'impose de toutes manières, mais là je crains que ça soit
plutôt le passage en architecture AJAX qui soit remis en cause.


Ben, en ce qui nous concerne on ne pense passer a ajax que sur les

nouvelles applications.

Alexandre

Alexandre Touret <atouret.NOSPAM@free.fr> wrote:

Une problématique qui m'intéresse, vu que je suis un peu dans le même
cas (si ce n'est que je pars d'une architecture Spring, Hibernate,
Tapestry 3.x). Il y a des choses intéressantes du côté de Tacos, mais
hélas pour mon projet impossible de passer par là car ça suppose de
passer sur Tapestry 4.x, ce qui implique un java 1.5.x minimum, or le
client du projet impose un JRE 1.4.2 et pas plus pour le moment...

Je n'ai donc pas de solution miracle pour le moment, mais je ne
chercherai de toutes manières pas à virer Tapestry autant que possible
vu le volume de pages qu'il y a dans l'application (le passage sur AJAX
étant plutôt progressif dans mon cas). A moins que toute solution
envisageable l'impose de toutes manières, mais là je crains que ça soit
plutôt le passage en architecture AJAX qui soit remis en cause.


Ben, en ce qui nous concerne on ne pense passer a ajax que sur les

nouvelles applications.

Effectivement, ça change un petit peu la donne. Si tu n'as pas
d'impératif au niveau de la version du JRE, as-tu regardé du côté de
Tapestry 4.x ? (voir 5.x si tu es patient) Il y a de plus en plus de
possibilités AJAXiennes dans ce monde-là. Et il faut avouer que
l'intégration des nouveautés du JDK 1.5.x (annotations en particulier) a
permis d'avoir enfin une structure de définition de pages qui facilite
le développement, ce qui était le gros point noir de Tapestry 3.x. Reste
un manque de documentation toujours aussi cruel (rien à voir avec
Struts... On s'en sort essentiellement en fouillant dans les archives de
diverses mailing-lists)

--
Christophe Franco

Bonjour,
je dois migrer une architecture de type Struts 1.2.x, Spring, hibernate
tournant sur Oracle AS 10.13 vers une archi WEB 2.0 (AJAX). Bon dans
l'absolu, je n'ai qu'à virer struts, mais pour quoi et remplacer par des
composants supportants AJAX?J'ai différencié différentes approches

J'ai vu différents FRAMEWORKS tenant la route

Approche JSF:
Dynafaces + JMaki (opensource), support de netbeans
Backbase : la rolls, super cher mais ca tape.

Approche RPC
Une approche intéressante mais qui à l'inconvénient de se séparer du
modèle J2EE
GWT; +/- incompatible avec des POJOS Hibernate
Echo2

Maintenant, je dois faire le choix.... et la je vous demandrai bien
votre avis :-D

Perso, à cet instant, je privilégierai les standards (et donc JSF) car
AJAX est encore trés jeune (et le Web 2.0 trop proche du DHTML à mon
gout). Mais pour que tout celà soit vraiment bénéfique et utilisable, il
faudra ajouter facelets, seam (à ne pas oublier !) et ajax4jsf en
supplément à votre couche de présentation.

Les Dynafaces sont trés prometeurs, mais il faut que l'idée arrive à
maturation dans le groupe d'expert de la spec JSF pour qu'on puisse
vraiment parler de standard AJAX JSF.

En attendant, je trouve ajax4jsf est trés prométeur car il est peu
impactant et se limite à faire des choses simple sans injecter des
quantité déraisonables de javascript incontrolables et ingérable si l'on
a une large plateforme de navigateur comme cible.
https://ajax4jsf.dev.java.net/nonav/ajax/ajax-jsf/

A+
TM

TestMan wrote:

Perso, à cet instant, je privilégierai les standards (et donc JSF) car
AJAX est encore trés jeune (et le Web 2.0 trop proche du DHTML à mon
gout). Mais pour que tout celà soit vraiment bénéfique et utilisable, il
faudra ajouter facelets, seam (à ne pas oublier !) et ajax4jsf en
supplément à votre couche de présentation.

Les Dynafaces sont trés prometeurs, mais il faut que l'idée arrive à
maturation dans le groupe d'expert de la spec JSF pour qu'on puisse
vraiment parler de standard AJAX JSF.

En attendant, je trouve ajax4jsf est trés prométeur car il est peu
impactant et se limite à faire des choses simple sans injecter des
quantité déraisonables de javascript incontrolables et ingérable si l'on
a une large plateforme de navigateur comme cible.
https://ajax4jsf.dev.java.net/nonav/ajax/ajax-jsf/

A+
TM

Apres avoir vu ajax4jsf je pense aussi que c est tres prometteur. Peut
etre que je vais envisager une architecture de type Shale + richfaces
(Composant payant construit a partir d' ajax4jsf). En tout cas je suis d
accord avec toi qu il vaut mieux privilegier une architecture standard
(cf. JSF) ca evite de partir ds du n importe quoi et d avoir une
architecture perenne.
En ce qui concerne SEAM, quelle est la plus value par rapport a spring,
j ai vu une demo au javaone, et je n ai pas vraiment vu de
difference(mis a part les annotations)

En tout cas merci de ton point de vue
Alexandre

(...)
Personnellement, plutot que de me bloquer avec un framework, je
préfère utiliser des librairies moins intrusives
genre ajaxtags http://ajaxtags.sourceforge.net/ qui ne remettent pas
en cause mon architecture et que j'utilise uniquement lorsque j'ai un
besoin foncitonnel réel.

C'est peut-être très joli sous FF, mais, par exemple, "Autocomplete
Demo" ne fonctionne pas avec IE 6.

Pour le moins génant...

--
Cordialement, Thierry ;-)

TestMan wrote:

Perso, à cet instant, je privilégierai les standards (et donc JSF) car
AJAX est encore trés jeune (et le Web 2.0 trop proche du DHTML à mon
gout). Mais pour que tout celà soit vraiment bénéfique et utilisable,
il faudra ajouter facelets, seam (à ne pas oublier !) et ajax4jsf en
supplément à votre couche de présentation.

Les Dynafaces sont trés prometeurs, mais il faut que l'idée arrive à
maturation dans le groupe d'expert de la spec JSF pour qu'on puisse
vraiment parler de standard AJAX JSF.

En attendant, je trouve ajax4jsf est trés prométeur car il est peu
impactant et se limite à faire des choses simple sans injecter des
quantité déraisonables de javascript incontrolables et ingérable si
l'on a une large plateforme de navigateur comme cible.
https://ajax4jsf.dev.java.net/nonav/ajax/ajax-jsf/

A+
TM

Apres avoir vu ajax4jsf je pense aussi que c est tres prometteur. Peut
etre que je vais envisager une architecture de type Shale + richfaces
(Composant payant construit a partir d' ajax4jsf). En tout cas je suis d
accord avec toi qu il vaut mieux privilegier une architecture standard
(cf. JSF) ca evite de partir ds du n importe quoi et d avoir une
architecture perenne.
En ce qui concerne SEAM, quelle est la plus value par rapport a spring,
j ai vu une demo au javaone, et je n ai pas vraiment vu de
difference(mis a part les annotations)

En tout cas merci de ton point de vue
Alexandre
Bonjour Alexandre,

Je trouve personellement que Seam s'intègre beaucoup mieux dans
l'environement Java EE 5 entre JSF et EJB3 ou JPA par exemple.

Spring a été créé à une autre époque, celle d'EJB2 de ces "charmants"
CMP et des patrons DAO/DTO à gogo mais aussi celle des JSP et de struts
pour la présentation. De ce fait, il restera donc forcement plus
générique et peut même se voir comme un concurent direct de JavaEE. il
en reste que les "coutures" sont moins estétiques avec la nouvelle
generation que représente Seam.

Peut-être parce que l'AOP est ici limité au plus strict nécessaire ou
peut-être parce que l'apport des annotations à clairement permet d'en
simplifier la compréhension.

Enfin, vu toutes les améliorations apportées par Java EE 5, je ne suis
pas certain que Spring n'en ait pas perdu un peu de son interret ces
derniers temps. Mais là je risque de faire bondir dans certain châteaux
... alors je zappe :P

Si on résume, je pense que si tu pars pour faire du standard qui dure,
essaye en premier Seam, et je ne serais pas surpris si la JSR-299
débouchait sur un concept assez proche qui te permettrait d'avoir une
porte de sortie appréciable ;)

A+
TM

TestMan wrote:

Si on résume, je pense que si tu pars pour faire du standard qui dure,
essaye en premier Seam, et je ne serais pas surpris si la JSR-299
débouchait sur un concept assez proche qui te permettrait d'avoir une
porte de sortie appréciable ;)

A+
TM
Malheureusement, le pré requis est que je travaille sur Oracle AS 10.1.3

qui respecte la spec J2EE 1.4. Dc le support des annotations n y est dc
pas present.
De plus, on a deja pas mal de composants tournant sur Spring et qui
utilisent pas mal l AOP.

C est vrai que la JSR que tu viens d evoquer ainsi que jboss seam
semblent interessantes surtout sur l injection des objets avec etat,
mais bon je ne pense y passer que lorsque je serais en Java EE 5

Merci en tt cas

Alexandre