Je cherche a savoir comment je pourrais faire de manière la plus
réutilisable une implémentation d'un tableau sur plusieurs pages.
Avec MySQL la solution est relativement simple avec la
clause LIMIT mais pour les autres SGDB ...
Je cherche a savoir comment je pourrais faire de manière la plus
réutilisable une implémentation d'un tableau sur plusieurs pages.
Avec MySQL la solution est relativement simple avec la
clause LIMIT mais pour les autres SGDB ...
Je cherche a savoir comment je pourrais faire de manière la plus
réutilisable une implémentation d'un tableau sur plusieurs pages.
Avec MySQL la solution est relativement simple avec la
clause LIMIT mais pour les autres SGDB ...
Je cherche a savoir comment je pourrais faire de manière la plus
réutilisable une implémentation d'un tableau sur plusieurs pages.
Les données étant recherchées dans une base de données qui n'est pas
nécessairement MySQL. Avec MySQL la solution est relativement simple avec la
clause LIMIT mais pour les autres SGDB ...
Je vous remercie pour vos remarques éclairées.
Je cherche a savoir comment je pourrais faire de manière la plus
réutilisable une implémentation d'un tableau sur plusieurs pages.
Les données étant recherchées dans une base de données qui n'est pas
nécessairement MySQL. Avec MySQL la solution est relativement simple avec la
clause LIMIT mais pour les autres SGDB ...
Je vous remercie pour vos remarques éclairées.
Je cherche a savoir comment je pourrais faire de manière la plus
réutilisable une implémentation d'un tableau sur plusieurs pages.
Les données étant recherchées dans une base de données qui n'est pas
nécessairement MySQL. Avec MySQL la solution est relativement simple avec la
clause LIMIT mais pour les autres SGDB ...
Je vous remercie pour vos remarques éclairées.
Avec MySQL la solution est relativement simple avec la clause LIMIT
mais pour les autres SGDB ...
MySQL et PostGreSQL utilise 'LIMIT'
MS SQL Server définit "SELECT TOP nn"
Interbase définit 'ROWS'
il n'y a presque que Oracle qui ne permettent de limiter le nombre de
réponses.
Avec MySQL la solution est relativement simple avec la clause LIMIT
mais pour les autres SGDB ...
MySQL et PostGreSQL utilise 'LIMIT'
MS SQL Server définit "SELECT TOP nn"
Interbase définit 'ROWS'
il n'y a presque que Oracle qui ne permettent de limiter le nombre de
réponses.
Avec MySQL la solution est relativement simple avec la clause LIMIT
mais pour les autres SGDB ...
MySQL et PostGreSQL utilise 'LIMIT'
MS SQL Server définit "SELECT TOP nn"
Interbase définit 'ROWS'
il n'y a presque que Oracle qui ne permettent de limiter le nombre de
réponses.
Bernard Koninckx wrote:Je cherche a savoir comment je pourrais faire de manière la plus
réutilisable une implémentation d'un tableau sur plusieurs pages.
Les données étant recherchées dans une base de données qui n'est pas
nécessairement MySQL. Avec MySQL la solution est relativement simple avec
la
clause LIMIT mais pour les autres SGDB ...
Je vous remercie pour vos remarques éclairées.
In fine, c'est pour faire quoi ? Une interface web ? Un client riche ?
Si c'est pour une interface web, voir du côté du composant @Table de
Tapestry, il fait ça très bien, et pas besoin de limiter les résultats
de la requête en base.
--
Christophe Franco
Bernard Koninckx <koninckxbernard@___hotmail.com> wrote:
Je cherche a savoir comment je pourrais faire de manière la plus
réutilisable une implémentation d'un tableau sur plusieurs pages.
Les données étant recherchées dans une base de données qui n'est pas
nécessairement MySQL. Avec MySQL la solution est relativement simple avec
la
clause LIMIT mais pour les autres SGDB ...
Je vous remercie pour vos remarques éclairées.
In fine, c'est pour faire quoi ? Une interface web ? Un client riche ?
Si c'est pour une interface web, voir du côté du composant @Table de
Tapestry, il fait ça très bien, et pas besoin de limiter les résultats
de la requête en base.
--
Christophe Franco
Bernard Koninckx wrote:Je cherche a savoir comment je pourrais faire de manière la plus
réutilisable une implémentation d'un tableau sur plusieurs pages.
Les données étant recherchées dans une base de données qui n'est pas
nécessairement MySQL. Avec MySQL la solution est relativement simple avec
la
clause LIMIT mais pour les autres SGDB ...
Je vous remercie pour vos remarques éclairées.
In fine, c'est pour faire quoi ? Une interface web ? Un client riche ?
Si c'est pour une interface web, voir du côté du composant @Table de
Tapestry, il fait ça très bien, et pas besoin de limiter les résultats
de la requête en base.
--
Christophe Franco
Oui, c'est pour du client Web. Je ne connais pas du tout Tapestry ...
Chaqune de vos informations mérite que je me pense dessus.
Petite question, en passant, la technologie Tapestry est-elle fortement
utilisée au niveau professionnel ?
Oui, c'est pour du client Web. Je ne connais pas du tout Tapestry ...
Chaqune de vos informations mérite que je me pense dessus.
Petite question, en passant, la technologie Tapestry est-elle fortement
utilisée au niveau professionnel ?
Oui, c'est pour du client Web. Je ne connais pas du tout Tapestry ...
Chaqune de vos informations mérite que je me pense dessus.
Petite question, en passant, la technologie Tapestry est-elle fortement
utilisée au niveau professionnel ?
Bernard Koninckx wrote:Oui, c'est pour du client Web. Je ne connais pas du tout Tapestry ...
Chaqune de vos informations mérite que je me pense dessus.
http://tapestry.apache.org/
Et le composant Table :
<http://tapestry.apache.org/tapestry4.1/tapestry-contrib/componentrefere
nce/table.html>Petite question, en passant, la technologie Tapestry est-elle fortement
utilisée au niveau professionnel ?
Oui, elle l'est. Elle est beaucoup utilisée dans la réalisation
d'intranets d'entreprises, et de plus en plus utilisée pour de grands
sites instituionnels ou commerciaux, à fort traffic. Il y a notamment le
site de la NHL, zillow.com (site immobilier américain, un peu
l'équivalent de seloger.com), un site de Brother, ou encore
TheServerSide.com qui sont totalement réalisés avec Tapestry, mais aussi
Google et ebay qui utilisent Tapestry sur certaines parties de leurs
sites (notamment pour shopping.com en ce qui concerne ebay). Plus bien
sûr beaucoup de sites moins célèbres, mais il est bien sûr difficile de
"déceler" les sites réalisés avec Tapestry quand ces sites ne
l'indiquent pas eux-mêmes...
Personnellement, je développe depuis plusieurs années une application
intranet sous Tapestry pour un gros client dans le domaine pétrolier, et
j'ai un client pour qui je fais du conseil qui travaille sur des
solutions de gestion de produits pour réaliser des catalogues pour
l'industrie et la distribution (leurs applications web utilisant très
massivement les tableaux multi-pages, quand il s'agit de gérer des
listes de produits pouvant atteindre plusieurs centaines de milliers de
références. Ca tourne très très bien, il faut juste bien sûr adapter la
mémoire du conteneur de servlets en fonction de la charge à gérer)
Après, la seule chose qu'il y a, c'est qu'en l'état actuel des choses,
la documentation sur Tapestry est essentiellement online, il y a eu un
livre publié chez Manning par l'organisateur du projet, mais ça date de
la version 3, or depuis la version 4 il y a eu énormément de changements
dans le framework (c'est un peu le gros problème du framework, et sa
force en même temps, c'est qu'ils n'hésitent pas à remettre beaucoup de
choses en question pour améliorer quand ils le peuvent, quitte à ne pas
offrir beaucoup de compatibilité entre les versions), donc ce livre
n'est plus tellement d'actualité. Tu as cependant de plus en plus de
livres plus généralistes sur le développement web avec Java, sur le
développement Ajax aussi, qui incluent des chapitres sur Tapestry. Je
pense notamment à :
- Art of Java Development (Manning)
- Begining POJOs, From Novice to Professional (APress) (cela dit, c'est
un peu Monsieur Jourdain faisant de la prose...)
- Pro Ajax and Java (APress)
--
Christophe Franco
Bernard Koninckx <koninckxbernard@___hotmail.com> wrote:
Oui, c'est pour du client Web. Je ne connais pas du tout Tapestry ...
Chaqune de vos informations mérite que je me pense dessus.
http://tapestry.apache.org/
Et le composant Table :
<http://tapestry.apache.org/tapestry4.1/tapestry-contrib/componentrefere
nce/table.html>
Petite question, en passant, la technologie Tapestry est-elle fortement
utilisée au niveau professionnel ?
Oui, elle l'est. Elle est beaucoup utilisée dans la réalisation
d'intranets d'entreprises, et de plus en plus utilisée pour de grands
sites instituionnels ou commerciaux, à fort traffic. Il y a notamment le
site de la NHL, zillow.com (site immobilier américain, un peu
l'équivalent de seloger.com), un site de Brother, ou encore
TheServerSide.com qui sont totalement réalisés avec Tapestry, mais aussi
Google et ebay qui utilisent Tapestry sur certaines parties de leurs
sites (notamment pour shopping.com en ce qui concerne ebay). Plus bien
sûr beaucoup de sites moins célèbres, mais il est bien sûr difficile de
"déceler" les sites réalisés avec Tapestry quand ces sites ne
l'indiquent pas eux-mêmes...
Personnellement, je développe depuis plusieurs années une application
intranet sous Tapestry pour un gros client dans le domaine pétrolier, et
j'ai un client pour qui je fais du conseil qui travaille sur des
solutions de gestion de produits pour réaliser des catalogues pour
l'industrie et la distribution (leurs applications web utilisant très
massivement les tableaux multi-pages, quand il s'agit de gérer des
listes de produits pouvant atteindre plusieurs centaines de milliers de
références. Ca tourne très très bien, il faut juste bien sûr adapter la
mémoire du conteneur de servlets en fonction de la charge à gérer)
Après, la seule chose qu'il y a, c'est qu'en l'état actuel des choses,
la documentation sur Tapestry est essentiellement online, il y a eu un
livre publié chez Manning par l'organisateur du projet, mais ça date de
la version 3, or depuis la version 4 il y a eu énormément de changements
dans le framework (c'est un peu le gros problème du framework, et sa
force en même temps, c'est qu'ils n'hésitent pas à remettre beaucoup de
choses en question pour améliorer quand ils le peuvent, quitte à ne pas
offrir beaucoup de compatibilité entre les versions), donc ce livre
n'est plus tellement d'actualité. Tu as cependant de plus en plus de
livres plus généralistes sur le développement web avec Java, sur le
développement Ajax aussi, qui incluent des chapitres sur Tapestry. Je
pense notamment à :
- Art of Java Development (Manning)
- Begining POJOs, From Novice to Professional (APress) (cela dit, c'est
un peu Monsieur Jourdain faisant de la prose...)
- Pro Ajax and Java (APress)
--
Christophe Franco
Bernard Koninckx wrote:Oui, c'est pour du client Web. Je ne connais pas du tout Tapestry ...
Chaqune de vos informations mérite que je me pense dessus.
http://tapestry.apache.org/
Et le composant Table :
<http://tapestry.apache.org/tapestry4.1/tapestry-contrib/componentrefere
nce/table.html>Petite question, en passant, la technologie Tapestry est-elle fortement
utilisée au niveau professionnel ?
Oui, elle l'est. Elle est beaucoup utilisée dans la réalisation
d'intranets d'entreprises, et de plus en plus utilisée pour de grands
sites instituionnels ou commerciaux, à fort traffic. Il y a notamment le
site de la NHL, zillow.com (site immobilier américain, un peu
l'équivalent de seloger.com), un site de Brother, ou encore
TheServerSide.com qui sont totalement réalisés avec Tapestry, mais aussi
Google et ebay qui utilisent Tapestry sur certaines parties de leurs
sites (notamment pour shopping.com en ce qui concerne ebay). Plus bien
sûr beaucoup de sites moins célèbres, mais il est bien sûr difficile de
"déceler" les sites réalisés avec Tapestry quand ces sites ne
l'indiquent pas eux-mêmes...
Personnellement, je développe depuis plusieurs années une application
intranet sous Tapestry pour un gros client dans le domaine pétrolier, et
j'ai un client pour qui je fais du conseil qui travaille sur des
solutions de gestion de produits pour réaliser des catalogues pour
l'industrie et la distribution (leurs applications web utilisant très
massivement les tableaux multi-pages, quand il s'agit de gérer des
listes de produits pouvant atteindre plusieurs centaines de milliers de
références. Ca tourne très très bien, il faut juste bien sûr adapter la
mémoire du conteneur de servlets en fonction de la charge à gérer)
Après, la seule chose qu'il y a, c'est qu'en l'état actuel des choses,
la documentation sur Tapestry est essentiellement online, il y a eu un
livre publié chez Manning par l'organisateur du projet, mais ça date de
la version 3, or depuis la version 4 il y a eu énormément de changements
dans le framework (c'est un peu le gros problème du framework, et sa
force en même temps, c'est qu'ils n'hésitent pas à remettre beaucoup de
choses en question pour améliorer quand ils le peuvent, quitte à ne pas
offrir beaucoup de compatibilité entre les versions), donc ce livre
n'est plus tellement d'actualité. Tu as cependant de plus en plus de
livres plus généralistes sur le développement web avec Java, sur le
développement Ajax aussi, qui incluent des chapitres sur Tapestry. Je
pense notamment à :
- Art of Java Development (Manning)
- Begining POJOs, From Novice to Professional (APress) (cela dit, c'est
un peu Monsieur Jourdain faisant de la prose...)
- Pro Ajax and Java (APress)
--
Christophe Franco
Bernard Koninckx wrote:Oui, c'est pour du client Web. Je ne connais pas du tout Tapestry ...
Chaqune de vos informations mérite que je me pense dessus.
http://tapestry.apache.org/
Et le composant Table :
<http://tapestry.apache.org/tapestry4.1/tapestry-contrib/componentrefere
nce/table.html>Petite question, en passant, la technologie Tapestry est-elle fortement
utilisée au niveau professionnel ?
Oui, elle l'est. Elle est beaucoup utilisée dans la réalisation
d'intranets d'entreprises, et de plus en plus utilisée pour de grands
sites instituionnels ou commerciaux, à fort traffic. Il y a notamment le
site de la NHL, zillow.com (site immobilier américain, un peu
l'équivalent de seloger.com), un site de Brother, ou encore
TheServerSide.com qui sont totalement réalisés avec Tapestry, mais aussi
Google et ebay qui utilisent Tapestry sur certaines parties de leurs
sites (notamment pour shopping.com en ce qui concerne ebay). Plus bien
sûr beaucoup de sites moins célèbres, mais il est bien sûr difficile de
"déceler" les sites réalisés avec Tapestry quand ces sites ne
l'indiquent pas eux-mêmes...
Personnellement, je développe depuis plusieurs années une application
intranet sous Tapestry pour un gros client dans le domaine pétrolier, et
j'ai un client pour qui je fais du conseil qui travaille sur des
solutions de gestion de produits pour réaliser des catalogues pour
l'industrie et la distribution (leurs applications web utilisant très
massivement les tableaux multi-pages, quand il s'agit de gérer des
listes de produits pouvant atteindre plusieurs centaines de milliers de
références. Ca tourne très très bien, il faut juste bien sûr adapter la
mémoire du conteneur de servlets en fonction de la charge à gérer)
Après, la seule chose qu'il y a, c'est qu'en l'état actuel des choses,
la documentation sur Tapestry est essentiellement online, il y a eu un
livre publié chez Manning par l'organisateur du projet, mais ça date de
la version 3, or depuis la version 4 il y a eu énormément de changements
dans le framework (c'est un peu le gros problème du framework, et sa
force en même temps, c'est qu'ils n'hésitent pas à remettre beaucoup de
choses en question pour améliorer quand ils le peuvent, quitte à ne pas
offrir beaucoup de compatibilité entre les versions), donc ce livre
n'est plus tellement d'actualité. Tu as cependant de plus en plus de
livres plus généralistes sur le développement web avec Java, sur le
développement Ajax aussi, qui incluent des chapitres sur Tapestry. Je
pense notamment à :
- Art of Java Development (Manning)
- Begining POJOs, From Novice to Professional (APress) (cela dit, c'est
un peu Monsieur Jourdain faisant de la prose...)
- Pro Ajax and Java (APress)
--
Christophe Franco
Bernard Koninckx <koninckxbernard@___hotmail.com> wrote:
Oui, c'est pour du client Web. Je ne connais pas du tout Tapestry ...
Chaqune de vos informations mérite que je me pense dessus.
http://tapestry.apache.org/
Et le composant Table :
<http://tapestry.apache.org/tapestry4.1/tapestry-contrib/componentrefere
nce/table.html>
Petite question, en passant, la technologie Tapestry est-elle fortement
utilisée au niveau professionnel ?
Oui, elle l'est. Elle est beaucoup utilisée dans la réalisation
d'intranets d'entreprises, et de plus en plus utilisée pour de grands
sites instituionnels ou commerciaux, à fort traffic. Il y a notamment le
site de la NHL, zillow.com (site immobilier américain, un peu
l'équivalent de seloger.com), un site de Brother, ou encore
TheServerSide.com qui sont totalement réalisés avec Tapestry, mais aussi
Google et ebay qui utilisent Tapestry sur certaines parties de leurs
sites (notamment pour shopping.com en ce qui concerne ebay). Plus bien
sûr beaucoup de sites moins célèbres, mais il est bien sûr difficile de
"déceler" les sites réalisés avec Tapestry quand ces sites ne
l'indiquent pas eux-mêmes...
Personnellement, je développe depuis plusieurs années une application
intranet sous Tapestry pour un gros client dans le domaine pétrolier, et
j'ai un client pour qui je fais du conseil qui travaille sur des
solutions de gestion de produits pour réaliser des catalogues pour
l'industrie et la distribution (leurs applications web utilisant très
massivement les tableaux multi-pages, quand il s'agit de gérer des
listes de produits pouvant atteindre plusieurs centaines de milliers de
références. Ca tourne très très bien, il faut juste bien sûr adapter la
mémoire du conteneur de servlets en fonction de la charge à gérer)
Après, la seule chose qu'il y a, c'est qu'en l'état actuel des choses,
la documentation sur Tapestry est essentiellement online, il y a eu un
livre publié chez Manning par l'organisateur du projet, mais ça date de
la version 3, or depuis la version 4 il y a eu énormément de changements
dans le framework (c'est un peu le gros problème du framework, et sa
force en même temps, c'est qu'ils n'hésitent pas à remettre beaucoup de
choses en question pour améliorer quand ils le peuvent, quitte à ne pas
offrir beaucoup de compatibilité entre les versions), donc ce livre
n'est plus tellement d'actualité. Tu as cependant de plus en plus de
livres plus généralistes sur le développement web avec Java, sur le
développement Ajax aussi, qui incluent des chapitres sur Tapestry. Je
pense notamment à :
- Art of Java Development (Manning)
- Begining POJOs, From Novice to Professional (APress) (cela dit, c'est
un peu Monsieur Jourdain faisant de la prose...)
- Pro Ajax and Java (APress)
--
Christophe Franco
Bernard Koninckx wrote:Oui, c'est pour du client Web. Je ne connais pas du tout Tapestry ...
Chaqune de vos informations mérite que je me pense dessus.
http://tapestry.apache.org/
Et le composant Table :
<http://tapestry.apache.org/tapestry4.1/tapestry-contrib/componentrefere
nce/table.html>Petite question, en passant, la technologie Tapestry est-elle fortement
utilisée au niveau professionnel ?
Oui, elle l'est. Elle est beaucoup utilisée dans la réalisation
d'intranets d'entreprises, et de plus en plus utilisée pour de grands
sites instituionnels ou commerciaux, à fort traffic. Il y a notamment le
site de la NHL, zillow.com (site immobilier américain, un peu
l'équivalent de seloger.com), un site de Brother, ou encore
TheServerSide.com qui sont totalement réalisés avec Tapestry, mais aussi
Google et ebay qui utilisent Tapestry sur certaines parties de leurs
sites (notamment pour shopping.com en ce qui concerne ebay). Plus bien
sûr beaucoup de sites moins célèbres, mais il est bien sûr difficile de
"déceler" les sites réalisés avec Tapestry quand ces sites ne
l'indiquent pas eux-mêmes...
Personnellement, je développe depuis plusieurs années une application
intranet sous Tapestry pour un gros client dans le domaine pétrolier, et
j'ai un client pour qui je fais du conseil qui travaille sur des
solutions de gestion de produits pour réaliser des catalogues pour
l'industrie et la distribution (leurs applications web utilisant très
massivement les tableaux multi-pages, quand il s'agit de gérer des
listes de produits pouvant atteindre plusieurs centaines de milliers de
références. Ca tourne très très bien, il faut juste bien sûr adapter la
mémoire du conteneur de servlets en fonction de la charge à gérer)
Après, la seule chose qu'il y a, c'est qu'en l'état actuel des choses,
la documentation sur Tapestry est essentiellement online, il y a eu un
livre publié chez Manning par l'organisateur du projet, mais ça date de
la version 3, or depuis la version 4 il y a eu énormément de changements
dans le framework (c'est un peu le gros problème du framework, et sa
force en même temps, c'est qu'ils n'hésitent pas à remettre beaucoup de
choses en question pour améliorer quand ils le peuvent, quitte à ne pas
offrir beaucoup de compatibilité entre les versions), donc ce livre
n'est plus tellement d'actualité. Tu as cependant de plus en plus de
livres plus généralistes sur le développement web avec Java, sur le
développement Ajax aussi, qui incluent des chapitres sur Tapestry. Je
pense notamment à :
- Art of Java Development (Manning)
- Begining POJOs, From Novice to Professional (APress) (cela dit, c'est
un peu Monsieur Jourdain faisant de la prose...)
- Pro Ajax and Java (APress)
--
Christophe Franco
Si j'ai bien compris c'est du MVC ... avec une Servlet Contrôleur et tout le
toutim ?
La solution ne risque-t-elle pas de tomber en "désuétude" ?
Que faire par rapport a des standards mis en place par Sun comme les JSF ?
Si j'ai bien compris c'est du MVC ... avec une Servlet Contrôleur et tout le
toutim ?
La solution ne risque-t-elle pas de tomber en "désuétude" ?
Que faire par rapport a des standards mis en place par Sun comme les JSF ?
Si j'ai bien compris c'est du MVC ... avec une Servlet Contrôleur et tout le
toutim ?
La solution ne risque-t-elle pas de tomber en "désuétude" ?
Que faire par rapport a des standards mis en place par Sun comme les JSF ?
Bernard Koninckx wrote:Si j'ai bien compris c'est du MVC ... avec une Servlet Contrôleur et tout
le
toutim ?
La solution ne risque-t-elle pas de tomber en "désuétude" ?
Que faire par rapport a des standards mis en place par Sun comme les JSF
?
C'est un risque effectivement, mais c'est un peu la même problématique
si on regarde JDO par rapport à Hibernate, et le moins qu'on puisse dire
c'est que c'est plutôt JDO qui est tombé en désuétude à peine lancé, et
Hibernate qui s'impose comme le standard de fait.
La différence, c'est que dans le domaine des frameworks web, il n'y a
jamais eu de standard de fait, même si beaucoup ont poussé derrière
Struts dans cet espoir, en vain (et même si dans la pratique, l'esprit
de Struts s'est un peu transmis à JSF...)
La chose qui fait que personnellement je suis beaucoup plus derrière un
projet comme Tapestry, c'est qu'il permet de découpler presque
totalement la partie HTML de la partie Java (surtout à partir de la
version 4, et ce sera encore plus le cas dans la version 5), laissant
donc beaucoup plus de facilités pour répartir les rôles dans une équipe
de développement où tout le monde n'a pas forcément les mêmes
compétences. Chez un de mes clients qui travaille avec Tapestry, toute
la partie HTML/CSS est confiée à un développeur qui n'a jamais fait de
Java de sa vie, et ça ne pose aucun problème. Notamment parce qu'il
peut, avec certaines limites certes, visualiser ses modèles de pages
comme de simples pages HTML. Je n'ose imaginer arriver à une telle
organisation avec JSF.
C'est particulièrement important si tu envisages une application
massivement Ajax, car l'on sait bien que très souvent les développeurs
Java rechigneront à se "salir les mains" à faire du Javascript, alors
qu'à côté de ça il y a plétore de développeurs "web" qui n'entendent
rien à Java... Réussir à faire travailler ensemble ce genre de "frères
ennemis" n'est pas le moindre des mérites de Tapestry...
En outre, avec Tapestry, un développeur débutant peut commencer
progressivement, en travaillant sur l'écriture de composants, laissant
l'agencement des composants en pages à des développeurs plus
expérimentés. Et il pourra progresser vers le développement de pages
complètes assez facilement, vu qu'il y a assez peu de différences
techniques entre pages et composants. Avec JSF, composants et pages sont
des concepts très différents, et pour bien développer il faut maîtriser
les deux. Le saut technologique est plus important, il demandera
probablement plus de formation.
L'inconvénient, c'est que le cycle de fonctionnement du moteur de
Tapestry est peut-être un peu plus difficile à comprendre,
essentiellement en raison d'une pénurie de documentation
quasi-chronique.
Après, il y a un dernier point que beaucoup prendront en compte, c'est
l'intérêt vis-à-vis de leur carrière personnelle. Il est clair que
pendant longtemps, il n'y avait pas trop à se poser de questions, pour
un développeur Java il était assez évident que développer avec Struts
permettait de se construire un CV garantissant une facilité de retrouver
du boulot à peu près n'importe où. Aujourd'hui, Struts est en perte de
vitesse, et même si bien sûr il y a une grande base installée et on
cherchera encore des développeurs connaissant Struts pendant un bon
moment (notamment pour... migrer des applications vers d'autres
frameworks...), il n'est pas aussi clair de trancher entre tout ce qui
existe à l'heure actuelle (car JSF et Tapestry sont bien sûr loin d'être
en position dominante).
En fait, il n'y a guère de framework qui soit en position dominante
actuellement, notamment pas JSF... quant à Tapestry, c'est évidemment un
choix encore très spécialisé, pour lequel il ne faudra pas espérer
retrouver facilement un emploi ou des missions du jour au lendemain,
surtout si on n'est pas mobile (et j'oserais dire, surtout en
France...). Cela veut dire aussi que par conséquent, il faut être
réaliste, si on est en position de recruteur, on ne trouve pas
actuellement de développeurs estampillés "Tapestry" disponibles du jour
au lendemain (en France toujours, parce après si on est prêt à
sous-traiter à l'étranger ça peut se faire, il y a souvent des gens qui
proposent leurs services sur les mailings-lists de Tapestry), il y a
nécessairement un effort de formation à faire lors des recrutements, et
ce serait illusoire de rechercher des développeurs déjà compétents et
immédiatement productifs (mais c'est sûr aussi que si on en trouve un,
c'est la perle rare...)
Donc au final, je pense qu'on ne peut pas avoir de réponse vraiment
tranchée. En particulier, pas avec l'argument "JSF est le standard de
Sun", parce que justement les exemples ne manquent pas de domaines où la
technologie poussée comme "le" standard n'a pas pris le dessus par
rapport à une ou plusieurs technologies de tierce partie. Ce qu'on sent,
c'est qu'il y a un mouvement assez fort qui pousse du côté de Tapestry,
qui a commencé lorsque Apache a commencé à soutenir le projet, et qui
s'est amplifié avec la version 4. Il y a aussi un mouvement qui pousse
du côté de JSF. Les deux sont en train de monter, dans un marché qui est
extrèmement morcellé et où de plus gros acteurs comme IBM, SAP,
Oracle... voudraient bien aussi leur part du gâteau.
--
Christophe Franco
Bernard Koninckx <koninckxbernard@___hotmail.com> wrote:
Si j'ai bien compris c'est du MVC ... avec une Servlet Contrôleur et tout
le
toutim ?
La solution ne risque-t-elle pas de tomber en "désuétude" ?
Que faire par rapport a des standards mis en place par Sun comme les JSF
?
C'est un risque effectivement, mais c'est un peu la même problématique
si on regarde JDO par rapport à Hibernate, et le moins qu'on puisse dire
c'est que c'est plutôt JDO qui est tombé en désuétude à peine lancé, et
Hibernate qui s'impose comme le standard de fait.
La différence, c'est que dans le domaine des frameworks web, il n'y a
jamais eu de standard de fait, même si beaucoup ont poussé derrière
Struts dans cet espoir, en vain (et même si dans la pratique, l'esprit
de Struts s'est un peu transmis à JSF...)
La chose qui fait que personnellement je suis beaucoup plus derrière un
projet comme Tapestry, c'est qu'il permet de découpler presque
totalement la partie HTML de la partie Java (surtout à partir de la
version 4, et ce sera encore plus le cas dans la version 5), laissant
donc beaucoup plus de facilités pour répartir les rôles dans une équipe
de développement où tout le monde n'a pas forcément les mêmes
compétences. Chez un de mes clients qui travaille avec Tapestry, toute
la partie HTML/CSS est confiée à un développeur qui n'a jamais fait de
Java de sa vie, et ça ne pose aucun problème. Notamment parce qu'il
peut, avec certaines limites certes, visualiser ses modèles de pages
comme de simples pages HTML. Je n'ose imaginer arriver à une telle
organisation avec JSF.
C'est particulièrement important si tu envisages une application
massivement Ajax, car l'on sait bien que très souvent les développeurs
Java rechigneront à se "salir les mains" à faire du Javascript, alors
qu'à côté de ça il y a plétore de développeurs "web" qui n'entendent
rien à Java... Réussir à faire travailler ensemble ce genre de "frères
ennemis" n'est pas le moindre des mérites de Tapestry...
En outre, avec Tapestry, un développeur débutant peut commencer
progressivement, en travaillant sur l'écriture de composants, laissant
l'agencement des composants en pages à des développeurs plus
expérimentés. Et il pourra progresser vers le développement de pages
complètes assez facilement, vu qu'il y a assez peu de différences
techniques entre pages et composants. Avec JSF, composants et pages sont
des concepts très différents, et pour bien développer il faut maîtriser
les deux. Le saut technologique est plus important, il demandera
probablement plus de formation.
L'inconvénient, c'est que le cycle de fonctionnement du moteur de
Tapestry est peut-être un peu plus difficile à comprendre,
essentiellement en raison d'une pénurie de documentation
quasi-chronique.
Après, il y a un dernier point que beaucoup prendront en compte, c'est
l'intérêt vis-à-vis de leur carrière personnelle. Il est clair que
pendant longtemps, il n'y avait pas trop à se poser de questions, pour
un développeur Java il était assez évident que développer avec Struts
permettait de se construire un CV garantissant une facilité de retrouver
du boulot à peu près n'importe où. Aujourd'hui, Struts est en perte de
vitesse, et même si bien sûr il y a une grande base installée et on
cherchera encore des développeurs connaissant Struts pendant un bon
moment (notamment pour... migrer des applications vers d'autres
frameworks...), il n'est pas aussi clair de trancher entre tout ce qui
existe à l'heure actuelle (car JSF et Tapestry sont bien sûr loin d'être
en position dominante).
En fait, il n'y a guère de framework qui soit en position dominante
actuellement, notamment pas JSF... quant à Tapestry, c'est évidemment un
choix encore très spécialisé, pour lequel il ne faudra pas espérer
retrouver facilement un emploi ou des missions du jour au lendemain,
surtout si on n'est pas mobile (et j'oserais dire, surtout en
France...). Cela veut dire aussi que par conséquent, il faut être
réaliste, si on est en position de recruteur, on ne trouve pas
actuellement de développeurs estampillés "Tapestry" disponibles du jour
au lendemain (en France toujours, parce après si on est prêt à
sous-traiter à l'étranger ça peut se faire, il y a souvent des gens qui
proposent leurs services sur les mailings-lists de Tapestry), il y a
nécessairement un effort de formation à faire lors des recrutements, et
ce serait illusoire de rechercher des développeurs déjà compétents et
immédiatement productifs (mais c'est sûr aussi que si on en trouve un,
c'est la perle rare...)
Donc au final, je pense qu'on ne peut pas avoir de réponse vraiment
tranchée. En particulier, pas avec l'argument "JSF est le standard de
Sun", parce que justement les exemples ne manquent pas de domaines où la
technologie poussée comme "le" standard n'a pas pris le dessus par
rapport à une ou plusieurs technologies de tierce partie. Ce qu'on sent,
c'est qu'il y a un mouvement assez fort qui pousse du côté de Tapestry,
qui a commencé lorsque Apache a commencé à soutenir le projet, et qui
s'est amplifié avec la version 4. Il y a aussi un mouvement qui pousse
du côté de JSF. Les deux sont en train de monter, dans un marché qui est
extrèmement morcellé et où de plus gros acteurs comme IBM, SAP,
Oracle... voudraient bien aussi leur part du gâteau.
--
Christophe Franco
Bernard Koninckx wrote:Si j'ai bien compris c'est du MVC ... avec une Servlet Contrôleur et tout
le
toutim ?
La solution ne risque-t-elle pas de tomber en "désuétude" ?
Que faire par rapport a des standards mis en place par Sun comme les JSF
?
C'est un risque effectivement, mais c'est un peu la même problématique
si on regarde JDO par rapport à Hibernate, et le moins qu'on puisse dire
c'est que c'est plutôt JDO qui est tombé en désuétude à peine lancé, et
Hibernate qui s'impose comme le standard de fait.
La différence, c'est que dans le domaine des frameworks web, il n'y a
jamais eu de standard de fait, même si beaucoup ont poussé derrière
Struts dans cet espoir, en vain (et même si dans la pratique, l'esprit
de Struts s'est un peu transmis à JSF...)
La chose qui fait que personnellement je suis beaucoup plus derrière un
projet comme Tapestry, c'est qu'il permet de découpler presque
totalement la partie HTML de la partie Java (surtout à partir de la
version 4, et ce sera encore plus le cas dans la version 5), laissant
donc beaucoup plus de facilités pour répartir les rôles dans une équipe
de développement où tout le monde n'a pas forcément les mêmes
compétences. Chez un de mes clients qui travaille avec Tapestry, toute
la partie HTML/CSS est confiée à un développeur qui n'a jamais fait de
Java de sa vie, et ça ne pose aucun problème. Notamment parce qu'il
peut, avec certaines limites certes, visualiser ses modèles de pages
comme de simples pages HTML. Je n'ose imaginer arriver à une telle
organisation avec JSF.
C'est particulièrement important si tu envisages une application
massivement Ajax, car l'on sait bien que très souvent les développeurs
Java rechigneront à se "salir les mains" à faire du Javascript, alors
qu'à côté de ça il y a plétore de développeurs "web" qui n'entendent
rien à Java... Réussir à faire travailler ensemble ce genre de "frères
ennemis" n'est pas le moindre des mérites de Tapestry...
En outre, avec Tapestry, un développeur débutant peut commencer
progressivement, en travaillant sur l'écriture de composants, laissant
l'agencement des composants en pages à des développeurs plus
expérimentés. Et il pourra progresser vers le développement de pages
complètes assez facilement, vu qu'il y a assez peu de différences
techniques entre pages et composants. Avec JSF, composants et pages sont
des concepts très différents, et pour bien développer il faut maîtriser
les deux. Le saut technologique est plus important, il demandera
probablement plus de formation.
L'inconvénient, c'est que le cycle de fonctionnement du moteur de
Tapestry est peut-être un peu plus difficile à comprendre,
essentiellement en raison d'une pénurie de documentation
quasi-chronique.
Après, il y a un dernier point que beaucoup prendront en compte, c'est
l'intérêt vis-à-vis de leur carrière personnelle. Il est clair que
pendant longtemps, il n'y avait pas trop à se poser de questions, pour
un développeur Java il était assez évident que développer avec Struts
permettait de se construire un CV garantissant une facilité de retrouver
du boulot à peu près n'importe où. Aujourd'hui, Struts est en perte de
vitesse, et même si bien sûr il y a une grande base installée et on
cherchera encore des développeurs connaissant Struts pendant un bon
moment (notamment pour... migrer des applications vers d'autres
frameworks...), il n'est pas aussi clair de trancher entre tout ce qui
existe à l'heure actuelle (car JSF et Tapestry sont bien sûr loin d'être
en position dominante).
En fait, il n'y a guère de framework qui soit en position dominante
actuellement, notamment pas JSF... quant à Tapestry, c'est évidemment un
choix encore très spécialisé, pour lequel il ne faudra pas espérer
retrouver facilement un emploi ou des missions du jour au lendemain,
surtout si on n'est pas mobile (et j'oserais dire, surtout en
France...). Cela veut dire aussi que par conséquent, il faut être
réaliste, si on est en position de recruteur, on ne trouve pas
actuellement de développeurs estampillés "Tapestry" disponibles du jour
au lendemain (en France toujours, parce après si on est prêt à
sous-traiter à l'étranger ça peut se faire, il y a souvent des gens qui
proposent leurs services sur les mailings-lists de Tapestry), il y a
nécessairement un effort de formation à faire lors des recrutements, et
ce serait illusoire de rechercher des développeurs déjà compétents et
immédiatement productifs (mais c'est sûr aussi que si on en trouve un,
c'est la perle rare...)
Donc au final, je pense qu'on ne peut pas avoir de réponse vraiment
tranchée. En particulier, pas avec l'argument "JSF est le standard de
Sun", parce que justement les exemples ne manquent pas de domaines où la
technologie poussée comme "le" standard n'a pas pris le dessus par
rapport à une ou plusieurs technologies de tierce partie. Ce qu'on sent,
c'est qu'il y a un mouvement assez fort qui pousse du côté de Tapestry,
qui a commencé lorsque Apache a commencé à soutenir le projet, et qui
s'est amplifié avec la version 4. Il y a aussi un mouvement qui pousse
du côté de JSF. Les deux sont en train de monter, dans un marché qui est
extrèmement morcellé et où de plus gros acteurs comme IBM, SAP,
Oracle... voudraient bien aussi leur part du gâteau.
--
Christophe Franco
Pour info, Oracle permet de le faire ainsi:
select ... from ... where rownum < nn
Pour info, Oracle permet de le faire ainsi:
select ... from ... where rownum < nn
Pour info, Oracle permet de le faire ainsi:
select ... from ... where rownum < nn