Merci pour la réponse qui a dû vous prendre un peu de temps libre :-)
Je comprends mieux l'opposition que vous faites entre client riche (RPC) et client nouveau-riche (Ajax) ; opposition qui concerne clairement les usages actuels de ces deux méthodes. Le fait que vous vous placiez « dans le cadre de gens qui ont besoin de gérer beaucoup d'information en même temps (y compris sur plusieurs écrans) » est pour moi beaucoup plus clair que lorsque vous écrivez « fournir des fonctions ou une interface utilisateur plus riches que ce qu’on peut réaliser avec les technologies de clients légers ».
Le développement d'interfaces utilisateurs en client riche Java (qu'on utilise les techno Eclipse RCP, autrement dit SWT/JFaces ou les technos Sun comme Swing) reposent sur des concepts qui sont maintenant connus et maîtrisés depuis des années, alors que les interfaces riches en client Web (autrement dit Ajax) sont encore toutes récentes (2-3 ans), avec un foisonnement de bibliothèques et un outillage (support des IDE) encore moyen.
Je ne peux que confirmer ce point. Nos développements Ajax sont effectivement encore plus proche de l'artisanat que de l'industrialisation -- ils sont grisant mais coûteux. Ajax est une rustine qui se colle sur les technologies^Wstandards du web, c'est à la fois bien et mal : bien parce que ces standards sont d'une haute qualité sémantique (attention, je n'ai forcément pas dit technique...) et parce que, à terme, ils permettent un déploiement d'application bien moins cher que des interfaces riches comme Nuxeo : pensez donc, l'architecture web est déjà en place depuis 15 ans ! Mal parce qu'une rustine, ça se décolle, c'est pas facile à fabriquer, il y a 50 méthodes différentes, pas pérennes...
Donc, avec Ajax, développement difficile mais déploiement pas cher... et j'ai l'impression qu'avec les technologies Java, une fois passé le cap de l'apprentissage, c'est l'inverse.
C'est alors l'utilisateur qui départagera, selon l'expérience qu'il veut vivre (et ça rejoint totalement le début de mon commentaire, waow, je devrais écrire plus souvent à 1H20 un dimanche matin). Ça va être passionnant.
Au fait : est-ce que vous avez jeter un œil sur XUL, qui pourrait être un compromis intéressant ? Je crois d'ailleurs que le back-office du journal Le Monde est codé en XUL, ce qui fait un parallèle intéressant avec l'AFP.
[^] # Re: Coût d'une telle solution
Posté par Trois Singes . En réponse à la dépêche Nuxeo RCP 2.0 : plateforme client riche pour applications documentaires et multimédias. Évalué à 1.
Je comprends mieux l'opposition que vous faites entre client riche (RPC) et client nouveau-riche (Ajax) ; opposition qui concerne clairement les usages actuels de ces deux méthodes. Le fait que vous vous placiez « dans le cadre de gens qui ont besoin de gérer beaucoup d'information en même temps (y compris sur plusieurs écrans) » est pour moi beaucoup plus clair que lorsque vous écrivez « fournir des fonctions ou une interface utilisateur plus riches que ce qu’on peut réaliser avec les technologies de clients légers ».
Le développement d'interfaces utilisateurs en client riche Java (qu'on utilise les techno Eclipse RCP, autrement dit SWT/JFaces ou les technos Sun comme Swing) reposent sur des concepts qui sont maintenant connus et maîtrisés depuis des années, alors que les interfaces riches en client Web (autrement dit Ajax) sont encore toutes récentes (2-3 ans), avec un foisonnement de bibliothèques et un outillage (support des IDE) encore moyen.
Je ne peux que confirmer ce point. Nos développements Ajax sont effectivement encore plus proche de l'artisanat que de l'industrialisation -- ils sont grisant mais coûteux. Ajax est une rustine qui se colle sur les technologies^Wstandards du web, c'est à la fois bien et mal : bien parce que ces standards sont d'une haute qualité sémantique (attention, je n'ai forcément pas dit technique...) et parce que, à terme, ils permettent un déploiement d'application bien moins cher que des interfaces riches comme Nuxeo : pensez donc, l'architecture web est déjà en place depuis 15 ans ! Mal parce qu'une rustine, ça se décolle, c'est pas facile à fabriquer, il y a 50 méthodes différentes, pas pérennes...
Donc, avec Ajax, développement difficile mais déploiement pas cher... et j'ai l'impression qu'avec les technologies Java, une fois passé le cap de l'apprentissage, c'est l'inverse.
C'est alors l'utilisateur qui départagera, selon l'expérience qu'il veut vivre (et ça rejoint totalement le début de mon commentaire, waow, je devrais écrire plus souvent à 1H20 un dimanche matin). Ça va être passionnant.
Au fait : est-ce que vous avez jeter un œil sur XUL, qui pourrait être un compromis intéressant ? Je crois d'ailleurs que le back-office du journal Le Monde est codé en XUL, ce qui fait un parallèle intéressant avec l'AFP.