Une passion, la technologie.
Imaginez un environnement de travail qui valorise l'innovation technologique et la curiosité.
Imaginez un groupe où vous aurez l'opportunité de travailler et partager avec des gens parmi les plus talentueux.
Imaginez une culture et des valeurs en rupture avec les SSII.
Imaginez une société où vos talents et vos idées seront reconnus et encouragés.
Imaginez une organisation qui vous donne les moyens réels de travailler, de progresser, de réaliser vos projets personnels.
N'imaginez plus, vivez-le !
N'hésitez pas à nous contacter à travers le Formulaire de contact ou directement à l'adresse recrutement@xebia.fr.
ADDM Adobe Android annotation BEA développement Devoxx Eclipse ESB Exploitation Flash Flex Google Groovy GWT Hibernate IBM J2EE Java JavaFX jazoon JBoss jdk-7 JEE JPA JSF JVM Méthodes agiles Maven Oracle OSGi Paris JUG Performance RIA scala SCRUM SOA Spring SpringSource Sun Tomcat Websphere Wicket Xebia XP
Xebia est un groupe d'experts, exclusivement dédié aux technologies J2EE.
Sauf mention contraire, le contenu de ce blog est sous contrat Creative Commons.
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
RIA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Mettre au grenier la configuration XML et l’API J2EE, voilà le pari que tentent de relever les frameworks orientés composants. Pour atteindre ce but louable : simplifier la vie stressée du développeur et par là même sauver quelques-uns de ses cheveux, le XML est remplacé par du code Java et l’API J2EE est cachée dans les entrailles du framework. Les pages deviennent des objets Java liés à des templates, auxquels sont ajoutés des composants réutilisables (si, si). Les composants sont ni plus ni moins que d’autres objets Java liés à des templates. Les requêtes, quant à elles, deviennent des événements traités par les pages et les composants.
Voilà pour le principe de cette approche qui semble avoir de beaux jours devant elle. Emergence naturelle ou stratégie voulue, la fondation Apache, jamais avare de solutions, nous propose deux frameworks composants : Tapestry 5 et Wicket. Alors comment choisir ? Le mieux est encore de se faire sa propre idée en les testant tous les deux. Nous sommes bien d’accord, rien ne remplacera jamais l’efficacité du prototypage. Cela n’empêche pourtant pas de faire une pré-sélection basée sur quelques points de comparaisons stratégiques. Voici donc un article pour vous aider à faire le meilleur choix ; à savoir le choix qui répondra le mieux aux besoins et à l’environnement de votre projet.
Bien qu’adoptant tous deux la programmation web orientée composant, les deux projets sont imprégnés d’une philosophie et d’un objectif différents. Les buts principaux de Wicket sont :
Pour Tapestry 5, les objectifs sont différents :
Attention ! Ce sont là les objectifs sur lesquels les deux projets sont focalisés. Ce qui ne signifie pas qu’ils s’y intéressent exclusivement. Wicket supporte bien les composants sans état, ce n’est juste pas son but principal. De même que Tapestry supporte le développement web entièrement en objet Java.
Ils affichent, aussi, des buts communs, comme d’être orientés Pojo et d’éliminer la configuration XML avec le pattern Convention Over Configuration.
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
SOA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Agilité
RIA
Le coin de la technique
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Agilité
RIA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Dans les précédents articles sur Wicket, nous avons exploré les bases du framework. Nous allons nous intéresser maintenant à quelques fonctionnalités avancées comme le templating ou l’internationalisation.
Avec Wicket, même le templating est très simple. L’implémentation du templating dans Wicket est très proche de la façon de faire de SiteMesh (au moins pour la partie HTML). La mise en œuvre se fait par des mécanismes d’héritage : Wicket nomme ceci le Markup Inheritance. Prenons un exemple concret.
Wicket est un framework plutôt en rupture avec les frameworks web actuels. Ici pas de fichier XML qui définit la navigation, pas de librairies de tag spécifiques, juste de la simplicité et du pragmatisme … tout pour nous plaire ! Wicket a choisi de ne pas mélanger les genres : les pages se font en plain html et le développement, à proprement parler, se fait en pur Java.
Enfonçons-nous un peu dans les mécanismes du framework. Cette semaine, étudions la gestion de la session, la validation de formulaires et l’intégration (toujours aussi simple) avec SpringFramework.
Wicket est un framework plutôt en rupture avec les frameworks web actuels. Ici pas de fichier XML qui définit la navigation, pas de librairies de tag spécifiques, juste de la simplicité et du pragmatisme … tout pour nous plaire ! Wicket a choisi de ne pas mélanger les genres : les pages se font en plain html et le développement, à proprement parler, se fait en pur Java.
Dans le précédent billet, nous nous étions arrêtés à la mise en place d’un projet Wicket. Aujourd’hui, regardons de plus près la construction des pages et la façon d’implémenter la logique de navigation avec les formulaires et les liens.
Wicket est un framework plutôt en rupture avec les frameworks web actuels. Ici pas de fichier XML qui définit la navigation, pas de librairies de tags spécifiques, juste de la simplicité et du pragmatisme … tout pour nous plaire ! Wicket a choisi de ne pas mélanger les genres : les pages se font en pur html et le développement, à proprement parler, se fait en pur Java.
Dans cette première partie, nous verrons comment démarrer avec Wicket.
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
Agilité
Le coin de la technique
