Return-Path: Delivered-To: apmail-xml-cocoon-cvs-archive@xml.apache.org Received: (qmail 62393 invoked by uid 500); 8 May 2002 06:21:40 -0000 Mailing-List: contact cocoon-cvs-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: cocoon-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list cocoon-cvs@xml.apache.org Received: (qmail 62383 invoked by uid 500); 8 May 2002 06:21:40 -0000 Delivered-To: apmail-xml-cocoon2-cvs@apache.org Date: 8 May 2002 06:21:39 -0000 Message-ID: <20020508062139.23540.qmail@icarus.apache.org> From: cziegeler@apache.org To: xml-cocoon2-cvs@apache.org Subject: cvs commit: xml-cocoon2/src/documentation/xdocs/developing authentication.xml session.xml X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 [bert@vankets.com] 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:

- <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 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> - +</map:match>

If the pipeline does not use the "auth-protect" action or the parameter "handler" is missing, the resource is accessible by any user.

@@ -100,13 +98,13 @@ redirects to a special redirect-to resource. This resource is a mandatory configuration of the authentication handler:

<action name="auth-protect" ...> - <handlers> <!-- Now follows the handlers configuration --> - <handler name="unique"> - <redirect-to uri="cocoon://loginpage"/> <!-- The login resource --> - </handler> - </handlers> -</action> - + <handlers> + <!-- Now follows the handlers configuration --> + <handler name="unique"> + <redirect-to uri="cocoon://loginpage"/> <!-- The login resource --> + </handler> + </handlers> +</action>

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.

The authentication process is done by the "auth-login" action. The login resource contains this action:

- <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> + <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>

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:

<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>

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 @@

The logout process is triggered by the "auth-logout" action:

<map:act type="auth-logout"> - <map:parameter name="handler" value="unique"/> + <map:parameter name="handler" value="unique"/> </map:act>

This action logs the user out of the given handler and removes all information about this handler stored in the session.

@@ -299,15 +297,16 @@

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:

- <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: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> + </map:action> +</map:match> +

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.

@@ -334,19 +333,19 @@

The module configuration is part of the application configuration:

<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>

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 @@

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:

- <action name="auth-protect" ...> - <handlers> - <handler name="unique"> + <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>

The entries are described in the following subchapters. All tags can have additional parameter definitions which are passed to the given resource, e.g:

<!-- 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>

The load-roles 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:

<roles> - <role>admin</role> - <role>guest</role> - <role>user</role> + <role>admin</role> + <role>guest</role> + <role>user</role> </roles> @@ -423,14 +422,16 @@

The XML format of the resource should look like the following:

<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> @@ -464,40 +465,43 @@

Here is a brief summary of the authentication handler configuration:

- <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> + <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> @@ -516,13 +520,13 @@

Example:

<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>

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 @@

Example:

<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>

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.

<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>

In the example above, if the user is already logged he is redirected to the loggedInStartPage 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:

<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>

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!

<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> 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 @@

The following example shows the use of several commands and in particular how the mergexml command can be used to manipulate context data.

- -<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> - + <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>

In the above example, a context for storing data is added. Using the setxml command data is then stored into the context. The following mergexml command then changes the name of user-1 and adds a further @@ -204,78 +202,79 @@ "?param=aaa&...".

The complete context you can access via these commands has the following XML format:

- - <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> - + <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>

The response context is an XML description of the current @@ -301,19 +300,17 @@

Cookies can be added either by setxml or by appendxml. There is no difference between these commands.

<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> - + <!-- 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> @@ -345,11 +342,11 @@ of the user, you could generate a base xml file with the information about this form:

<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>

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:

<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>

As the form values are appended to the request, getxml with specifying the path (which is the parameter name used for the input field) @@ -373,18 +370,18 @@ <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>

The user data is now stored inside the session context "userdata", so the context has the following content:

<user> - <forename>Walter</forename> - <surname>Walterson</surname> + <forename>Walter</forename> + <surname>Walterson</surname> </user> @@ -397,15 +394,13 @@ stored inside the session.

The example from the previous chapter could look like this:

<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>

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:

<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>

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 - inputxml inserts the current value inside the tag. So the xml streamed would after a second run would look like this:

<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>

Like getxml it is also possible to provide default values for the input field, if the context does not contain any information:

<session:inputxml name="forename" context="userdata" path="/user/forename"> Defaultname -</session:xml> +</session:inputxml> ---------------------------------------------------------------------- In case of troubles, e-mail: webmaster@xml.apache.org To unsubscribe, e-mail: cocoon-cvs-unsubscribe@xml.apache.org For additional commands, e-mail: cocoon-cvs-help@xml.apache.org