From commits-return-4288-apmail-jackrabbit-commits-archive=jackrabbit.apache.org@jackrabbit.apache.org Tue Jul 10 09:38:16 2007 Return-Path: Delivered-To: apmail-jackrabbit-commits-archive@www.apache.org Received: (qmail 51520 invoked from network); 10 Jul 2007 09:38:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Jul 2007 09:38:15 -0000 Received: (qmail 78115 invoked by uid 500); 10 Jul 2007 09:38:18 -0000 Delivered-To: apmail-jackrabbit-commits-archive@jackrabbit.apache.org Received: (qmail 78064 invoked by uid 500); 10 Jul 2007 09:38:18 -0000 Mailing-List: contact commits-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list commits@jackrabbit.apache.org Received: (qmail 78042 invoked by uid 99); 10 Jul 2007 09:38:17 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Jul 2007 02:38:17 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.130] (HELO eos.apache.org) (140.211.11.130) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 10 Jul 2007 02:38:14 -0700 Received: from eos.apache.org (localhost [127.0.0.1]) by eos.apache.org (Postfix) with ESMTP id 426B059A07 for ; Tue, 10 Jul 2007 09:37:54 +0000 (GMT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Apache Wiki To: commits@jackrabbit.apache.org Date: Tue, 10 Jul 2007 09:37:54 -0000 Message-ID: <20070710093754.12274.61668@eos.apache.org> Subject: [Jackrabbit Wiki] Update of "ApacheSling/ComponentAPI" by FelixMeschberger X-Virus-Checked: Checked by ClamAV on apache.org Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification. The following page has been changed by FelixMeschberger: http://wiki.apache.org/jackrabbit/ApacheSling/ComponentAPI The comment on the change is: Add sections on Filters and Sessions ------------------------------------------------------------------------------ Content Resolution:: The Component Framework derives a Content instance from the client request URL. The details of how to resolve the Content data and how to instantiate and populate the object is outside the scope of this document. One possible solution would be to map the request URL to a [http://www.jcp.org/en/jsr/detail?id=170 Java Content Repository] Node and to use an object content mapping tool (e.g. [http://incubator.apache.org/graffito/jcr-mapping/index.html Jackrabbit Object Content Mapping]) to instantiate such an object. Component Resolution:: From the Content object created in the first step, the Component object is resolved from the Component ID retrieved from the Content object. The Component ID is a simple string, whose semantics is defined by the Component Framework. One possible definition could be for the Component ID to the fully qualified name of a class implementing the {{{Component}}} interface. - Input Processing and Response Generation:: After getting the Content and the Component, the =Component.service()= method is called to process any user supplied input and send the response to the client. To structure the rendered response page, this method is responsible to include other content. See [[#Dispatching_Requests][Dispatching Requests]] for details. See [[#Error_Handling][Error Handling]] below for a discussion how exceptions and HTTP stati are handled. + Input Processing and Response Generation:: After getting the Content and the Component, the =Component.service()= method is called to process any user supplied input and send the response to the client. To structure the rendered response page, this method is responsible to include other content. See ''Dispatching Requests'' below for details. See ''Error Handling'' below for a discussion on how exceptions and HTTP stati are handled. === URL decomposition === @@ -148, +148 @@ + == Request Processing Filters == + + Similar to the Servlet API providing filters for filtering requests and/or responses the Component API provides the {{{org.apache.sling.component.ComponentFilter}}} interface. The filters are called by a {{{ComponentFilterChain}}} and either handle the request, manipulate the request and/or response object and finally forward the request and response optionally wrapped to the {{{ComponentFilterChain.doFilter(ComponentRequest, ComponentResponse)}}} method. + + Like the {{{Component}}}s filters have a defined lifecycle manifested by {{{init}}} and {{{destroy}}} methods. When the filter enters the system, the Component Framework calls the {{{ComponentFilter.init(ComponentContext)}}} method. Only when this method completes successfully will the filter be put into action and be used during request processing. When the filter leaves the system, the Component Framework removes the filter from being used in filter chains and calls the {{{ComponentFilter.destroy()}}} method. This method is not expected to throw any exceptions. The filter may be removed from the Component Framework at the discretion of the Component Framework or because the filter is being unregistered from the Component Framework by some means outside this specification. + + This specification does not define how {{{ComponentFilter}}} objects are registered with the Component Framework nor is it specified how the order in which the filters are called is defined. Likewise it is outside this specification how the filter instances registered with the Component Framework are configured. + + + + == Sessions == + + + The {{{org.apache.sling.component.ComponentSession}}} interface provides a way to identify a user across more than one request and to store transient information about that user. + + A component can bind an object attribute into a {{{ComponentSession}}} by name. The {{{ComponentSession}}} interface defines two scopes for storing objects: {{{APPLICATION_SCOPE}}}, {{{COMPONENT_SCOPE}}}. All objects stored in the session using the {{{APPLICATION_SCOPE}}} must be available to all the components, servlets and JSPs that belong to the same component application and that handle a request identified as being a part of the same session. Objects stored in the session using the {{{COMPONENT_SCOPE}}} must be available to the component during requests for the same content that the objects where stored from. Attributes stored in the {{{COMPONENT_SCOPE}}} are not protected from other web components of the component application. They are just conveniently namespaced. + + The component session extends the Servlet API {{{HttpSession}}}. Therefore all {{{HttpSession}}} listeners do apply to the component session and attributes set in the component session are visible in the {{{HttpSession}}} and vice versa. + + The attribute accessor methods without the ''scope'' parameter always refer to {{{COMPONENT_SCOPE}}} attributes. To access {{{APPLICATION_SCOPE}}} attributes use the accessors taking an explicit {{{scope}}} parameter. + + ''A final note on Sessions'': Sessions are server side sessions and hence violate the sessionless principle of REST and therefore should be used with care. It is almost always possible to not use sessions. + + + == Dispatching Requests == To include renderings of child Content objects, a {{{org.apache.sling.component.ComponentRequestDispatcher}}} object may be retrieved from the ComponentContext with which the Component has been initialized or from the ComponentRequest provided to the service method. Using this dispatcher the reponse of rendering the Content may be included by calling the {{{ComponentRequestDispatcher.include(ComponentRequest, ComponentResponse)}}} method.