Auto formation struts

Bonjour,

je me permets d'intervenir....

Seb wrote:

ok, tu bosses sur de gros projets ? sinon continue à faire tes
petites servlets.

Tiens typiquement l'étudiant qui connait rien a l'informatique mais

je trouve que sa remarque n'étais pas complètement infondée.

qui croit que tous les projets open source sont la panacé sous
prétexte que c'est "open source"

loin de là, mais tout comme je pense qu'il vaut mieux utiliser hibernate que
faire son propre framework de persistance, je pense qu'il vaut mieux
utiliser struts plutot que de batir son framework (je parle dans le cas d'un
groupe de développeurs qui n'ont pas 6mois de R&D à consacrer à ce framework
maison)

Parce que j'imagine que toi t'as déjà fait des benchmarks sur
Struts.....?

tu as déjà fait un benchmack de struts comparé à un benchmark avec ton
propre framework ?
ca m'interesse, je n'ai malheureusement jamais eu le temps de le faire...

Sincèrement, je ne suis pas sur qu'il soit possible de connaître
toutes les subtilités de Struts en lisant simplement les quelques
tutos disponibles sur Struts sur Internet : genre les nombreuses
Taglibes html, templates ou tiles.... ou encore les validator forms.

ca aide bcp, tu fais comment sinon ?

t'achète un bouquin.... c'est pas parce que tu as comprit MVC que tu
as comprit Struts.

perso, je pense que l'étude d'exemples + tutos et groupes sur le net apporte
autant qu'un bouquin

Le pattern MVC2 (hum hum!) est plus

simple a comprendre que toutes ces balises (imbitables?)

bof, c'est pas si compliqué que ca quand meme...

qui ne seront peut

être pas conformes avec JSTL à l'avenir.....

rien de bien dramatique à mon avis.
par contre avoir rendu deprecated les templates au profit de tiles, c'est
vraiment pas pratique, car il va falloir modifier toutes les pages....

D'ailleurs, que pensez vous des validators forms? remplacer 2
lignes de code Java par 4 lignes de configuration XML avec une
syntaxe imbitable style Perl ..... pas génial leur truc.

c'est pas la syntaxe qui pose problème à mes yeux, c'est le fait que c'est
statique. Donc complètement inutile.
Sans compter que le JavascriptValidatorTag est buggé, et le code javascript
généré assez lamentable. Mais une fois que tout ceci est corrigé, modifié et
rendu dynamique, cela s'avère etre très pratique.

Bref, je pense qu'on pourrait faire mieux, mais c'est mieux que de partir
d'une feuille blanche (surtout pour qqun qui débute), ou pour du travail en
équipe: cela permet d'homogénéiser tous les développements.

Tiens typiquement l'étudiant qui connait rien a l'informatique mais

je trouve que sa remarque n'étais pas complètement infondée.

C'est pas la remarque qui me gênait mais l'argumentation. Le fait de croire
que Struts est une fin en soi et la panacée, ainsi que le fait de se voir
passer pour un con si on a le malheur de critiquer une solution Open source.

qui croit que tous les projets open source sont la panacé sous
prétexte que c'est "open source"
loin de là, mais tout comme je pense qu'il vaut mieux utiliser hibernate

que

faire son propre framework de persistance, je pense qu'il vaut mieux
utiliser struts plutot que de batir son framework (je parle dans le cas
d'un

groupe de développeurs qui n'ont pas 6mois de R&D à consacrer à ce
framework

maison)

D'accord....
D'un autre coté si tu mets 6 mois à maîtriser les taglib Struts qui ne
seront peut être plus standards dans 1 an ou 2....
L'intérêt de ce type de framework c'est bien de gagner en productivité non?

Parce que j'imagine que toi t'as déjà fait des benchmarks sur
Struts.....?

tu as déjà fait un benchmack de struts comparé à un benchmark avec ton
propre framework ?
ca m'interesse, je n'ai malheureusement jamais eu le temps de le faire...

La tendance actuelle c'est de rajouter le maximum de couches applicatives :
alors une couche de Struts, une couche d'EJB, une couche d'hibernate, une
couche de Jetspeed, une couche de JDO.
C'est sur qu'avec des architectures 15/tiers on est vachement plus
productifs et performants .... et en prime ca rassure les actionnaires.

qui ne seront peut

être pas conformes avec JSTL à l'avenir.....

rien de bien dramatique à mon avis.

Mouai..... mon opinion c'est que certaines taglibs Struts sont aberrantes :
quel est l'intérêt par exemple des Taglib HTML? j'aimerais bien qu'on
m'explique.
Parce que en utilisant ces taglibs HTML (Taglib qui au départ doivent
améliorer la productivité), on se retrouve avec des pages JSP qu'un
intégrateur HTML ou infographiste ne pourra pas retravailler.
Il y aurait pas un peu de zèle de la part des développeurs Struts? ils ont
réussit à encapsuler la couche HTML (!!??)

par contre avoir rendu deprecated les templates au profit de tiles, c'est
vraiment pas pratique, car il va falloir modifier toutes les pages....

"....qui ne seront peut être plus standards dans 1 an ou 2"

D'ailleurs, que pensez vous des validators forms? remplacer 2
lignes de code Java par 4 lignes de configuration XML avec une
syntaxe imbitable style Perl ..... pas génial leur truc.
c'est pas la syntaxe qui pose problème à mes yeux, c'est le fait que c'est

statique. Donc complètement inutile.

Qu'entends tu par statique?non orienté objet?
Moi ce qui me gêne c'est de laisser la logique de validation au framework,
aussi puissant soit t'il.... tout cela avec une syntaxe qu'un développeur
Java peut avoir du mal à appréhender.

Sans compter que le JavascriptValidatorTag est buggé, et le code
javascript

généré assez lamentable. Mais une fois que tout ceci est corrigé, modifié
et

rendu dynamique, cela s'avère etre très pratique.

Dans le bouquin sur Struts écrit par James Turner et Kevin Bedell, il y a un
paragraphe intitulé "Le validator en vaut-il la peine"
Bon ... quand on sait qu'ils ont participé au développement de ce
validator....

Bref, je pense qu'on pourrait faire mieux, mais c'est mieux que de partir
d'une feuille blanche (surtout pour qqun qui débute), ou pour du travail
en

équipe: cela permet d'homogénéiser tous les développements.

D'accord.

Struts peut être très pratique, je reproche simplement le fait de dire que
c'est la panacée.
Un petit lien pour le plaisir :
http://www.application-servers.com/comments.do?reqCode=readComments&sid 03
-03-23-22:17:22

Seb wrote:

D'un autre coté si tu mets 6 mois à maîtriser les taglib Struts qui ne
seront peut être plus standards dans 1 an ou 2....

faut 1mois à tout casser pour maitriser :-)

La tendance actuelle c'est de rajouter le maximum de couches
applicatives : alors une couche de Struts, une couche d'EJB, une
couche d'hibernate, une couche de Jetspeed, une couche de JDO.
C'est sur qu'avec des architectures 15/tiers on est vachement plus
productifs et performants .... et en prime ca rassure les
actionnaires.

pour moi hibernate est plus indispensable que struts....et niveau gain de
temps, c'est incomparable.

Parce que en utilisant ces taglibs HTML (Taglib qui au départ doivent
améliorer la productivité), on se retrouve avec des pages JSP qu'un
intégrateur HTML ou infographiste ne pourra pas retravailler.

moi ca me dérange pas, j'ai la charte graphique avant de commencer à coder.
Et je ne vois pas en quoi les tags HTML sont génants...ils n'intègrent pas
de graphisme. Il suffit de modifier la feuille css.
Ceci dit, je ne les utilise pas car je préfère 100 fois la librairie
struts-layout, qui, elle, me fait gagner un temps énorme (à condition
d'avoir la charte *avant*) une fois que j'ai créé mes propres tags
graphiques, basés sur ceux de struts-layout mais améliorés pour intégrer ma
charte.

Personnellement, je n'ai jamais vu un infographiste travailler des pages
JSP. Et jamais je ne laisserai un graphiste toucher à mes pages. Il bosse de
son coté, et j'intègre et je découpe ses pages comme je veux. Plus
j'encapsule, mieux c'est.

Il y aurait pas un peu de zèle de la part des développeurs Struts?
ils ont réussit à encapsuler la couche HTML (!!??)

idem, ce n'est pas génant. Au contraire.
Ceci dit, je trouve que les balises HTML de struts n'ont que très peu
d'interet car elle
Struts-layout en fait beaucoup plus.
Actuellement, meme pour une page très complexe, je ne crache *aucune* ligne
HTML. Mes écrans sont parfaits. C'est pratique quand on travaille 6 mois-1
an sur le meme projet, sans que la charte graphique ne bouge. Et tu peux pas
imaginer à quel point ca change la vie quand on code les JSP...

Qu'entends tu par statique?non orienté objet?

statique = non dynamique.
Dnas mes sites, de nombreux champs ont des types qui changent en fonction de
certains paramètres calculés (string, float, int, date, required ou pas,
length....). Je ne voit pas trop comment utiliser les validatorForm pour
valider ce genre de chose car il faut tout déclarer "en dur" dans un fichier
xml....
Bref, ca n'a aucun interet.

Moi ce qui me gêne c'est de laisser la logique de validation au
framework, aussi puissant soit t'il....

je ne vois pas ou est le problème. Tu lui dis ce qu'il doit valider et
comment. Et c'est lui qui valide...rien de choquant. Tu peux te concentrer
sur la partier métier, plutot que de passer du temps à écrire comment
valider.

tout cela avec une syntaxe
qu'un développeur Java peut avoir du mal à appréhender.

je n'ai toujours pas compris le problème avec la syntaxe...

http://www.application-servers.com/comments.do?reqCode=readComments&sid 03

-03-23-22:17:22

J'avais lu cette article il y a longtemps. Je suis entièrement d'accord sur
le fait qu'il faut impérativement développer une couche au dessus de struts.
Mais une fois que c'est fait, je trouve que c'est très agréable.
Je maintiens que l'utilisation de struts+struts-layout+hibernate permet de
gagner énormément de temps sur les développements, une fois qu'on a écrit la
couche de base.
Je ne suis pas d'accord avec le reste.
D'ailleurs as-tu lu la réponse faite à cet article, qui elle, est pleine de
bon sens ?
<http://www.application-servers.com/links.do?reqCode=showLink&lid73>


Sinon, puisque tu connais ce site, tu devrais également connaitre
http://struts.application-servers.com/

"Nan Struts c'est un framework, pas un librairie mais un ensemble de
librairie.
Apprend ton sujet avant de donner des leçons. Le fait que tu mettes
des mots
les uns à la suite des autres ne signifie pas que tu maîtrises le
sujet"

Ne joue pas sur les mots, tu avais très bien compris et puis t'inkiète
pas pr moi, on est pas la pr parler de ma situation ;)

A la base de ce message, je voulais juste aiguiller qqn qui cherchait
de la doc sur Struts et au final ca devient un débat sur Struts...

Bon courage les gars !


"Lionel" <cooll_nospam@free.fr> wrote in message news:<404631cf$0$21669$636a15ce@news.free.fr>...

Seb wrote:

D'un autre coté si tu mets 6 mois à maîtriser les taglib Struts qui ne
seront peut être plus standards dans 1 an ou 2....

faut 1mois à tout casser pour maitriser :-)

La tendance actuelle c'est de rajouter le maximum de couches
applicatives : alors une couche de Struts, une couche d'EJB, une
couche d'hibernate, une couche de Jetspeed, une couche de JDO.
C'est sur qu'avec des architectures 15/tiers on est vachement plus
productifs et performants .... et en prime ca rassure les
actionnaires.

pour moi hibernate est plus indispensable que struts....et niveau gain de
temps, c'est incomparable.

Parce que en utilisant ces taglibs HTML (Taglib qui au départ doivent
améliorer la productivité), on se retrouve avec des pages JSP qu'un
intégrateur HTML ou infographiste ne pourra pas retravailler.

moi ca me dérange pas, j'ai la charte graphique avant de commencer à coder.
Et je ne vois pas en quoi les tags HTML sont génants...ils n'intègrent pas
de graphisme. Il suffit de modifier la feuille css.
Ceci dit, je ne les utilise pas car je préfère 100 fois la librairie
struts-layout, qui, elle, me fait gagner un temps énorme (à condition
d'avoir la charte *avant*) une fois que j'ai créé mes propres tags
graphiques, basés sur ceux de struts-layout mais améliorés pour intégrer ma
charte.

Personnellement, je n'ai jamais vu un infographiste travailler des pages
JSP. Et jamais je ne laisserai un graphiste toucher à mes pages. Il bosse de
son coté, et j'intègre et je découpe ses pages comme je veux. Plus
j'encapsule, mieux c'est.

Il y aurait pas un peu de zèle de la part des développeurs Struts?
ils ont réussit à encapsuler la couche HTML (!!??)

idem, ce n'est pas génant. Au contraire.
Ceci dit, je trouve que les balises HTML de struts n'ont que très peu
d'interet car elle
Struts-layout en fait beaucoup plus.
Actuellement, meme pour une page très complexe, je ne crache *aucune* ligne
HTML. Mes écrans sont parfaits. C'est pratique quand on travaille 6 mois-1
an sur le meme projet, sans que la charte graphique ne bouge. Et tu peux pas
imaginer à quel point ca change la vie quand on code les JSP...

Qu'entends tu par statique?non orienté objet?

statique = non dynamique.
Dnas mes sites, de nombreux champs ont des types qui changent en fonction de
certains paramètres calculés (string, float, int, date, required ou pas,
length....). Je ne voit pas trop comment utiliser les validatorForm pour
valider ce genre de chose car il faut tout déclarer "en dur" dans un fichier
xml....
Bref, ca n'a aucun interet.

Moi ce qui me gêne c'est de laisser la logique de validation au
framework, aussi puissant soit t'il....

je ne vois pas ou est le problème. Tu lui dis ce qu'il doit valider et
comment. Et c'est lui qui valide...rien de choquant. Tu peux te concentrer
sur la partier métier, plutot que de passer du temps à écrire comment
valider.

tout cela avec une syntaxe
qu'un développeur Java peut avoir du mal à appréhender.

je n'ai toujours pas compris le problème avec la syntaxe...

http://www.application-servers.com/comments.do?reqCode=readComments&sid 03

-03-23-22:17:22

J'avais lu cette article il y a longtemps. Je suis entièrement d'accord sur
le fait qu'il faut impérativement développer une couche au dessus de struts.
Mais une fois que c'est fait, je trouve que c'est très agréable.
Je maintiens que l'utilisation de struts+struts-layout+hibernate permet de
gagner énormément de temps sur les développements, une fois qu'on a écrit la
couche de base.
Je ne suis pas d'accord avec le reste.
D'ailleurs as-tu lu la réponse faite à cet article, qui elle, est pleine de
bon sens ?
<http://www.application-servers.com/links.do?reqCode=showLink&lid73>


Sinon, puisque tu connais ce site, tu devrais également connaitre
http://struts.application-servers.com/