You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by hl...@apache.org on 2005/06/01 16:25:55 UTC
cvs commit: jakarta-tapestry/framework/src/java/org/apache/tapestry/services Infrastructure.java
hlship 2005/06/01 07:25:55
Modified: portlet/src/descriptor/META-INF hivemodule.xml
framework/src/descriptor/META-INF tapestry.request.xml
portlet/src/documentation/content/xdocs/tapestry-portlet
index.xml
src/documentation/content/xdocs links.ent site.xml
framework/src/java/org/apache/tapestry/services/impl
InfrastructureImpl.java
framework/src/java/org/apache/tapestry/services
Infrastructure.java
Added: portlet/src/documentation/content/xdocs/tapestry-portlet
coding-issues.xml configuration.xml
Log:
Add in basic Portlet documentation.
Properly seperate the Servlet and Portlet implementations of the CookieService via the Infrastructure.
Revision Changes Path
1.18 +7 -7 jakarta-tapestry/portlet/src/descriptor/META-INF/hivemodule.xml
Index: hivemodule.xml
===================================================================
RCS file: /home/cvs/jakarta-tapestry/portlet/src/descriptor/META-INF/hivemodule.xml,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- hivemodule.xml 15 May 2005 22:56:37 -0000 1.17
+++ hivemodule.xml 1 Jun 2005 14:25:55 -0000 1.18
@@ -181,14 +181,13 @@
<construct service-id="PortletRequestGlobals" property="renderResponse"/>
</invoke-factory>
</service-point>
-
- <!-- There's nothing in the Portlet API to support cookies, so override
- the default (servlet) implementation with an empty placeholder.
- This may break some tests when running JUnit inside Eclipse. -->
-
- <implementation service-id="tapestry.request.CookieSource">
+
+ <service-point id="PortletCookieSource" interface="org.apache.tapestry.services.CookieSource">
+
+ A "default" (no-op) implementation of the CookieSource interface.
+
<invoke-factory service-id="hivemind.lib.PlaceholderFactory"/>
- </implementation>
+ </service-point>
<service-point id="PortletLinkFactory" interface="org.apache.tapestry.services.LinkFactory">
Implementation of LinkFactory for portlets that builds links using
@@ -225,6 +224,7 @@
<property name="exceptionPresenter" mode="portlet" object="service:PortletExceptionPresenter"/>
<property name="staleLinkExceptionPresenter" mode="portlet" object="service:PortletStaleLinkExceptionPresenter"/>
<property name="staleSessionExceptionPresenter" mode="portlet" object="service:PortletStaleSessionExceptionPresenter"/>
+ <property name="cookieSource" mode="portlet" object="service:PortletCookieSource"/>
</contribution>
<contribution configuration-id="PortletApplicationInitializers">
1.30 +2 -1 jakarta-tapestry/framework/src/descriptor/META-INF/tapestry.request.xml
Index: tapestry.request.xml
===================================================================
RCS file: /home/cvs/jakarta-tapestry/framework/src/descriptor/META-INF/tapestry.request.xml,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- tapestry.request.xml 15 May 2005 22:56:36 -0000 1.29
+++ tapestry.request.xml 1 Jun 2005 14:25:55 -0000 1.30
@@ -39,7 +39,7 @@
<invoke-factory model="threaded">
<construct class="impl.RequestLocaleManagerImpl">
<set-service property="request" service-id="tapestry.globals.WebRequest"/>
- <set-service property="cookieSource" service-id="CookieSource"/>
+ <set-object property="cookieSource" value="infrastructure:cookieSource"/>
<set-service property="threadLocale" service-id="hivemind.ThreadLocale"/>
</construct>
</invoke-factory>
@@ -181,6 +181,7 @@
<contribution configuration-id="tapestry.Infrastructure">
<property name="responseRenderer" object="service:ResponseRenderer"/>
<property name="requestCycleFactory" object="service:RequestCycleFactory"/>
+ <property name="cookieSource" object="service:CookieSource"/>
</contribution>
<service-point id="AbsoluteURLBuilder">
1.2 +14 -1 jakarta-tapestry/portlet/src/documentation/content/xdocs/tapestry-portlet/index.xml
Index: index.xml
===================================================================
RCS file: /home/cvs/jakarta-tapestry/portlet/src/documentation/content/xdocs/tapestry-portlet/index.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.xml 10 Mar 2005 23:24:33 -0000 1.1
+++ index.xml 1 Jun 2005 14:25:55 -0000 1.2
@@ -23,7 +23,20 @@
</header>
<body>
-<p> An add-on module for Tapestry that enables the use of Tapestry to create <link href="http://www.jcp.org/en/jsr/detail?id=168">JSR-168 Portlets</link>. </p>
+<p> An add-on module for Tapestry that enables the use of Tapestry to create <link href="http://www.jcp.org/en/jsr/detail?id=168">JSR-168 Portlets</link>.
+ Portlet support is new in Tapestry 4.0. To a large degree, Tapestry has been re-architected to support portlets.</p>
+
+<p>
+Portlet support in Tapestry is <em>native</em>. This means that Tapestry is, under the covers, using the true Portlet API
+as it is intended to be used. Some portal services support bridging ... allowing servlet applications to operate as
+portlet applications unchanged; such an approach is possible as well, but is not necessary.
+</p>
+
+<p>
+The pattern of development for Tapestry portlet applications is to create a (generally) small application,
+consisting of just a few pages. Each Tapestry portlet within a portal page will be a completely separate
+instance of not just the portlet, but all the Tapestry services behind it.
+</p>
</body>
</document>
1.1 jakarta-tapestry/portlet/src/documentation/content/xdocs/tapestry-portlet/coding-issues.xml
Index: coding-issues.xml
===================================================================
<?xml version="1.0"?>
<!--
Copyright 2005 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "./dtd/document-v12.dtd"
[
<!ENTITY projectroot '../'>
<!ENTITY % links.ent SYSTEM "../links.ent">
%links.ent;
]>
<document>
<header>
<title>Coding Issues</title>
</header>
<body>
<section>
<title>Loss of Transient State</title>
<p>
For developers experienced at servlet Tapestry, this one issue takes quite some getting used to.
</p>
<p>
In servlet Tapestry, a request comes in (such as a form submission). As part of processing the request,
pages will be obtained from the page pool and will have persistent state rolled back. Other page
and component properties will contain <em>transient</em> state; information that will be discarded
at the end of the request ... but that's ok, because a response page will be rendered before
that information is lost.
</p>
<p>
In portlet Tapestry, much is the same, <em>except for transient state</em>. The Portlet API
splits the scenario into two completely distrinct parts: the action request and the render request. These
are two completely seperate requests, and all transient state will be lost between them. Further,
the render request may occur many times. This is because a single portlet within a page <em>may</em>
(depending on the Portlet container and configuration of the portlet) have to re-render itself due
to an action request for some entirely different portlet.</p>
<p>
The solution is to define more properties as <em>persistent</em>. This is done using the <property> element
of the page and component specifications, such as:
</p>
<source><![CDATA[
<property name="itemId" persist="session"/>
]]></source>
<p>
Commonly, the &PageBeginRenderListener; interface is used to obtain a database object, bootstrapping
from an id stored as a persistent property:
</p>
<source><![CDATA[
public abstract class MyPage
extends BasePage
implements PageBeginRenderListener
{
/** Persistent */
public abstract long getItemId();
public abstract void setItemId(long itemId);
/** Transient */
public abstract Item getItem();
public abstract void setItem(Item item);
/** Injected */
public abstract ItemSource getItemSource();
public void pageBeginRender(PageEvent event)
{
long itemId = getItemId();
Item item = getItemSource().findItemById(itemId);
setItem(item);
}
}
]]>
</source>
<p>
One of the most common problems related to loss of transient state concerns
<link href="site:validation">user input validation</link>. By <em>default</em>,
validation data is stored transiently. The end result is that when a validated form
is submitted with errors and re-rendered, the error messages and field decorations do not appear!
</p>
<p>
A good technique for handling this properly is to make the validation delegate
an <link href="site:state">application state object</link> that persists in the session,
and then <em>inject</em>
that ASO into each page that contains a form.
</p>
<p>
Start by defining an ASO for the validation delegate. The goes into your application's
hivemodule.xml module descriptor:
</p>
<source><![CDATA[
<contribution configuration-id="hivemind.state.ApplicationObjects">
<state-object name="validation-delegate" scope="session">
<create-instance class="org.apache.tapestry.valid.ValidationDelegate"/>
</state-object>
</contribution>
]]></source>
<p>
Next, in each page that needs the validation delegate, inject it as a property. This is done
in the page's specification:
</p>
<source><![CDATA[
<inject name="delegate" type="state" object="validation-delegate"/>
]]></source>
<p>
When using a &Form; component, override the default validation delegate:
</p>
<source><![CDATA[
<component id="form" type="Form">
<binding name="delegate" value="delegate"/>
<binding name="listener" value="doSubmit"/>
</component>
]]></source>
<p>
The delegate parameter's default binding prefix is "ognl", so <code>value="delegate"</code> refers
to the delegate property of the page, a read-only property created by the <inject> element.
</p>
<p>
And that's it ... the validation delegate will be created when first needed. A single instance will be shared
by many pages. It will be necessary to invoke the clear() method on the validation delegate when switching pages
(otherwise, you could see decorations one one page that are really caused by form input errors on some
other page). This is an extra step to be done inside your listener methods.
</p>
</section>
<section>
<title>Partial Pages</title>
<p>
A fundamental part of developing Portlets (with our without Tapestry) is that each Portlet within a Portal Page
produces just a portion of the HTML. This means you will not, and should not, use the &Shell; or &Body;
components.
</p>
<p>
The latter seems problematic ... no &Body; component normally means no client-side JavaScript! Fortunately,
your components can still create JavaScript, using Tapestry script templates, and the JavaScript
will still be collected as if there was a &Body; component. You may also see the namespace, provided by the
portlet container, integrated into the names of client-side variables and methods ... this prevents any name collisions
when multiple Tapestry portlets exist on the same page.
</p>
</section>
<section>
<title>Accessing the Portlet API</title>
<p>
In very rare circumstances, you may need to directly access the PortletRequest object. For example,
you may make part of your page conditional based on the current window mode.
</p>
<p>
If you are just interseted in query parameters, you can access those via the &IRequestCycle; object.
</p>
<p>
Most other standard information can be injected as the infrastructure:request object. This object
is API neutral (neither servlet nor portlet, but a kind of least-common-denominator abstraction). It
can easily be injected into any page or component using the specification's <inject> element:
</p>
<source><![CDATA[
<inject property="request" object="infrastructure:request"/>
]]></source>
<p>
The type of object injected will be &WebRequest;. There's also an infrastructure:response object
that implements the &WebResponse; interface.
</p>
<note>
This may look odd; you are injecting something that looks like an application global. Don't worry ... what's
actually injected is a proxy object that implements the &WebRequest; interface, but ultimately
delegates all of its behavior to a per-request (and therefore, per-thread) object. It just works.
</note>
<p>
Properties such as portletMode or windowState are <em>not</em> part of &WebRequest;, you'll want to
inject a portlet-specific object instead:
</p>
<table>
<tr>
<th>Object</th> <th>Interface</th>
</tr>
<tr>
<td>service:tapestry.portlet.ActionResponse</td>
<td>javax.portlet.ActionResponse</td>
</tr>
<tr>
<td>service:tapestry.portlet.PortletRequest</td>
<td>javax.portlet.PortletRequest</td>
</tr>
<tr>
<td>service:tapestry.portlet.RenderResponse</td>
<td>javax.portlet.RenderResponse</td>
</tr>
</table>
<p>
Care should be taken to only invoke methods on the ActionResponse and RenderResponse objects when
in the correct phase.
</p>
</section>
<section>
<title>User Attributes</title>
<p>
Part of the <portlet> definition within the portlet.xml deployment descriptor is a definition
of user attributes. User attributes are configuration data stored for each user (this is part of the
infrastructure provided by the Portal: user authentication and attributes). User attribute names are strings, usually
in the form of a dotted sequence of terms (such as "user.name.given"). User attribute values are simple strings.
</p>
<p>
User attributes are stored persistently in a database; values will be available in later sessions,
not just later requests.
</p>
<p>
A special binding prefix, "user:", is used to access user attributes.
</p>
<p>
So, a particular portlet may define an attribute:
</p>
<source><![CDATA[
<user-attribute>
<description>User Given Name</description>
<name>user.name.given</name>
</user-attribute>
]]></source>
<p>
Inside a page template, this value can be read and displayed:
</p>
<source><![CDATA[
<span jwcid="@Insert" value="user:user.name.given">User Name</span>
]]></source>
<p>
These values can just as easily be used with form element components, such as &ValidField;,
to read <em>and update</em> attributes:
</p>
<source><![CDATA[
<input jwcid="userName@ValidField" value="user:user.name.given"
displayName="User Name" validator="string,required"/>
]]></source>
</section>
</body>
</document>
1.1 jakarta-tapestry/portlet/src/documentation/content/xdocs/tapestry-portlet/configuration.xml
Index: configuration.xml
===================================================================
<?xml version="1.0"?>
<!--
Copyright 2005 The Apache Software Foundation
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "./dtd/document-v12.dtd"
[
<!ENTITY projectroot '../'>
<!ENTITY % links.ent SYSTEM "../links.ent">
%links.ent;
]>
<document>
<header>
<title>Configuration</title>
</header>
<body>
<p>
Configuration for Tapestry portlet applications is quite similar to configuration of Tapestry
servlet applications. In both cases, the WEB-INF/lib folder of the web application should include
the Tapestry libraries and dependencies. For portlet applications, WEB-INB/lib should also include the
tapestry-portlet-<em>x.y</em>.jar library.
</p>
<section>
<title>portlet.xml</title>
<p>
The file WEB-INF/portlet.xml define the portlets packaged inside a web application. As with servlet Tapestry,
we will use a framework-supplied Portlet class:
</p>
<source><![CDATA[
<portlet-app version="1.0"
xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_1_0.xsd">
<portlet>
<description xml:lang="EN"></description>
<portlet-name>myportlet</portlet-name>
<display-name xml:lang="EN">My Tapestry Portlet</display-name>
<portlet-class>org.apache.tapestry.portlet.ApplicationPortlet</portlet-class>
<expiration-cache>-1</expiration-cache>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>view</portlet-mode>
<portlet-mode>help</portlet-mode>
<portlet-mode>edit</portlet-mode>
</supports>
<supported-locale>en</supported-locale>
<portlet-info>
<title>My Tapestry Portlet</title>
<short-title>tapestry-portlet</short-title>
<keywords></keywords>
</portlet-info>
</portlet>
</portlet-app>
]]></source>
<p>
The class <code>org.apache.tapestry.portlet.ApplicationPortlet</code> is always the class for Tapestry Portlets.
</p>
<p>
Tapestry applications can support any reasonable <mime-type>, though the available components make HTML and WML
the most likely candidates.
</p>
<p>
Different portlet containers interpret the <portlet-mode> element differently. For example, &eXo; assumes that
every Portlet will support the "view" mode, and adding such an entry will result in a confusing duplication of the
view icons on the Portlet's control tab. On the other hand, &Jetspeed; makes no assumptions, so you really
should provide the "view" mode.
</p>
<p>
Later, we'll see how the combination of mime-type and portlet mode is used to select a Tapestry page.
</p>
<p>
Tapestry supports the other <portlet> elements, such as <portlet-preferences> and
<user-attribute>.
</p>
</section>
<section>
<title>hivemodule.xml</title>
<p>
Each Tapestry portlet application within a web application will construct its <em>own</em> &HiveMind; Registry
on initialization. The Registry will reflect all the libraries on the portlet's classpath (that is,
including the Tapestry and HiveMind JARs in WEB-INF/lib). In addition, two <em>optional</em> module
descriptors will be parsed and used, if present:
</p>
<ul>
<li>WEB-INF/<em>name</em>/hivemodule.xml</li>
<li>WEB-INF/hivemodule.xml</li>
</ul>
<p>
The <em>name</em>, in the above, is the portlet name, from the <portlet-name> element of the
portlet.xml descriptor. This allows different Tapestry portlets, even within the same WAR, to
precisely control their individual configuration.
</p>
<p>
The two primary reasons for a Tapestry portlet application to have its own hivemodule.xml are:
</p>
<ul>
<li>To control the mapping of requests to Tapestry pages</li>
<li>To define portlet-specific services needed by the portlet application</li>
</ul>
</section>
<section>
<title>web.xml</title>
<p>
By specification, portlet applications are a specialized kind of web application; as such, they require
a web.xml as well as a portlet.xml.
</p>
<p>
For Tapestry, it is necessary to define a single Tapestry application servlet for each WAR.
</p>
<source><![CDATA[
<!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>app</display-name>
<servlet>
<servlet-name>ApplicationServlet</servlet-name>
<servlet-class>org.apache.tapestry.ApplicationServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ApplicationServlet</servlet-name>
<url-pattern>/app</url-pattern>
</servlet-mapping>
</web-app>
]]></source>
<note>
Some portals, such as &eXo;, require additional configuration in the web.xml deployment
descriptor.
</note>
<p>
Note that just <em>one</em> ApplicationServlet is needed, regardless of the number of Tapestry portlet applications
within the WAR. This Tapestry servlet instance is primarily needed to support the use of the
asset service, which is the mechanism by which private assets stored within the framework's JARs (such
as images and stylesheets) can be provided to client web browsers.
</p>
<p>
In the above example, the default servlet mapping, to the /app URL, was used. You may use alternate
mappings, but additional <link href="site:friendly-urls">configuration</link> is needed.
</p>
</section>
<section>
<title>Mapping Requests to Pages</title>
<p>
Tapestry has to bridge between the operation-centric organization of Portlets, and the page/component-centric
organization of Tapestry itself. This is most visible when the a Tapestry Portlet first starts up, or when a
user changes the window state or portlet mode by using the portlet's toolbar (to be specific: the toolbar
provided by the Portal page).
</p>
<p>
In all these cases, a request is recieved by the Tapestry ApplicationPortlet that includes no real information
in the request, just an indication of the desired window state and portlet mode.
</p>
<p>
Tapestry uses a set of <em>rules</em> to determine what to do in these cases. Each rule
identifies <em>up-to</em> three <em>factors</em> used to select a page. These factors are
mime-type, portlet-mode, and window-state.
</p>
<p>
The rules are sorted and consulted in order. The first match defines the page to activate and render. Omitting
a factor means that the factor is not used when checking a rule against an incoming request.
</p>
<p>
The rules are defined by the configuration point <code>tapestry.portlet.resolver.PageResolverRules</code>. Contributions
to this configuration point consist of <match> elements:
</p>
<source><![CDATA[
<match [portlet-mode="..."] [mime-type="..."] [window-state="..."] page="..."/>
]]></source>
<p>
The default rules are:
</p>
<source><![CDATA[
<match portlet-mode="edit" page="Edit"/>
<match portlet-mode="help" page="Help"/>
]]></source>
<p>
Any rules you define will be mixed in with these two default rules.
</p>
<p>
So, by contributing additional <match> rules to this configuration point, it is possible
to precisely control which page should be rendered for each request; for example, you could
have different pages for the "edit" portlet-mode, depending on whether the window state was
normal or maximized:
</p>
<source>
<![CDATA[
<contribution configuration-id="tapestry.portlet.resolver.PageResolverRules">
<match portlet-mode="edit" window-state="maximized" page="EditLarge"/>
</contribution>
]]>
</source>
<p>
Here, the Edit page would be used (as per the default rules) unless the window state was maximized,
in which case the EditLarge page would be used.
</p>
<p>
What happens when none of the rules match? In that case, the View page is activated and
rendered. The View page, in portlet Tapestry, is the equivalent of the Home page, in servlet Tapestry.
</p>
<p>
<strong>For advanced developers</strong>: the process for determing the page for a request is ultimately based on
a extensible chain of command. The <code>tapestry.portlet.resolver.PageResolvers</code> configuration
point defines the commands in the chain; by providing services that implement the
<link href="apidocs/org/apache/tapestry/portlet/PortletPageResolver.html">PortletPageResolver</link> interfaces,
you can add even more sophisticated and precise control over the mapping between requests and pages.
</p>
</section>
</body>
</document>
1.14 +4 -0 jakarta-tapestry/src/documentation/content/xdocs/links.ent
Index: links.ent
===================================================================
RCS file: /home/cvs/jakarta-tapestry/src/documentation/content/xdocs/links.ent,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- links.ent 21 May 2005 15:36:22 -0000 1.13
+++ links.ent 1 Jun 2005 14:25:55 -0000 1.14
@@ -111,6 +111,8 @@
<!ENTITY StateObjectFactory '<link href="&apiroot;/engine/state/StateObjectFactory.html">StateObjectFactory</link>'>
<!ENTITY Tapestry '<link href="&apiroot;/Tapestry.html">Tapestry</link>'>
<!ENTITY ValidationDelegate '<link href="&apiroot;/valid/ValidationDelegate.html">ValidationDelegate</link>'>
+<!ENTITY WebRequest '<link href="&apiroot;/web/WebRequest.html">WebRequest</link>'>
+<!ENTITY WebResponse '<link href="&apiroot;/web/WebResponse.html">WebResponse</link>'>
<!-- Links to Component Reference -->
@@ -164,11 +166,13 @@
<!ENTITY BSF '<link href="http://jakarta.apache.org/bsf/">BSF</link>'>
<!ENTITY BCEL '<link href="http://jakarta.apache.org/bcel/">BCEL</link>'>
<!ENTITY Eclipse '<link href="http://www.eclipse.org">Eclipse</link>'>
+<!ENTITY eXo '<link href="http://www.exoplatform.com/">eXo platform</link>'>
<!ENTITY HiveMind '<link href="http://jakarta.apache.org/hivemind/">HiveMind</link>'>
<!ENTITY Log4J '<link href="http://jakarta.apache.org/log4j/">Log4J</link>'>
<!ENTITY Jakarta '<link href="http://jakarta.apache.org">Jakarta</link>'>
<!ENTITY Javassist '<link href="http://jboss.org/developers/projects/javassist.html">Javassist</link>'>
<!ENTITY JBoss '<link href="http://www.jboss.org">JBoss</link>'>
+<!ENTITY Jetspeed '<link href="http://portals.apache.org/jetspeed-2/">Jetspeed 2</link>'>
<!ENTITY Jetty '<link href="http://sf.net/projects/jetty/">Jetty</link>'>
<!ENTITY JUnit '<link href="http://www.junit.org">JUnit</link>'>
<!ENTITY Jython '<link href="http://www.jython.org">Jython</link>'>
1.33 +3 -1 jakarta-tapestry/src/documentation/content/xdocs/site.xml
Index: site.xml
===================================================================
RCS file: /home/cvs/jakarta-tapestry/src/documentation/content/xdocs/site.xml,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- site.xml 20 May 2005 12:46:09 -0000 1.32
+++ site.xml 1 Jun 2005 14:25:55 -0000 1.33
@@ -53,7 +53,7 @@
<localization label="Localization" href="localization.html"/>
<state label="Managing server-side state" href="state.html"/>
<hivemind label="HiveMind Integration" href="hivemind.html"/>
- <friend-urls label="Friendly URLs" href="friendly-urls.html"/>
+ <friendly-urls label="Friendly URLs" href="friendly-urls.html"/>
<events label="Page Events" href="events.html"/>
<configuration label="Configuring Tapestry" href="configuration.html"/>
<proprties label="Tapestry Object Properties" href="properties.html"/>
@@ -129,6 +129,8 @@
<portlet label="Portlet Support" tab="portlet" href="tapestry-portlet/">
<index label="Overview" href="index.html"/>
+ <configuration label="Configuration" href="configuration.html"/>
+ <coding-issues label="Coding Issues" href="coding-issues.html"/>
<reports label="Reports">
&tapestry-portlet-report-menu.ent;
1.35 +6 -0 jakarta-tapestry/framework/src/java/org/apache/tapestry/services/impl/InfrastructureImpl.java
Index: InfrastructureImpl.java
===================================================================
RCS file: /home/cvs/jakarta-tapestry/framework/src/java/org/apache/tapestry/services/impl/InfrastructureImpl.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- InfrastructureImpl.java 20 May 2005 12:46:08 -0000 1.34
+++ InfrastructureImpl.java 1 Jun 2005 14:25:55 -0000 1.35
@@ -43,6 +43,7 @@
import org.apache.tapestry.markup.MarkupWriterSource;
import org.apache.tapestry.services.ComponentMessagesSource;
import org.apache.tapestry.services.ComponentPropertySource;
+import org.apache.tapestry.services.CookieSource;
import org.apache.tapestry.services.DataSqueezer;
import org.apache.tapestry.services.Infrastructure;
import org.apache.tapestry.services.LinkFactory;
@@ -265,6 +266,11 @@
{
return (AssetFactory) getProperty("assetFactory");
}
+
+ public CookieSource getCookieSource()
+ {
+ return (CookieSource) getProperty("cookieSource");
+ }
public Object getProperty(String propertyName)
{
1.36 +10 -3 jakarta-tapestry/framework/src/java/org/apache/tapestry/services/Infrastructure.java
Index: Infrastructure.java
===================================================================
RCS file: /home/cvs/jakarta-tapestry/framework/src/java/org/apache/tapestry/services/Infrastructure.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- Infrastructure.java 20 May 2005 12:46:07 -0000 1.35
+++ Infrastructure.java 1 Jun 2005 14:25:55 -0000 1.36
@@ -272,13 +272,20 @@
* Service (possibly a pipeline) that will invoke {@link org.apache.tapestry.IActionListener}
* objects.
*/
-
+
public ListenerInvoker getListenerInvoker();
-
+
/**
* Service that is used to convert {@link org.apache.hivemind.Resource}s into
* {@link org.apache.tapestry.IAsset}s.
*/
-
+
public AssetFactory getAssetFactory();
+
+ /**
+ * Service used to access HTTP Cookies. This is only available for Servlet Tapestry; a
+ * placeholder will be provided for Portlet Tapestry.
+ */
+
+ public CookieSource getCookieSource();
}
\ No newline at end of file
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org