cziegeler 02/05/07 23:21:38
Modified: src/documentation/xdocs/developing authentication.xml
session.xml
Log:
Pretty printed docs
Submitted by: Bert Van Kets [EMAIL PROTECTED]
Revision Changes Path
1.2 +168 -166
xml-cocoon2/src/documentation/xdocs/developing/authentication.xml
Index: authentication.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/src/documentation/xdocs/developing/authentication.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- authentication.xml 23 Apr 2002 10:25:32 -0000 1.1
+++ authentication.xml 8 May 2002 06:21:38 -0000 1.2
@@ -83,15 +83,13 @@
resource can be protected by calling this handler using the
auth-protect
action. The "auth-protect" action must be included in the pipeline
of the
resource. It gets the handler information as a parameter:</p>
- <source> <map:match pattern="protectedresource">
- <map:act type="auth-protect">
- <map:parameter name="handler" value="unique handler name"/>
-
- <map:generate src="source/resource.xml"/>
- </map:act>
+ <source><map:match pattern="protectedresource">
+ <map:act type="auth-protect">
+ <map:parameter name="handler" value="unique handler name"/>
+ <map:generate src="source/resource.xml"/>
+ </map:act>
...
- </map:match>
-</source>
+</map:match></source>
<p>If the pipeline does not use the "auth-protect" action or the
parameter "handler" is missing, the resource is accessible by any
user.</p>
</s2>
@@ -100,13 +98,13 @@
redirects to a special redirect-to resource. This resource is a
mandatory
configuration of the authentication handler:</p>
<source><action name="auth-protect" ...>
- <handlers> <!-- Now follows the handlers configuration -->
- <handler name="unique">
- <redirect-to uri="cocoon://loginpage"/> <!-- The login
resource -->
- </handler>
- </handlers>
-</action>
-</source>
+ <handlers>
+ <!-- Now follows the handlers configuration -->
+ <handler name="unique">
+ <redirect-to uri="cocoon://loginpage"/> <!-- The login
resource -->
+ </handler>
+ </handlers>
+</action></source>
<p>This redirect-to resource is an unprotected resource in the
sitemap. For tracking which resource was requested, the
redirect-to resource
gets the request parameter "resource" with the value. In addition
all
@@ -117,19 +115,18 @@
described below.</p>
<p>The authentication process is done by the "auth-login" action.
The login resource contains this action: </p>
- <source> <map:match pattern="login">
- <map:act type="auth-login">
- <map:parameter name="handler" value="unique"/>
- <map:parameter name="parameter_userid"
value="request:name"/>
- <map:parameter name="parameter_password"
value="request:password"/>
-
- <map:redirect-to uri="authentication-successful"/>
- </map:act>
- <!-- authentication failed: -->
- <map:generate src="auth_failed.xml"/>
- <map:transform src="tohtml.xsl"/>
- <map:serialize/>
- </map:match></source>
+ <source><map:match pattern="login">
+ <map:act type="auth-login">
+ <map:parameter name="handler" value="unique"/>
+ <map:parameter name="parameter_userid" value="request:name"/>
+ <map:parameter name="parameter_password" value="request:password"/>
+ <map:redirect-to uri="authentication-successful"/>
+ </map:act>
+ <!-- authentication failed: -->
+ <map:generate src="auth_failed.xml"/>
+ <map:transform src="tohtml.xsl"/>
+ <map:serialize/>
+</map:match></source>
<p>The "auth-protect" action uses the handler parameter to call the
authentication resource of this handler. This authentication
resource needs to
know the information provided by the user. For each piece of
information an own
@@ -163,12 +160,13 @@
possible (e.g. database, LDAP). The authentication resource is
another
mandatory configuration of the authentication handler:</p>
<source><action name="auth-protect" ...>
- <handlers> <!-- Now follows the handlers configuration -->
- <handler name="unique">
- <redirect-to uri="cocoon:raw://loginpage"/> <!-- The
login resource -->
- <authentication uri="cocoon:raw://authenticationresource"/>
- </handler>
- </handlers>
+ <handlers>
+ <!-- Now follows the handlers configuration -->
+ <handler name="unique">
+ <redirect-to uri="cocoon:raw://loginpage"/> <!-- The login
resource -->
+ <authentication uri="cocoon:raw://authenticationresource"/>
+ </handler>
+ </handlers>
</action></source>
<p>If the authentication resource is a sitemap resource or a remote
resource, this resource is requested by the framework with the
given parameters from
@@ -204,7 +202,7 @@
<p>The logout process is triggered by the "auth-logout"
action:</p>
<source><map:act type="auth-logout">
- <map:parameter name="handler" value="unique"/>
+ <map:parameter name="handler" value="unique"/>
</map:act></source>
<p>This action logs the user out of the given handler and removes all
information about this handler stored in the session.</p>
@@ -299,15 +297,16 @@
<p>For managing the application the framework needs to know to which
application a resource belongs. So in addition to the handler
parameter the
auth-protect action gets the application name as a second
parameter:</p>
- <source> <map:match pattern="protectedresource">
- <map:action type="auth-protect">
- <map:parameter name="handler" value="unique handler name"/>
- <map:parameter name="application" value="unique application
name"/>
-
- <map:generate src="source/resource.xml"/>
+ <source><map:match pattern="protectedresource">
+ <map:action type="auth-protect">
+ <map:parameter name="handler" value="unique handler name"/>
+ <map:parameter name="application" value="unique application name"/>
+
+ <map:generate src="source/resource.xml"/>
...
- </map:action>
- </map:match></source>
+ </map:action>
+</map:match>
+</source>
<p>With this mechanism each application resource can easily access
its
and only its information. If a resource has no "application"
parameter it can
not access information of any application.</p>
@@ -334,19 +333,19 @@
<p>The module configuration is part of the application
configuration:</p>
<source><action name="auth-protect" ...>
- <handlers>
- <handler name="unique">
- ....redirect-to/authentication configuration
- <applications> <!-- the applications for this handler
-->
- <application name="unique">
- ...
- <configuration name="portal">
- ...portal configuration
- </configuration>
- </application>
- </applications>
- </handler>
- </handlers>
+ <handlers>
+ <handler name="unique">
+ ....redirect-to/authentication configuration
+ <applications> <!-- the applications for this handler -->
+ <application name="unique">
+ ...
+ <configuration name="portal">
+ ...portal configuration
+ </configuration>
+ </application>
+ </applications>
+ </handler>
+ </handlers>
</action></source>
<p>So whenever the portal engine is asked to build the portal it can
easily retrieve its configuration from the current application by
getting the
@@ -356,41 +355,41 @@
<p>Using the framework it is possible to add new roles to the system
and to
add new users. For this purpose, there are several optional entries
for the
authentication handler which provide the needed functionality:</p>
- <source><action name="auth-protect" ...>
- <handlers>
- <handler name="unique">
+ <source><action name="auth-protect">
+ <handlers>
+ <handler name="unique">
...redirect-to/authentication configuration...
- <!-- Optional resource for loading user information -->
- <load-users
uri="cocoon:raw://financeresource-sunrise-loaduser"/>
+ <!-- Optional resource for loading user information -->
+ <load-users uri="cocoon:raw://financeresource-sunrise-loaduser"/>
- <!-- Optional resource for loading roles information-->
- <load-roles
uri="cocoon:raw://financeresource-sunrise-roles"/>
+ <!-- Optional resource for loading roles information-->
+ <load-roles uri="cocoon:raw://financeresource-sunrise-roles"/>
- <!-- Optional resource for creating a new user -->
- <new-user
uri="cocoon:raw://financeresource-sunrise-newuser"/>
+ <!-- Optional resource for creating a new user -->
+ <new-user uri="cocoon:raw://financeresource-sunrise-newuser"/>
- <!-- Optional resource for creating a new role -->
- <new-role
uri="cocoon:raw://financeresource-sunrise-newrole"/>
+ <!-- Optional resource for creating a new role -->
+ <new-role uri="cocoon:raw://financeresource-sunrise-newrole"/>
- <!-- Optional resource for changing user information -->
- <change-user
uri="cocoon:raw://financeresource-sunrise-newuser"/>
+ <!-- Optional resource for changing user information -->
+ <change-user uri="cocoon:raw://financeresource-sunrise-newuser"/>
- <!-- Optional resource for deleting a role -->
- <delete-role
uri="cocoon:raw://financeresource-sunrise-delrole"/>
+ <!-- Optional resource for deleting a role -->
+ <delete-role uri="cocoon:raw://financeresource-sunrise-delrole"/>
- <!-- Optional resource for deleting a user-->
- <delete-user
uri="cocoon:raw://financeresource-sunrise-deluser"/>
- </handler>
- </handlers>
+ <!-- Optional resource for deleting a user-->
+ <delete-user uri="cocoon:raw://financeresource-sunrise-deluser"/>
+ </handler>
+ </handlers>
</action></source>
<p>The entries are described in the following subchapters. All tags can
have additional parameter definitions which are passed to the given
resource,
e.g:</p>
<source><!-- Optional resource for deleting a user-->
<delete-user uri="cocoon:raw://financeresource-sunrise-deluser">
- <connection>database</connection>
- <url>db:usertable</url>
+ <connection>database</connection>
+ <url>db:usertable</url>
</delete-user></source>
<s2 title="Getting Roles">
<p>The <en>load-roles</en> resource is invoked from the framework
whenever
@@ -399,9 +398,9 @@
the root node "roles" and for each role a subelement "role" with a
text child
of the rolename:</p>
<source><roles>
- <role>admin</role>
- <role>guest</role>
- <role>user</role>
+ <role>admin</role>
+ <role>guest</role>
+ <role>user</role>
</roles></source>
</s2>
<s2 title="Getting Users">
@@ -423,14 +422,16 @@
<p>The XML format of the resource should look like the
following:</p>
<source><users>
- <user>
- <ID>authentication ID</ID>
- <role>rolename</role>
- <data> ... application specific data ... </data>
- </user>
- <user>
- ...
- </user>
+ <user>
+ <ID>authentication ID</ID>
+ <role>rolename</role>
+ <data>
+ ... application specific data ...
+ </data>
+ </user>
+ <user>
+ ...
+ </user>
...
</users></source>
</s2>
@@ -464,40 +465,43 @@
<s1 title="Configuration Summary">
<p>Here is a brief summary of the authentication handler configuration:
</p>
- <source><action name="auth-protect" ...>
- <handlers>
- <handler name="unique">
- <redirect-to uri="cocoon:raw://loginpage"/> <!-- The
redirect-to resource -->
-
- <!-- Authentication resource -->
- <authentication uri="cocoon:raw://authenticationresource">
- <!-- optional parameters -->
- </load>
- <!-- optional save resource -->
- <save uri="cocoon:raw://authenticationsaveresource">
- <!-- optional parameters -->
- </save>
+ <source><action name="auth-protect">
+ <handlers>
+ <handler name="unique">
+ <redirect-to uri="cocoon:raw://loginpage"/> <!-- The
redirect-to resource -->
+ <authentication uri="cocoon:raw://authenticationresource"/>
<!-- Authentication resource -->
+
+ <load uri="cocoon:raw://authenticationsaveresource">
+ <!-- optional parameters -->
+ </load>
+ <!-- optional save resource -->
+ <save uri="cocoon:raw://authenticationsaveresource">
+ <!-- optional parameters -->
+ </save>
+
+ <applications>
+ <!-- the applications for this handler -->
+ <application name="unique">
+
+ <!-- Loading/Saving -->
+ <load uri="cocoon:raw://loadapp">
+ <!-- optional -->
+ <!-- optional parameters -->
+ </load>
+ <save uri="cocoon:raw://saveapp">
+ <!-- optional -->
+ <!-- optional parameters -->
+ </save>
+ <!-- module configurations: -->
+
+ <configuration name="portal">
+ ...portal configuration
+ </configuration>
+ </application>
+ </applications>
- <applications> <!-- the applications for this handler
-->
- <application name="unique">
-
- <!-- Loading/Saving -->
- <load uri="cocoon:raw://loadapp"> <!--
optional -->
- <!-- optional parameters -->
- </load>
- <save uri="cocoon:raw://saveapp"> <!--
optional -->
- <!-- optional parameters -->
- </save>
-
- <!-- module
configurations: -->
- <configuration name="portal">
- ...portal configuration
- </configuration>
- </application>
-
- </applications>
- </handler>
- </handlers>
+ </handler>
+ </handlers>
</action></source>
</s1>
<s1 title="Pipeline Patterns">
@@ -516,13 +520,13 @@
</ol>
<p>Example:</p>
<source><map:match pattern="protected">
- <map:act type="auth-protect"> <!-- protect the resource -->
- <map:parameter name="handler" value="myhandler"/>
+ <map:act type="auth-protect"> <!-- protect the resource -->
+ <map:parameter name="handler" value="myhandler"/>
- <map:generate src="resource.xml"/>
- <map:transform src="toHTML"/>
- <map:serialize/>
- </map:act>
+ <map:generate src="resource.xml"/>
+ <map:transform src="toHTML"/>
+ <map:serialize/>
+ </map:act>
</map:match></source>
<p>It is very important that the auth-protect action wrapps the real
pipeline, as the pipeline is only invoked if the action grants
access. The
@@ -546,23 +550,22 @@
</ol>
<p>Example:</p>
<source><map:match pattern="protected-*">
+ <map:act type="auth-protect"> <!-- protect the resource -->
+ <map:parameter name="handler" value="myhandler"/>
- <map:act type="auth-protect"> <!-- protect the resource -->
- <map:parameter name="handler" value="myhandler"/>
-
- <map:match pattern="protected-first">
- <map:generate src="resource1.xml"/>
- <map:transform src="toHTML"/>
- <map:serialize/>
- </map:match>
+ <map:match pattern="protected-first">
+ <map:generate src="resource1.xml"/>
+ <map:transform src="toHTML"/>
+ <map:serialize/>
+ </map:match>
....
- <map:match pattern="protected-second">
- <map:generate src="resource2.xml"/>
- <map:transform src="toHTML"/>
- <map:serialize/>
- </map:match>
-
- </map:act>
+ <map:match pattern="protected-second">
+ <map:generate src="resource2.xml"/>
+ <map:transform src="toHTML"/>
+ <map:serialize/>
+ </map:match>
+
+ </map:act>
</map:match></source>
<p>Very important - as explained with the single resource pattern -
is
the leading match before the action is performed. The second match
is required
@@ -576,15 +579,15 @@
tag.</p>
<source><map:match pattern="startpage">
- <map:act type="auth-loggedIn"> <!-- check authentication -->
- <map:parameter name="handler" value="myhandler"/>
+ <map:act type="auth-loggedIn"> <!-- check authentication -->
+ <map:parameter name="handler" value="myhandler"/>
- <map:redirect-to uri="loggedInStartPage"/>
- </map:act>
+ <map:redirect-to uri="loggedInStartPage"/>
+ </map:act>
- <map:generate src="startpage.xml"/>
- <map:transform src="toHTML"/>
- <map:serialize/>
+ <map:generate src="startpage.xml"/>
+ <map:transform src="toHTML"/>
+ <map:serialize/>
</map:match></source>
<p>In the example above, if the user is already logged he is
redirected to the <en>loggedInStartPage</en> resource. If he is
not logged in
@@ -594,34 +597,33 @@
given handler - all values from the context to the sitemap, e.g.
ID, role etc.
These values can be used within the other components:</p>
<source><map:match pattern"protected">
- <map:act type="auth-protect"> <!-- protect the resource -->
- <map:parameter name="handler" value="myhandler"/>
-
- <!-- Append the ID of the user to the file name -->
- <map:generate src="resource_{ID}.xml"/>
- <map:transform src="toHTML"/>
- <map:serialize/>
+ <map:act type="auth-protect"> <!-- protect the resource -->
+ <map:parameter name="handler" value="myhandler"/>
- </map:act>
+ <!-- Append the ID of the user to the file name -->
+ <map:generate src="resource_{ID}.xml"/>
+ <map:transform src="toHTML"/>
+ <map:serialize/>
+ </map:act>
</map:match></source>
<p>But the auth-loggedIn action does not give the included pipeline
access to the authentication context belonging to the handler. If
you want this, you
have to nest the auth-protect action inside!</p>
<source><map:match pattern"start">
- <map:act type="auth-loggedIn"> <!-- check authentication -->
- <map:parameter name="handler" value="myhandler"/>
+ <map:act type="auth-loggedIn"> <!-- check authentication -->
+ <map:parameter name="handler" value="myhandler"/>
- <map:act type="auth-protect"> <!-- give access to the
context -->
- <map:parameter name="handler" value="myhandler"/>
+ <map:act type="auth-protect"> <!-- give access to the context
-->
+ <map:parameter name="handler" value="myhandler"/>
- <map:generate src="getinfofromcontext.xml"/>
- <map:transform src="session"/>
- <map:transform src="toHTML"/>
- <map:serialize/>
- </map:act>
+ <map:generate src="getinfofromcontext.xml"/>
+ <map:transform src="session"/>
+ <map:transform src="toHTML"/>
+ <map:serialize/>
</map:act>
+ </map:act>
</map:match></source>
</s2>
1.2 +140 -145
xml-cocoon2/src/documentation/xdocs/developing/session.xml
Index: session.xml
===================================================================
RCS file:
/home/cvs/xml-cocoon2/src/documentation/xdocs/developing/session.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- session.xml 23 Apr 2002 10:25:32 -0000 1.1
+++ session.xml 8 May 2002 06:21:38 -0000 1.2
@@ -101,33 +101,31 @@
<p>The following example shows the use of several commands and in
particular how the <em>mergexml</em> command can be used to
manipulate context
data.</p>
- <source>
-<resource xmlns:session="http://cocoon.apache.org/session/1.0">
- <session:createcontext name="trackdemo"/>
- <!-- build context data -->
- <session:setxml context="trackdemo" path="/">
- <context>
- <users>
- <user id="1">
- <name>Carsten</name>
- </user>
- </users>
- </context>
- </session:setxml>
- <session:mergexml context="trackdemo" path="/context">
- <users>
- <user id="1">
- <name>Ziegeler</name>
- <developer>true</developer>
- </user>
- <user id="2">
- <name>Walter</name>
- </user>
- </users>
- </session:mergexml>
- <session:getxml context="trackdemo" path="/"/>
-</resource>
-</source>
+ <source><resource
xmlns:session="http://cocoon.apache.org/session/1.0">
+ <session:createcontext name="trackdemo"/>
+ <!-- build context data -->
+ <session:setxml context="trackdemo" path="/">
+ <context>
+ <users>
+ <user id="1">
+ <name>Carsten</name>
+ </user>
+ </users>
+ </context>
+ </session:setxml>
+ <session:mergexml context="trackdemo" path="/context">
+ <users>
+ <user id="1">
+ <name>Ziegeler</name>
+ <developer>true</developer>
+ </user>
+ <user id="2">
+ <name>Walter</name>
+ </user>
+ </users>
+ </session:mergexml>
+ <session:getxml context="trackdemo" path="/"/>
+</resource></source>
<p>In the above example, a context for storing data is added. Using
the <em>setxml</em> command data is then stored into the
context. The following
<em>mergexml</em> command then changes the name of user-1 and
adds a further
@@ -204,78 +202,79 @@
"?param=aaa&...".</p>
<p>The complete context you can access via these commands has the
following XML format:</p>
- <source>
- <parameter> <-- All parameters: parameter names build the
elements with the values as text node childs -->
- <firstparameter>value of parameter</firstparameter>
- <secondparameter>value of parameter</secondparameter>
- </parameter>
-
- <querystring>the querystring with a leading '?' or
empty<querystring>
- (The querystring contains only parameters send by the GET
method)
-
- <parametervalues> <-- All parameters. The tags are all
inside the session namespace.
- The generated xml can be used without
modification for the
-
session:connection command. -->
-
- <session:params>
- <session:param>
- <session:name>1st parameter
name</session:name>
- <session:value>1st parameter
value</session:value>
- </session:param>
- ...
- <session:param>
- <session:name>2nd parameter
name</session:name>
- <session:value>2nd parameter
value</session:value>
- </session:param>
- </session:params>
-
- <!-- If a parameter has more than one value,
for each value a
- <session:param> block is generated. -->
- </parametervalues>
-
- <attributes> <!-- lists all attributes, attribute names
build the elements
- with the values as text node childs -->
- </attributes>
-
- <headers> <!-- lists all headers, header names build the
elements
- with the values as text node childs -->
- </headers>
-
- <cookies> <!-- lists all cookies -->
- <cookie name="...">
- <value>the cookie value</value>
- <name>the name of the cookie</name>
- <comment>value</comment>
- <domain>value</domain>
- <path>value</path>
- <maxAge>value</maxAge>
- <secure>value</secure>
- <version>value</version>
- </cookie>
- </cookies>
-
- <characterEncoding>value</characterEncoding>
- <contentLength>value</contentLength>
- <contentType>value</contentType>
- <protocol>value</protocol>
- <remoteAddress>value</remoteAddress>
- <remoteHost>value</remoteHost>
- <scheme>value</scheme>
- <serverName>value</serverName>
- <serverPort>value</serverPort>
- <authType>value</authType>
- <method>value</method>
- <contextPath>value</contextPath>
- <pathInfo>value</pathInfo>
- <pathTranslated>value</pathTranslated>
- <remoteUser>value</remoteUser>
- <requestedSessionId>value</requestedSessionId>
- <requestURI>value</requestURI>
- <servletPath>value</servletPath>
-
<isRequestedSessionIdFromCookie>value</isRequestedSessionIdFromCookie>
-
<isRequestedSessionIdFromCookie>value</isRequestedSessionIdFromCookie>
-
<isRequestedSessionIdValid>value</isRequestedSessionIdValid>
- </source>
+ <source><parameter>
+ <!-- All parameters: parameter names build the elements with the values
as text node childs -->
+ <firstparameter>value of parameter</firstparameter>
+ <secondparameter>value of parameter</secondparameter>
+</parameter>
+
+<querystring>the querystring with a leading '?' or
empty<querystring>
+ (The querystring contains only parameters send by the GET method)
+
+<parametervalues>
+ <!-- All parameters. The tags are all inside the session namespace.
+ The generated xml can be used without modification for the
+ session:connection command. -->
+ <session:params>
+ <session:param>
+ <session:name>1st parameter name</session:name>
+ <session:value>1st parameter value</session:value>
+ </session:param>
+ ...
+ <session:param>
+ <session:name>2nd parameter name</session:name>
+ <session:value>2nd parameter value</session:value>
+ </session:param>
+ </session:params>
+ <!-- If a parameter has more than one value, for each value a
+ <session:param> block is generated. -->
+</parametervalues>
+
+<attributes>
+ <!-- lists all attributes, attribute names build the elements
+ with the values as text node childs -->
+</attributes>
+
+<headers>
+ <!-- lists all headers, header names build the elements
+ with the values as text node childs -->
+</headers>
+
+<cookies>
+ <!-- lists all cookies -->
+ <cookie name="...">
+ <value>the cookie value</value>
+ <name>the name of the cookie</name>
+ <comment>value</comment>
+ <domain>value</domain>
+ <path>value</path>
+ <maxAge>value</maxAge>
+ <secure>value</secure>
+ <version>value</version>
+ </cookie>
+</cookies>
+
+<characterEncoding>value</characterEncoding>
+<contentLength>value</contentLength>
+<contentType>value</contentType>
+<protocol>value</protocol>
+<remoteAddress>value</remoteAddress>
+<remoteHost>value</remoteHost>
+<scheme>value</scheme>
+<serverName>value</serverName>
+<serverPort>value</serverPort>
+<authType>value</authType>
+<method>value</method>
+<contextPath>value</contextPath>
+<pathInfo>value</pathInfo>
+<pathTranslated>value</pathTranslated>
+<remoteUser>value</remoteUser>
+<requestedSessionId>value</requestedSessionId>
+<requestURI>value</requestURI>
+<servletPath>value</servletPath>
+<isRequestedSessionIdFromCookie>value</isRequestedSessionIdFromCookie>
+<isRequestedSessionIdFromCookie>value</isRequestedSessionIdFromCookie>
+<isRequestedSessionIdValid>value</isRequestedSessionIdValid></source>
</s2>
<s2 title="The Response Context - Accessing the Environment, Part Two">
<p>The response context is an XML description of the current
@@ -301,19 +300,17 @@
<p>Cookies can be added either by setxml or by appendxml. There is
no difference between these commands.</p>
<source><session:setxml context="response" path="/cookie">
- <!-- Now follows the cookie definition -->
- <name>The cookie name</name>
- <value>The value of the cookie</value>
-
- <!-- The following are optional -->
- <path>value</path>
- <domain>value</domain>
- <secure>true or false</secure>
- <comment>value</comment>
- <maxAge>value</maxAge>
- <version>value</version>
-</session:setxml>
- </source>
+ <!-- Now follows the cookie definition -->
+ <name>The cookie name</name>
+ <value>The value of the cookie</value>
+ <!-- The following are optional -->
+ <path>value</path>
+ <domain>value</domain>
+ <secure>true or false</secure>
+ <comment>value</comment>
+ <maxAge>value</maxAge>
+ <version>value</version>
+</session:setxml></source>
</s3>
</s2>
<s2 title="The Temporary Context">
@@ -345,11 +342,11 @@
of the user, you could generate a base xml file with the
information about this
form:</p>
<source><page>
- <form>
- <action>form-handling-page</action>
- <input name="forename" type="text"/>
- <input name="surname" type="text"/>
- </form>
+ <form>
+ <action>form-handling-page</action>
+ <input name="forename" type="text"/>
+ <input name="surname" type="text"/>
+ </form>
</page></source>
<p>A stylesheet can transform this into valid html. The action tag
indicates that the "form-handling-page" should be invoked by
submitting the
@@ -358,12 +355,12 @@
sitemap and uses the session transformer. It could also read the
following
xml:</p>
<source><page
xmlns:session="http://cocoon.apache.org/session/1.0">
- <forename>
- <session:getxml context="request" path="/parameter/forename"/>
- </forename>
- <surname>
- <session:getxml context="request" path="/parameter/surname"/>
- </surname>
+ <forename>
+ <session:getxml context="request" path="/parameter/forename"/>
+ </forename>
+ <surname>
+ <session:getxml context="request" path="/parameter/surname"/>
+ </surname>
</page></source>
<p>As the form values are appended to the request, <em>getxml</em>
with specifying the path (which is the parameter name used for the
input field)
@@ -373,18 +370,18 @@
<source><page
xmlns:session="http://cocoon.apache.org/session/1.0">
<session:setxml context="userdata" path="/user">
<forename>
- <session:getxml context="request" path="/parameter/forename"/>
+ <session:getxml context="request" path="/parameter/forename"/>
</forename>
<surname>
- <session:getxml context="request" path="/parameter/surname"/>
+ <session:getxml context="request" path="/parameter/surname"/>
</surname>
</session:setxml>
</page></source>
<p>The user data is now stored inside the session context "userdata",
so the context has the following content:</p>
<source><user>
- <forename>Walter</forename>
- <surname>Walterson</surname>
+ <forename>Walter</forename>
+ <surname>Walterson</surname>
</user></source>
</s2>
<s2 title="The Session Framework approach">
@@ -397,15 +394,13 @@
stored inside the session.</p>
<p>The example from the previous chapter could look like this:</p>
<source><page
xmlns:session="http://cocoon.apache.org/session/1.0">
- <session:form name="myform">
- <session:action>the-next-page</session:action>
- <session:content>
- <session:inputxml name="forename" type="text"
- context="userdata" path="/user/forename"/>
- <session:inputxml name="surname" type="text"
- context="userdata" path="/user/surname"/>
- </session:content>
- </session:form>
+ <session:form name="myform">
+ <session:action>the-next-page</session:action>
+ <session:content>
+ <session:inputxml name="forename" type="text" context="userdata"
path="/user/forename"/>
+ <session:inputxml name="surname" type="text" context="userdata"
path="/user/surname"/>
+ </session:content>
+ </session:form>
</page></source>
<p>The form tag starts the form definition. The name attribute is
required to distinct between different forms on the same page. The
action tag
@@ -416,10 +411,10 @@
given path. The session transformer transforms by removing the
namespace and
the context attribute:</p>
<source><page
xmlns:session="http://cocoon.apache.org/session/1.0">
- <form action="the-next-page">
- <inputxml name="forename" type="text"/>
- <inputxml name="surname" type="text"/>
- </form>
+ <form action="the-next-page">
+ <inputxml name="forename" type="text"/>
+ <inputxml name="surname" type="text"/>
+ </form>
</page></source>
<p>A stylesheet can now generate the appropriate html (or any other
format). The main difference is, that the resource invoked by
submitting the
@@ -432,16 +427,16 @@
about the user - <em>inputxml</em> inserts the current value
inside the tag. So
the xml streamed would after a second run would look like this:</p>
<source><page
xmlns:session="http://cocoon.apache.org/session/1.0">
- <form action="the-next-page">
- <inputxml name="forename" type="text">Walter</inputxml>
- <inputxml name="surname"
type="text">Walterson</inputxml>
- </form>
+ <form action="the-next-page">
+ <inputxml name="forename" type="text">Walter</inputxml>
+ <inputxml name="surname" type="text">Walterson</inputxml>
+ </form>
</page></source>
<p>Like <em>getxml</em> it is also possible to provide default values
for the input field, if the context does not contain any
information:</p>
<source><session:inputxml name="forename" context="userdata"
path="/user/forename">
Defaultname
-</session:xml></source>
+</session:inputxml></source>
</s2>
</s1>
</body>
----------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
