Tapisserie Apache - Architecture

Tapestry essaie d'utiliser autant que possible les fonctionnalités disponibles de Java. Par exemple, toutes les pages Tapestry sont simplement des POJO. Il n'applique aucune interface personnalisée ou classe de base pour écrire l'application. Au lieu de cela, il utilise Annotation (une option légère pour étendre les fonctionnalités d'une classe Java) pour fournir des fonctionnalités. Il est basé sur des tests de combatJava Servlet APIet est implémenté en tant que filtre de servlet. Il donne une nouvelle dimension à l'application Web et la programmation est assez simple, flexible, compréhensible et robuste.

Flux de travail

Discutons de la séquence d'action qui se déroule lorsqu'une page de tapisserie est demandée.

Step 1 - Le Java Servletreçoit la demande de page. Ce servlet Java est configuré de manière à ce que la requête entrante soit transmise à tapestry. La configuration se fait dans leweb.xmlcomme spécifié dans le programme suivant. La balise Filter and Filter Mapping redirige toute la demande vers Tapestry Filter .

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" 
   "http://java.sun.com/dtd/web-app_2_3.dtd"> 
<web-app> 
   <display-name>My Tapestry Application</display-name> 
   <context-param> 
      <param-name>tapestry.app-package</param-name> 
      <param-value>org.example.myapp</param-value> 
   </context-param> 
   <filter> 
      <filter-name>app</filter-name> 
      <filter-class>org.apache.tapestry5.TapestryFilter</filter-class> 
   </filter> 
   <filter-mapping> 
      <filter-name>app</filter-name> 
      <url-pattern>/*</url-pattern> 
   </filter-mapping> 
</web-app>

Step 2 - Le Tapestry Filter appelle le HttpServletRequestHandler Service par ses Service() méthode.

Step 3 - HttpServletRequestHandler stocke la demande et la réponse dans RequestGlobals. Il encapsule également la demande et la réponse en tant qu'objet Request and Response et l'envoie au RequestHandler.

Step 4 - Le RequestHandler est une abstraction en plus de HttpServletRequestde l'API Servlet. Une partie des traits saillants de la tapisserie se fait enRequestHandlersection. La fonctionnalité de tapisserie peut être étendue en écrivant un filtre dans RequestHandler. RequestHandler fournit plusieurs filtres intégrés, qui incluent -

  • CheckForUpdates Filter- Responsable du rechargement des classes en direct. Ce filtre vérifie les modifications des classes Java et met à jour l'application si nécessaire.

  • Localization Filter - Identifiez l'emplacement de l'utilisateur et fournissez un support de localisation pour l'application.

  • StaticFiles Filter- Identifiez la requête statique et abandonnez le processus. Une fois le processus abandonné, Java Servlet prend le contrôle et traite la demande.

  • Error Filter - Attrape l'exception non interceptée et présente la page de rapport d'exception.

Le RequestHandler modifie et stocke également la demande et la réponse dans RequestQlobals et appelle le service MasterDispatcher.

Step 5 - Le MasterDispatcherest responsable du rendu de la page en appelant plusieurs répartiteurs est une commande spécifique. Les quatre principaux répartiteurs appelés par MasterDispatcher sont les suivants:

  • RootPath Dispatcher - Il reconnaît le chemin racine «/» de la requête et rend le même que la page de démarrage.

  • Asset Dispatcher - Il a reconnu la demande d'actif (actifs Java) en vérifiant le modèle d'url / actifs / et envoie les actifs demandés sous forme de flux d'octets.

  • PageRender Dispatcher- La plupart des opérations de tapisserie sont effectuées dans PageRender Dispatcher et dans le répartiteur de composants suivant. Ce répartiteur reconnaît la page particulière de cette demande et son contexte d'activation (informations supplémentaires). Il rend ensuite cette page particulière et l'envoie au client. Par exemple, si l'URL de la demande est / product / 12123434, le répartiteur vérifiera si une classe portant le nom product / 12123434 est disponible. S'il est trouvé, il appelle la classe product / 12123434, génère la réponse et l'envoie au client. Sinon, il vérifie la classe de produit. S'il est trouvé, il appelle la classe de produit avec des informations supplémentaires 121234434, génère la réponse et l'envoie au client. Ces informations supplémentaires sont appelées contexte d'activation. Si aucune classe n'est trouvée, il transmet simplement la demande au répartiteur de composants.

  • Component Dispatcher- Le répartiteur de composants correspond à l'URL de la page avec le modèle - / <nom_classe> / <id_composant>: <type_événement> / <contexte_activation> Par exemple, / product / grid: sort / asc représente la classe de produit, le composant de grille, le type sortevent et le contexte d'activation asc. Ici, event_type est facultatif et si aucun n'est fourni, l'action de type d'événement par défaut sera déclenchée. Habituellement, la réponse du répartiteur de composants est d'envoyer une redirection vers le client. La plupart du temps, la redirection correspondra à PageRender Dispatcher dans la prochaine requête et une réponse appropriée sera envoyée au client.