Author: crossley Date: Wed Dec 29 22:55:55 2004 New Revision: 123702 URL: http://svn.apache.org/viewcvs?view=rev&rev=123702 Log: Zap the damn tab-characters!
Modified: cocoon/trunk/src/documentation/xdocs/userdocs/actions/database-actions.xml cocoon/trunk/src/documentation/xdocs/userdocs/actions/script-action.xml cocoon/trunk/src/documentation/xdocs/userdocs/actions/sendmail-action.xml cocoon/trunk/src/documentation/xdocs/userdocs/actions/session-action.xml cocoon/trunk/src/documentation/xdocs/userdocs/concepts/caching.xml cocoon/trunk/src/documentation/xdocs/userdocs/concepts/databases.xml cocoon/trunk/src/documentation/xdocs/userdocs/concepts/errorhandling.xml cocoon/trunk/src/documentation/xdocs/userdocs/concepts/modules.xml cocoon/trunk/src/documentation/xdocs/userdocs/concepts/mrustore.xml cocoon/trunk/src/documentation/xdocs/userdocs/concepts/sitemap.xml cocoon/trunk/src/documentation/xdocs/userdocs/concepts/xmlsearching.xml cocoon/trunk/src/documentation/xdocs/userdocs/flow/api.xml cocoon/trunk/src/documentation/xdocs/userdocs/flow/continuations.xml cocoon/trunk/src/documentation/xdocs/userdocs/flow/how-does-it-work.xml cocoon/trunk/src/documentation/xdocs/userdocs/flow/jxtemplate.xml cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_repeater_action.xml cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_row_action.xml cocoon/trunk/src/documentation/xdocs/userdocs/generators/extractor-generator.xml cocoon/trunk/src/documentation/xdocs/userdocs/generators/file-generator.xml cocoon/trunk/src/documentation/xdocs/userdocs/generators/html-generator.xml cocoon/trunk/src/documentation/xdocs/userdocs/generators/imagedirectory-generator.xml cocoon/trunk/src/documentation/xdocs/userdocs/generators/jsp-generator.xml cocoon/trunk/src/documentation/xdocs/userdocs/generators/request-generator.xml cocoon/trunk/src/documentation/xdocs/userdocs/generators/search-generator.xml cocoon/trunk/src/documentation/xdocs/userdocs/generators/serverpages-generator.xml cocoon/trunk/src/documentation/xdocs/userdocs/generators/status-generator.xml cocoon/trunk/src/documentation/xdocs/userdocs/generators/stream-generator.xml cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldb-generator.xml cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldbcollection-generator.xml cocoon/trunk/src/documentation/xdocs/userdocs/matchers/matchers.xml cocoon/trunk/src/documentation/xdocs/userdocs/matchers/template-matcher.xml cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcardheader-matcher.xml cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcarduri-matcher.xml cocoon/trunk/src/documentation/xdocs/userdocs/offline/ant.xml cocoon/trunk/src/documentation/xdocs/userdocs/offline/bean.xml cocoon/trunk/src/documentation/xdocs/userdocs/selectors/browser-selector.xml cocoon/trunk/src/documentation/xdocs/userdocs/selectors/host-selector.xml cocoon/trunk/src/documentation/xdocs/userdocs/selectors/parameter-selector.xml cocoon/trunk/src/documentation/xdocs/userdocs/selectors/regular-expression-header-selector.xml cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestattribute-selector.xml cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestparameter-selector.xml cocoon/trunk/src/documentation/xdocs/userdocs/selectors/selectors.xml cocoon/trunk/src/documentation/xdocs/userdocs/serializers/link-serializer.xml cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svg-serializer.xml cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svgtiff-serializer.xml cocoon/trunk/src/documentation/xdocs/userdocs/serializers/vrml-serializer.xml cocoon/trunk/src/documentation/xdocs/userdocs/serializers/ziparchive-serializer.xml cocoon/trunk/src/documentation/xdocs/userdocs/transformers/cinclude-transformer.xml cocoon/trunk/src/documentation/xdocs/userdocs/transformers/extractor-transformer.xml cocoon/trunk/src/documentation/xdocs/userdocs/transformers/filter-transformer.xml cocoon/trunk/src/documentation/xdocs/userdocs/transformers/ldap-transformer.xml cocoon/trunk/src/documentation/xdocs/userdocs/transformers/log-transformer.xml cocoon/trunk/src/documentation/xdocs/userdocs/transformers/readdomsession-transformer.xml cocoon/trunk/src/documentation/xdocs/userdocs/transformers/transformers.xml cocoon/trunk/src/documentation/xdocs/userdocs/transformers/writedomsession-transformer.xml cocoon/trunk/src/documentation/xdocs/userdocs/transformers/xslt-transformer.xml cocoon/trunk/src/documentation/xdocs/userdocs/xsp/esql.xml cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-concepts.xml cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-forms.xml cocoon/trunk/src/documentation/xdocs/userdocs/xsp/sendmail.xml Modified: cocoon/trunk/src/documentation/xdocs/userdocs/actions/database-actions.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/actions/database-actions.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/actions/database-actions.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/actions/database-actions.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/actions/database-actions.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/actions/database-actions.xml Wed Dec 29 22:55:55 2004 @@ -26,63 +26,63 @@ </header> <body> - <s1 title="Introduction"> - <p> - Two different sets of actions exist, that deal with (object) relational - database access through JDBC. The original database actions provide a - relatively simple interface to store, modify, delete and retrieve data. - They are oriented towards usage of request parameters for input and - request attributes together with sitemap variables for output and do - not support auto increment column types. In addition, the description of - the database structure is split over several files since these actions - attempt to use all tables in a provided description. - </p> - <p> - The modular database actions provide similar functionality. In contrast - to the original actions they allow to store the database meta data in a - single file and to switch input and output flexible through the use of - modules. Even for auto increment columns specific modules exist that - cover a wide range of database management systems. - </p> + <s1 title="Introduction"> + <p> + Two different sets of actions exist, that deal with (object) relational + database access through JDBC. The original database actions provide a + relatively simple interface to store, modify, delete and retrieve data. + They are oriented towards usage of request parameters for input and + request attributes together with sitemap variables for output and do + not support auto increment column types. In addition, the description of + the database structure is split over several files since these actions + attempt to use all tables in a provided description. + </p> + <p> + The modular database actions provide similar functionality. In contrast + to the original actions they allow to store the database meta data in a + single file and to switch input and output flexible through the use of + modules. Even for auto increment columns specific modules exist that + cover a wide range of database management systems. + </p> <p> For an overview of column types supported by the modular database actions, see javadocs for JDBCTypeConversions. The types supported by the original actions are documented in AbstractDatabaseAction. </p> - </s1> + </s1> - <s1 title="Original Database Actions"> - <p> - The original database actions have evolved quite a bit and at different - speeds. The add action is certainly the most complete one, providing - support for multiple tables and rows. However, the interface has become - a bit inconsistent. - </p> - <p> - If an error occurs, the original database actions will throw an - exception. - </p> - <s2 title="Describing the Structure of your DB - descriptor.xml"> - <p> - The key to database actions is a file that describes database meta - data in XML. The original actions will ignore all but the first table - and act only on one row. Only the add action will try to access all - tables that are contained in this description. As a consequence, each - HTML form needs to have a corresponding descriptor file if different - tables are affected. - </p> - <p> - The file name has no meaning and does not need to be - <code>descriptor.xml</code> - it can even be a Cocoon pipeline. The - name of the root element in a descriptor file is ignored. Only - <code>table</code> elements nested on first level inside the root - element are parsed by the actions. All unknown elements or attributes - are ignored. - </p> - <p> - For each table a <code>table</code> element needs to be present. - </p> - <source> + <s1 title="Original Database Actions"> + <p> + The original database actions have evolved quite a bit and at different + speeds. The add action is certainly the most complete one, providing + support for multiple tables and rows. However, the interface has become + a bit inconsistent. + </p> + <p> + If an error occurs, the original database actions will throw an + exception. + </p> + <s2 title="Describing the Structure of your DB - descriptor.xml"> + <p> + The key to database actions is a file that describes database meta + data in XML. The original actions will ignore all but the first table + and act only on one row. Only the add action will try to access all + tables that are contained in this description. As a consequence, each + HTML form needs to have a corresponding descriptor file if different + tables are affected. + </p> + <p> + The file name has no meaning and does not need to be + <code>descriptor.xml</code> - it can even be a Cocoon pipeline. The + name of the root element in a descriptor file is ignored. Only + <code>table</code> elements nested on first level inside the root + element are parsed by the actions. All unknown elements or attributes + are ignored. + </p> + <p> + For each table a <code>table</code> element needs to be present. + </p> + <source> <![CDATA[ <?xml version="1.0"?> @@ -98,113 +98,113 @@ </values> </table> </employee> -]]> - </source> - <p> - Describes a single table named "employee". In addition a database - connection is specified. See <link - href="../../developing/datasources.html">here</link> for more - information on database connections. - </p> +]]> + </source> + <p> + Describes a single table named "employee". In addition a database + connection is specified. See <link + href="../../developing/datasources.html">here</link> for more + information on database connections. + </p> - <s3 title="Key Columns"> - <p> - Tables may or may not have key columns. A key column is a column - that is part of the primary key. Actually, candidate keys should do - as well. - </p> - <p> - All key columns are contained in a <code>keys</code> child element - of the <code>table</code> element. Each column has a - <code>key</code> element to define its properties. The - <code>dbcol</code> attribute holds the column name, - <code>type</code> is the JDBC type name for this column (have a - look at AbstactDatabaseAction source for valid type names), - <code>param</code> specifies the name of the request parameter to - use, and <code>mode</code> sets how the value for this column is - obtained on adding a row. - </p> - <p> - Through the mode attribute the behaviour of the add action can be - changed. - </p> - <p> - Default mode is "automatic" and to let the database create the key - value by setting this value to <code>null</code>. The created value - can not be read back from the database and will not be available as - request attribute or sitemap variable. - </p> - <p> - A mode of "manual" will query the database for the maximum current - value, add 1 to it and use that for a value. - </p> - <p> - A mode of "form" will use the corresponding request parameter. - </p> - <p> - A mode of "request-attribute" will use the corresponding request - attribute. The name specified in the <code>param</code> attribute - will be automatically prefixed with the class name. - </p> - <p> - Key values will be propagated to sitemap variables and - prefixed - with the class name - request attributes. - </p> - </s3> - <s3 title="Other Columns"> - <p> - All other columns are contained in a <code>values</code> child - element of the <code>table</code> element. Each column has a - <code>value</code> element to define its properties. Properties are - similar to those for key columns. A <code>mode</code> attribute - does not exist for value columns. Instead, request parameters and - request attributes are tried in this order for the specified - parameter. - </p> - <p> - Request attribute names are <em>not</em> prefixed with the class - name. Thus, to insert the value of a key column of the previous row - or previous table into a value column, it needs to be named - <code>org.apache.cocoon.acting.AbstractDatabaseAction:key:table:dbcol</code>. - </p> - <p> - Value columns are propagated to request attributes with class name - prefix. They are not available for the sitemap. - </p> - </s3> - </s2> - </s1> - <s1 title="Modular Database Actions"> - <p> - The modular database actions were mainly created to make auto increment - columns available, handle input and output flexibly, and have a - consistent interface. A successful action will return the number of - rows affected in a sitemap parameter named <code>row-count</code>. The - added features required to change the descriptor file format in - incompatible ways. - </p> - <p> - It can be configured if an exception will be thrown when an error - occurs. - </p> - <s2 title="Describing the Structure of your DB - descriptor.xml"> - <p> - Like the original actions, the modular actions need meta data in an - XML file. However, that file may contain any number of tables, not - just the ones needed for a single request. The tables actually used - are referenced through a <code>table-set</code>. Unknown elements and - attributes are ignored. This way a descriptor file can be shared with - other actions like the form validator. - </p> - <p> - For the flexible input and output handling, the modular database - actions rely on <link href="../concepts/modules.html">modules</link>. - Have a look at those before proceeding. - </p> + <s3 title="Key Columns"> + <p> + Tables may or may not have key columns. A key column is a column + that is part of the primary key. Actually, candidate keys should do + as well. + </p> + <p> + All key columns are contained in a <code>keys</code> child element + of the <code>table</code> element. Each column has a + <code>key</code> element to define its properties. The + <code>dbcol</code> attribute holds the column name, + <code>type</code> is the JDBC type name for this column (have a + look at AbstactDatabaseAction source for valid type names), + <code>param</code> specifies the name of the request parameter to + use, and <code>mode</code> sets how the value for this column is + obtained on adding a row. + </p> + <p> + Through the mode attribute the behaviour of the add action can be + changed. + </p> + <p> + Default mode is "automatic" and to let the database create the key + value by setting this value to <code>null</code>. The created value + can not be read back from the database and will not be available as + request attribute or sitemap variable. + </p> + <p> + A mode of "manual" will query the database for the maximum current + value, add 1 to it and use that for a value. + </p> + <p> + A mode of "form" will use the corresponding request parameter. + </p> + <p> + A mode of "request-attribute" will use the corresponding request + attribute. The name specified in the <code>param</code> attribute + will be automatically prefixed with the class name. + </p> + <p> + Key values will be propagated to sitemap variables and - prefixed + with the class name - request attributes. + </p> + </s3> + <s3 title="Other Columns"> + <p> + All other columns are contained in a <code>values</code> child + element of the <code>table</code> element. Each column has a + <code>value</code> element to define its properties. Properties are + similar to those for key columns. A <code>mode</code> attribute + does not exist for value columns. Instead, request parameters and + request attributes are tried in this order for the specified + parameter. + </p> + <p> + Request attribute names are <em>not</em> prefixed with the class + name. Thus, to insert the value of a key column of the previous row + or previous table into a value column, it needs to be named + <code>org.apache.cocoon.acting.AbstractDatabaseAction:key:table:dbcol</code>. + </p> + <p> + Value columns are propagated to request attributes with class name + prefix. They are not available for the sitemap. + </p> + </s3> + </s2> + </s1> + <s1 title="Modular Database Actions"> + <p> + The modular database actions were mainly created to make auto increment + columns available, handle input and output flexibly, and have a + consistent interface. A successful action will return the number of + rows affected in a sitemap parameter named <code>row-count</code>. The + added features required to change the descriptor file format in + incompatible ways. + </p> + <p> + It can be configured if an exception will be thrown when an error + occurs. + </p> + <s2 title="Describing the Structure of your DB - descriptor.xml"> + <p> + Like the original actions, the modular actions need meta data in an + XML file. However, that file may contain any number of tables, not + just the ones needed for a single request. The tables actually used + are referenced through a <code>table-set</code>. Unknown elements and + attributes are ignored. This way a descriptor file can be shared with + other actions like the form validator. + </p> + <p> + For the flexible input and output handling, the modular database + actions rely on <link href="../concepts/modules.html">modules</link>. + Have a look at those before proceeding. + </p> <p> The following is a snippet from a descriptor file. </p> - <source> + <source> <![CDATA[ <root> <connection>personnel</connection> @@ -232,81 +232,81 @@ name. In such a case modifications like update, insert, delete will likely fail. </p> - <p> - Another application of aliases if different numbers of columns should - be affected by an operation. or if a table contains several candidate - keys that are used alternatively. This way, different views to a - table can be created. - </p> - <s3 title="Key Columns"> - <p> - The descriptor file resembles the one for the original actions. One - major difference is the absence of <code>dbcol</code> and - <code>param</code> attributes. Instead there is a <code>name</code> - attribute which corresponds to the <code>dbcol</code> attribute and - specifies the database column name. - </p> - <p> - If a column is an auto increment column, the similar named attribute - indicates this. Auto increment columns will be handled differently - on insert operations. - </p> - <p> - Instead of specifying a parameter name, the actions support to use - different input modules for each operation through the nested - <code>mode</code> elements. This is described in more detail below. - </p> - <p> - Note here though, that not every column needs a <code>mode</code> - element: The actions default to the module defined as - <code>request</code> which is in a default installation to obtain - the values from request parameters. The name of the parameter - defaults to table name dot column name. - </p> - </s3> - <s3 title="Other Columns"> - <p> + <p> + Another application of aliases if different numbers of columns should + be affected by an operation. or if a table contains several candidate + keys that are used alternatively. This way, different views to a + table can be created. + </p> + <s3 title="Key Columns"> + <p> + The descriptor file resembles the one for the original actions. One + major difference is the absence of <code>dbcol</code> and + <code>param</code> attributes. Instead there is a <code>name</code> + attribute which corresponds to the <code>dbcol</code> attribute and + specifies the database column name. + </p> + <p> + If a column is an auto increment column, the similar named attribute + indicates this. Auto increment columns will be handled differently + on insert operations. + </p> + <p> + Instead of specifying a parameter name, the actions support to use + different input modules for each operation through the nested + <code>mode</code> elements. This is described in more detail below. + </p> + <p> + Note here though, that not every column needs a <code>mode</code> + element: The actions default to the module defined as + <code>request</code> which is in a default installation to obtain + the values from request parameters. The name of the parameter + defaults to table name dot column name. + </p> + </s3> + <s3 title="Other Columns"> + <p> Apart from the fact that the auto increment columns are only - supported for key columns, everything said above applies to value - columns as well. + supported for key columns, everything said above applies to value + columns as well. </p> - </s3> - <s3 title="Operation Mode Types"> - <p> - Basically, two different mode types exist: - <code>autoincrement</code> which is used whenever data shall be - inserted into a table and this particular key column has the - auto increment attribute set and <code>others</code> for all other - requirements. + </s3> + <s3 title="Operation Mode Types"> + <p> + Basically, two different mode types exist: + <code>autoincrement</code> which is used whenever data shall be + inserted into a table and this particular key column has the + auto increment attribute set and <code>others</code> for all other + requirements. </p> <p> In addition, a table-set can specify different mode types to use - instead of the predefined type names. Through this, and the fact - that every mode can specify a different input module, it is easy to - use different input modules for different tasks and forms. + instead of the predefined type names. Through this, and the fact + that every mode can specify a different input module, it is easy to + use different input modules for different tasks and forms. </p> <p> One special mode type name exists that matches all requested ones: - <code>all</code> This makes it easier to configure only some - columns differently for each table-set. + <code>all</code> This makes it easier to configure only some + columns differently for each table-set. </p> - </s3> - <s3 title="How to obtain Values"> - <p> - As said above, these actions default to reading from request - parameters with a default parameter name. By specifying - <code>mode</code> elements, this can be overridden. Any component - that implements the <code>InputModule</code> interface can be used - to obtain values. How to make such modules known to Apache Cocoon - is described <link href="../concepts/modules.html">elsewhere</link>. - </p> - <p> - Beside using different input modules, their parameters can be set - in place, for example to override parameter names, configure a - random generator or a message digest algorithm. - </p> + </s3> + <s3 title="How to obtain Values"> + <p> + As said above, these actions default to reading from request + parameters with a default parameter name. By specifying + <code>mode</code> elements, this can be overridden. Any component + that implements the <code>InputModule</code> interface can be used + to obtain values. How to make such modules known to Apache Cocoon + is described <link href="../concepts/modules.html">elsewhere</link>. + </p> + <p> + Beside using different input modules, their parameters can be set + in place, for example to override parameter names, configure a + random generator or a message digest algorithm. + </p> - <source> + <source> <![CDATA[ <table name="user_groups"> <keys> @@ -326,84 +326,84 @@ </keys> </table> ]]> - </source> - <p> - The above example shows just that: the <code>parameter</code> - element is not read by the database action itself but the - complete <code>mode</code> configuration object is passed to the - input module. Both the request attribute and the request parameter - input modules understand this parameter attribute which takes - precedence over the default one. - </p> - <p> - Another feature when obtaining values is tied to the - <code>type</code> attribute: Different modes can be used in - different situations. The basic setup uses two different mode - types: <code>autoincrement</code> when inserting in key columns - that have an indicator that they are indeed auto increment columns - and <code>others</code> for insert operations on all other columns - and all other operations on all columns. - </p> - <p> - Table-sets can override the default names for these two mode type - name categories with arbitrary names except the special name - <code>all</code>. A mode that carries the type name "all" is used - with all requested type names. Lookup obeys first match principle - so that all modes are tested from top to bottom and the first that - matches is used. - </p> - </s3> - <s3 title="How to store Values e.g. in your Session"> - <p> - All modular database action can be configured to use any component - that implements the <code>OutputModule</code> interface to store - values. The output module is chosen on declaring the action in the - sitemap or dynamically with a sitemap parameter. If no output - module is specified, the default it to use the request attribute - module. - </p> - <p> - The interface does not allow to pass configuration information to - the output module. This has to be done when the module is declared - e.g. in cocoon.xconf. - </p> - </s3> - <s3 title="Inserting Multiple Rows - Sets"> - <p> - Once common task is to work on more than one row. If the rows are - in different tables, this is catered for by table-sets. Operating - on multiple rows of one table requires to mark columns that should - vary and among those one, that determines the number of rows to - work on. - </p> - <p> - This is done with sets. All columns that cary a <code>set</code> - attribute can vary, those, that don't, are kept fixed during the - operation. The column that is used to determine the number of rows - is required to have a value of <code>master</code> while all others - need to have a value of <code>slave</code> for the set - attribute. There may be only one master in a set. - </p> - <p> - Sets can be tagged either on column or on mode level but not both - for a single column. - </p> - </s3> - <s3 title="Select Your Tables - Table-Sets"> - <p> - Tables that should be used during an operation can be grouped - together with a table-set. A table-set references tables by their - name or their alias. - </p> - <p> - In addition, a table-set can override the mode type names for the - two categories "autoincrement" and "others". - </p> - <p> - Operations spanning multiple tables in a table-set are done in a - single transaction. Thus, if one fails, the other is rolled back. - </p> - <source> + </source> + <p> + The above example shows just that: the <code>parameter</code> + element is not read by the database action itself but the + complete <code>mode</code> configuration object is passed to the + input module. Both the request attribute and the request parameter + input modules understand this parameter attribute which takes + precedence over the default one. + </p> + <p> + Another feature when obtaining values is tied to the + <code>type</code> attribute: Different modes can be used in + different situations. The basic setup uses two different mode + types: <code>autoincrement</code> when inserting in key columns + that have an indicator that they are indeed auto increment columns + and <code>others</code> for insert operations on all other columns + and all other operations on all columns. + </p> + <p> + Table-sets can override the default names for these two mode type + name categories with arbitrary names except the special name + <code>all</code>. A mode that carries the type name "all" is used + with all requested type names. Lookup obeys first match principle + so that all modes are tested from top to bottom and the first that + matches is used. + </p> + </s3> + <s3 title="How to store Values e.g. in your Session"> + <p> + All modular database action can be configured to use any component + that implements the <code>OutputModule</code> interface to store + values. The output module is chosen on declaring the action in the + sitemap or dynamically with a sitemap parameter. If no output + module is specified, the default it to use the request attribute + module. + </p> + <p> + The interface does not allow to pass configuration information to + the output module. This has to be done when the module is declared + e.g. in cocoon.xconf. + </p> + </s3> + <s3 title="Inserting Multiple Rows - Sets"> + <p> + Once common task is to work on more than one row. If the rows are + in different tables, this is catered for by table-sets. Operating + on multiple rows of one table requires to mark columns that should + vary and among those one, that determines the number of rows to + work on. + </p> + <p> + This is done with sets. All columns that cary a <code>set</code> + attribute can vary, those, that don't, are kept fixed during the + operation. The column that is used to determine the number of rows + is required to have a value of <code>master</code> while all others + need to have a value of <code>slave</code> for the set + attribute. There may be only one master in a set. + </p> + <p> + Sets can be tagged either on column or on mode level but not both + for a single column. + </p> + </s3> + <s3 title="Select Your Tables - Table-Sets"> + <p> + Tables that should be used during an operation can be grouped + together with a table-set. A table-set references tables by their + name or their alias. + </p> + <p> + In addition, a table-set can override the mode type names for the + two categories "autoincrement" and "others". + </p> + <p> + Operations spanning multiple tables in a table-set are done in a + single transaction. Thus, if one fails, the other is rolled back. + </p> + <source> <![CDATA[ <table name="groups"> @@ -436,9 +436,9 @@ </root> ]]> - </source> - </s3> - </s2> - </s1> + </source> + </s3> + </s2> + </s1> </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/actions/script-action.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/actions/script-action.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/actions/script-action.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/actions/script-action.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/actions/script-action.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/actions/script-action.xml Wed Dec 29 22:55:55 2004 @@ -16,7 +16,7 @@ --> <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <!-- - <![CDATA[ CVS Version: $Id: script-action.xml,v 1.5 2004/05/08 08:57:55 crossley Exp $ + <![CDATA[ CVS Version: $Id$ ]]> --><document> <header> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/actions/sendmail-action.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/actions/sendmail-action.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/actions/sendmail-action.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/actions/sendmail-action.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/actions/sendmail-action.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/actions/sendmail-action.xml Wed Dec 29 22:55:55 2004 @@ -235,7 +235,7 @@ argument does not contain a colon, the argument names a request parameter which is a file upload through a HTML form (internally an <code>org.apache.cocoon.components.request.multipart.FilePart</code> - object). + object). </td> </tr> <!-- [CH] I believe deleting attachments should be handled at a different place Modified: cocoon/trunk/src/documentation/xdocs/userdocs/actions/session-action.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/actions/session-action.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/actions/session-action.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/actions/session-action.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/actions/session-action.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/actions/session-action.xml Wed Dec 29 22:55:55 2004 @@ -42,7 +42,7 @@ <source> <![CDATA[ <map:act type="session"/> -]]> +]]> </source> <p>This is the equivalent to specify the 'action' parameter with the value 'create':</p> @@ -51,7 +51,7 @@ <map:act type="session"> <map:parameter name="action" value="create"/> </map:act> -]]> +]]> </source> </s2> <s2 title="Terminating a Session"> @@ -63,7 +63,7 @@ <map:act type="session"> <map:parameter name="action" value="terminate"/> </map:act> -]]> +]]> </source> <p>This terminates the session immediately.</p> <p>You can optionally specifiy the 'mode' parameter which controlls @@ -77,7 +77,7 @@ <map:parameter name="action" value="terminate"/> <map:parameter name="mode" value="if-unused"/> </map:act> -]]> +]]> </source> </s2> </s1> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/concepts/caching.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/concepts/caching.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/caching.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/caching.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/concepts/caching.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/concepts/caching.xml Wed Dec 29 22:55:55 2004 @@ -18,30 +18,30 @@ <document> <header> - <title>Caching</title> - <version>0.9</version> - <type>Technical document</type> - <authors><person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document explains the basic caching algorithm of Apache Cocoon.</abstract> + <title>Caching</title> + <version>0.9</version> + <type>Technical document</type> + <authors><person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document explains the basic caching algorithm of Apache Cocoon.</abstract> </header> <body> - <s1 title="Goal"> - <p>This document explains the basic caching algorithm of Apache Cocoon.</p> - </s1> - <s1 title="Overview"> - <p>The caching algorithm of Cocoon has a very flexible and powerful design. + <s1 title="Goal"> + <p>This document explains the basic caching algorithm of Apache Cocoon.</p> + </s1> + <s1 title="Overview"> + <p>The caching algorithm of Cocoon has a very flexible and powerful design. The algorithms and components used are not hard coded into the core of Cocoon. They can be configured in the sitemap.</p> <p>This document describes the components available for caching, how they can be configured and how to implement your own cacheable components. </p> - </s1> - <s1 title="How to Configure Caching"> - <p>The caching can be turned on and off on a per pipeline setting in the sitemap. - This means, for each <em>map:pipeline</em> section in a sitemap, it's possible to - turn on/off caching and configure the caching algorithm.</p> - <p>The following example shows how to turn on caching for a pipeline:</p> + </s1> + <s1 title="How to Configure Caching"> + <p>The caching can be turned on and off on a per pipeline setting in the sitemap. + This means, for each <em>map:pipeline</em> section in a sitemap, it's possible to + turn on/off caching and configure the caching algorithm.</p> + <p>The following example shows how to turn on caching for a pipeline:</p> <source> <![CDATA[ <map:pipeline type="caching"> @@ -49,8 +49,8 @@ </map:pipeline> ]]> </source> - <p>If you know that it doesn't make sense to turn on caching for some of - your pipelines, put them together in their own section and use:</p> + <p>If you know that it doesn't make sense to turn on caching for some of + your pipelines, put them together in their own section and use:</p> <source> <![CDATA[ <map:pipeline type="noncaching"> @@ -75,57 +75,57 @@ <p>Depending on your Cocoon installation you might have different implementations in that section. As with all components, you can define a default for all pipelines and override this whereever it makes sense.</p> - </s1> - <s1 title="The Default Caching Algorithm"> - <p>The default algorithm uses a very easy but effective approach + </s1> + <s1 title="The Default Caching Algorithm"> + <p>The default algorithm uses a very easy but effective approach to cache a request: The pipeline process is cached up to the most possible point.</p> <p>Therefore each component in the pipeline is queried by Cocoon if it supports caching. Several components, like the file generator or the xslt transformer support caching. However, dynamic components like the sql transformer or the cinclude transformer do not. Let's have a look at some examples:</p> - <s2 title="Simple Examples"> - <p>If you have the following pipeline:</p> + <s2 title="Simple Examples"> + <p>If you have the following pipeline:</p> <p>Generator[type=file|src=a.xml] -> Transformer[type="xslt"|src=a.xsl] -> Serializer</p> - <p>The file generator is cacheable and generates a key which uses the src + <p>The file generator is cacheable and generates a key which uses the src (or the filename) to build the key. The cache uses the last modification date of the xml file to test if the cached content is valid.</p> - <p>The xslt transformer is cacheable and generates a key which uses + <p>The xslt transformer is cacheable and generates a key which uses the filename to build the unique key. The cache validity object uses the last modification date of the xslt file.</p> <p>The default serializer (html) supports the caching as well.</p> - <p>All three keys are used to build a unique key for this pipeline. + <p>All three keys are used to build a unique key for this pipeline. The first time it is invoked its response is cached. The second time this pipeline is called, the cached content is get from the cache. If it is still valid, the cached content is directly send to the client.</p> </s2> <s2 title="Complex Example"> - <p>Only part of the following pipeline is cached:</p> + <p>Only part of the following pipeline is cached:</p> <p>Generator[type=file|src=a.xml] -> Transformer[type="xslt"|src=a.xsl] -> Transformer[type=sql] -> Transformer[type="xslt"|src=b.xsl] -> Serializer</p> - <p>The file generator is cacheable and generates a key which uses the src + <p>The file generator is cacheable and generates a key which uses the src (or the filename) to build the key. The cache uses the last modification date of the xml file to test if the cached content is valid.</p> - <p>The xslt transformer is cacheable and generates a key which uses + <p>The xslt transformer is cacheable and generates a key which uses the filename to build the unique key. The cache validity object uses the last modification date of the xslt file.</p> - <p>The sql transformer is not cacheable, so the caching algorithm stops - at this point although the last transformer is cacheable again.</p> - <p>The cached response is the output of the first xslt transformer, so when the - next request comes in and the cached content is valid, the cached content is - directly feed into the sql transformer. The generator and the first - xslt transformer are not executed.</p> - </s2> - <s2 title="Making Components Cacheable"> - <p>This chapter is only for developers of own sitemap components. It details what you have - to do when you want that your own sitemap components supports the caching.</p> - <p>Each sitemap component (generator or transformer) which might be + <p>The sql transformer is not cacheable, so the caching algorithm stops + at this point although the last transformer is cacheable again.</p> + <p>The cached response is the output of the first xslt transformer, so when the + next request comes in and the cached content is valid, the cached content is + directly feed into the sql transformer. The generator and the first + xslt transformer are not executed.</p> + </s2> + <s2 title="Making Components Cacheable"> + <p>This chapter is only for developers of own sitemap components. It details what you have + to do when you want that your own sitemap components supports the caching.</p> + <p>Each sitemap component (generator or transformer) which might be cacheable must implement the CacheableProcessingComponent interface. When the pipeline is processed each sitemap component starting with the generator is asked if it implements this interface. This test stops either when the first component does not implement the CacheableProcessingComponent interface or when the first cacheable component is currently not cacheable for any reasons (more about this in a moment).</p> - <p>The CacheableProcessingComponent interface declares a method <code>getKey()</code> + <p>The CacheableProcessingComponent interface declares a method <code>getKey()</code> which must produce a unique key for this sitemap component inside the component space. For example the FileGenerator returns the source argument (the xml document read). All parameters/values @@ -136,7 +136,7 @@ <p>If for any reason the sitemap component detects that the current request is not cacheable it can simply return <code>null</code> as the key. This has the same effect as not declaring the CacheableProcessingComponent interface.</p> - <p>Now after the key is build for this particular request, it is looked up + <p>Now after the key is build for this particular request, it is looked up in the cache if it exists. If not, the new request is generated and cached for further requests.</p> <p>If a cached response is found for the key, the caching algorithm checks @@ -159,32 +159,32 @@ from the cache, the new response is generated and then stored together with the new validity objects in the cache.</p> </s2> - </s1> - <s1 title="Configuration"> - <p>The caching of Cocoon can be completely configured by different Avalon + </s1> + <s1 title="Configuration"> + <p>The caching of Cocoon can be completely configured by different Avalon components. This chapter describes how the various components work together.</p> - <s2 title="Configuration of Pipelines"> - <p>Each pipeline can be configured with a buffer size, and each - caching pipeline with the name of the Cache to use.</p> - <s3 title="Expiration of Content"> - <p> - Utilize the pipeline <code>expires</code> parameter to dramatically reduce - redundand requests. Even the most dynamic application pages have a - reasonable period of time during which they are static. - Even if a page doesn't change for just one minute, still use the - <code>expires</code> parameter. Here is an example: - </p> + <s2 title="Configuration of Pipelines"> + <p>Each pipeline can be configured with a buffer size, and each + caching pipeline with the name of the Cache to use.</p> + <s3 title="Expiration of Content"> + <p> + Utilize the pipeline <code>expires</code> parameter to dramatically reduce + redundand requests. Even the most dynamic application pages have a + reasonable period of time during which they are static. + Even if a page doesn't change for just one minute, still use the + <code>expires</code> parameter. Here is an example: + </p> <source><![CDATA[ <map:pipeline> <map:parameter name="expires" value="access plus 1 minutes"/> ... </map:pipeline> ]]></source> - <p> - The value of the parameter is in a format borrowed from the Apache HTTP module mod_expires. - Examples of other possible values are: - </p> + <p> + The value of the parameter is in a format borrowed from the Apache HTTP module mod_expires. + Examples of other possible values are: + </p> <source><![CDATA[ access plus 1 hours access plus 1 month @@ -192,27 +192,27 @@ access plus 30 days access plus 1 month 15 days 2 hours ]]></source> - <p> - Imagine 1'000 users hitting your web site at the same time. - Say that they are split into 5 groups, each of which has the same ISP. - Most ISPs use intermediate proxy servers to reduce traffic, hense - improving their end user experience and also reducing their operating costs. - In our case the 1'000 end user requests will result in just 5 requests to Cocoon. - </p> - <p> - After the first request from each group reaches the server, the expires header will - be recognized by the proxy servers which will serve the following requests from their cache. - Keep in mind however that most proxies cache HTTP GET requests, but will not cache HTTP POST requests. - </p> - <p> - To feel the difference, set an expires parameter on one of your pipelines and - load the page with the browser. Notice that after the first time, there are no - access records in the server logs until the specified time expires. - </p> - <p>This parameter has effect on all pipeline implementations, even on - the non caching ones. Remember, the caching does not take place in Cocoon, - it's either in a proxy inbetween Cocoon and the client or in the client - itself.</p> + <p> + Imagine 1'000 users hitting your web site at the same time. + Say that they are split into 5 groups, each of which has the same ISP. + Most ISPs use intermediate proxy servers to reduce traffic, hense + improving their end user experience and also reducing their operating costs. + In our case the 1'000 end user requests will result in just 5 requests to Cocoon. + </p> + <p> + After the first request from each group reaches the server, the expires header will + be recognized by the proxy servers which will serve the following requests from their cache. + Keep in mind however that most proxies cache HTTP GET requests, but will not cache HTTP POST requests. + </p> + <p> + To feel the difference, set an expires parameter on one of your pipelines and + load the page with the browser. Notice that after the first time, there are no + access records in the server logs until the specified time expires. + </p> + <p>This parameter has effect on all pipeline implementations, even on + the non caching ones. Remember, the caching does not take place in Cocoon, + it's either in a proxy inbetween Cocoon and the client or in the client + itself.</p> </s3> <s3 title="Response Buffering"> <p>Each pipeline can buffer the response, before it is send to the client. @@ -264,40 +264,40 @@ particular pipeline. Please note, that the parameter element does have the sitemap namespace!</p> </s3> - </s2> - <s2 title="Configuration of Caches"> - <p>Each cache can be configured with the store to use.</p> - </s2> - <s2 title="Configuration of Stores"> - <p>Have a look at the store configuration.</p> - </s2> - </s1> - <s1 title="Additional Information for Developers"> - <s2 title="Java APIs"> - <p>For more information on the java apis refer directly to the + </s2> + <s2 title="Configuration of Caches"> + <p>Each cache can be configured with the store to use.</p> + </s2> + <s2 title="Configuration of Stores"> + <p>Have a look at the store configuration.</p> + </s2> + </s1> + <s1 title="Additional Information for Developers"> + <s2 title="Java APIs"> + <p>For more information on the java apis refer directly to the javadocs of Cocoon.</p> <p>The most important packages are:</p> - <ol> - <li><code>org.apache.cocoon.caching</code>: This package declares all interfaces for caching.</li> - <li><code>org.apache.cocoon.components.pipeline</code>: The interfaces and implementations of the pipelines.</li> - </ol> - </s2> - <s2 title="The XMLSerializer/XMLDeserializer"> - <p>The caching of the sax events is implemented by two Avalon components: + <ol> + <li><code>org.apache.cocoon.caching</code>: This package declares all interfaces for caching.</li> + <li><code>org.apache.cocoon.components.pipeline</code>: The interfaces and implementations of the pipelines.</li> + </ol> + </s2> + <s2 title="The XMLSerializer/XMLDeserializer"> + <p>The caching of the sax events is implemented by two Avalon components: The XMLSerializer and the XMLDeserializer. The XMLSerializer gets sax events and creates an object which is used by the XMLDeserializer to recreate these sax events.</p> - <s3 title="org.apache.cocoon.components.sax.XMLByteStreamCompiler"> - <p>The <code>XMLByteStreamCompiler</code>compiles sax events into a byte stream.</p> - </s3> - <s3 title="org.apache.cocoon.components.sax.XMLByteStreamInterpreter"> - <p>The <code>XMLByteStreamInterpreter</code> is the counterpart of the - <code>XMLByteStreamCompiler</code>. It interprets the byte + <s3 title="org.apache.cocoon.components.sax.XMLByteStreamCompiler"> + <p>The <code>XMLByteStreamCompiler</code>compiles sax events into a byte stream.</p> + </s3> + <s3 title="org.apache.cocoon.components.sax.XMLByteStreamInterpreter"> + <p>The <code>XMLByteStreamInterpreter</code> is the counterpart of the + <code>XMLByteStreamCompiler</code>. It interprets the byte stream and creates sax events.</p> - </s3> - <s3 title="Configuration"> - <p>The XMLSerializer and XMLDeserialzer are two Avalon components which - can be configured in the cocoon.xconf:</p> + </s3> + <s3 title="Configuration"> + <p>The XMLSerializer and XMLDeserialzer are two Avalon components which + can be configured in the cocoon.xconf:</p> <source> <![CDATA[ <xml-serializer @@ -307,14 +307,14 @@ class="org.apache.cocoon.components.sax.XMLByteStreamInterpreter"/> ]]> </source> - <p>You must assure that the correct (or matching) deserializer is + <p>You must assure that the correct (or matching) deserializer is configured for the serializer.</p> <p>Both components are poolable, so make sure you set appropriate pool sizes for these components. For more information on component pooling have a look at the Avalon documentation.</p> - </s3> - </s2> - </s1> + </s3> + </s2> + </s1> </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/concepts/databases.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/concepts/databases.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/databases.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/databases.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/concepts/databases.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/concepts/databases.xml Wed Dec 29 22:55:55 2004 @@ -27,118 +27,118 @@ <body> - <s1 title="Introduction"> - <p> - Publishing dynamic content or creating web-applications - eventually involves database access. Apache Cocoon - offers a number of different approaches to access - (object) relational and XML databases. This document provides - an overview of the different ways to access (object) - relational databases. - </p> - <p> - This document will not explain how to set up database - connectivity with Apache Cocoon. For this, see <link - href="../../developing/datasources.html">here.</link> - </p> - <p> - Basically, there are three different approaches available: - <link href="actions.html">Actions,</link> <link - href="../xsp/logicsheet-concepts.html">logicsheets,</link> - and <link href="sitemap.html">transformers.</link> Each approach has - its pros and cons. - </p> - </s1> + <s1 title="Introduction"> + <p> + Publishing dynamic content or creating web-applications + eventually involves database access. Apache Cocoon + offers a number of different approaches to access + (object) relational and XML databases. This document provides + an overview of the different ways to access (object) + relational databases. + </p> + <p> + This document will not explain how to set up database + connectivity with Apache Cocoon. For this, see <link + href="../../developing/datasources.html">here.</link> + </p> + <p> + Basically, there are three different approaches available: + <link href="actions.html">Actions,</link> <link + href="../xsp/logicsheet-concepts.html">logicsheets,</link> + and <link href="sitemap.html">transformers.</link> Each approach has + its pros and cons. + </p> + </s1> - <s1 title="Actions Approach"> - <p> - <link href="actions.html">Actions</link> are code to be executed - during pipeline setup. The outcome of an action can change how a pipeline is - assembled. For example, a pipeline may produce an alternative - page to display upon failure of a particular database operation. - </p> - <p> - Actions are especially great for inserting, changing, or deleting data. - Employing the pipeline-switching features of actions will simplify your - pages. Such actions are concerned with only one view: either the success - or failure of an operation. - </p> - <p> - Actions can be useful, even when data is not provided by users. - For example, you could store tracking information in a database in - a central location without the need to modify every page. - </p> - <p> - Database actions can read and return data from a database. This is - useful when the pipeline assembly depends upon such data. It's also - useful when setting up an environment for XSP processing. - </p> - <p> - Once the database meta data is captured in an XML descriptor file, - making use of these actions is simply a matter of placing them in a pipeline. - This is a major advantage of the action approach. No programming is - required, not even SQL query writing. - </p> - <p> - For more detailed information, read: <link - href="../actions/database-actions.html">Database Actions</link>. - </p> - </s1> + <s1 title="Actions Approach"> + <p> + <link href="actions.html">Actions</link> are code to be executed + during pipeline setup. The outcome of an action can change how a pipeline is + assembled. For example, a pipeline may produce an alternative + page to display upon failure of a particular database operation. + </p> + <p> + Actions are especially great for inserting, changing, or deleting data. + Employing the pipeline-switching features of actions will simplify your + pages. Such actions are concerned with only one view: either the success + or failure of an operation. + </p> + <p> + Actions can be useful, even when data is not provided by users. + For example, you could store tracking information in a database in + a central location without the need to modify every page. + </p> + <p> + Database actions can read and return data from a database. This is + useful when the pipeline assembly depends upon such data. It's also + useful when setting up an environment for XSP processing. + </p> + <p> + Once the database meta data is captured in an XML descriptor file, + making use of these actions is simply a matter of placing them in a pipeline. + This is a major advantage of the action approach. No programming is + required, not even SQL query writing. + </p> + <p> + For more detailed information, read: <link + href="../actions/database-actions.html">Database Actions</link>. + </p> + </s1> - <s1 title="ESQL Logicsheet Approach"> - <p> - The use of logicsheets is limited to XSPs. ESQL is currently available - for Java-based XSPs. Its interface is modeled largely on - JDBC. Thus, it is advantageous to be familiar with JDBC. - </p> - <p> - ESQL is great when reading data from a database. However, it is less attractive - to use when it has to react to operation failures. This is due to the fact - that it adds a layer of complexity to an XSP file, making it - more difficult to understand and maintain. - </p> - <p> - Complex layouts of the data are easy to achieve. ESQL allows - the arbitrary nesting of queries and connections. It also provides support for - stored procedures and complex data types. ESQL provides a means to - create a structured representation of the database data with a single tag. - This is useful when generating reports to use - with other XML-aware software or to be formated with XSL or CSS2. - XML data can be retrieved from the - database and included in the output. With some supported database - management systems, ESQL supports skipping part of the - resultset as well as limiting the result. - Given the full power of Java available within XSP, - any processing of the data is possible. - </p> - <p> - For more detailed information, read: <link - href="../xsp/esql.html">ESQL Taglib</link>. - </p> - </s1> + <s1 title="ESQL Logicsheet Approach"> + <p> + The use of logicsheets is limited to XSPs. ESQL is currently available + for Java-based XSPs. Its interface is modeled largely on + JDBC. Thus, it is advantageous to be familiar with JDBC. + </p> + <p> + ESQL is great when reading data from a database. However, it is less attractive + to use when it has to react to operation failures. This is due to the fact + that it adds a layer of complexity to an XSP file, making it + more difficult to understand and maintain. + </p> + <p> + Complex layouts of the data are easy to achieve. ESQL allows + the arbitrary nesting of queries and connections. It also provides support for + stored procedures and complex data types. ESQL provides a means to + create a structured representation of the database data with a single tag. + This is useful when generating reports to use + with other XML-aware software or to be formated with XSL or CSS2. + XML data can be retrieved from the + database and included in the output. With some supported database + management systems, ESQL supports skipping part of the + resultset as well as limiting the result. + Given the full power of Java available within XSP, + any processing of the data is possible. + </p> + <p> + For more detailed information, read: <link + href="../xsp/esql.html">ESQL Taglib</link>. + </p> + </s1> - <s1 title="SQL Transformer Approach"> - <p> - An approach using the SQL transformer can be combined with any kind - of page. This will result in slightly cleaner pages as you don't need - some of the setup that an ESQL approach requires. - </p> - <p> - On the other hand, it is more or less impossible to react to operation - failures. This is due to the fact that the pipeline is already assembled - and the necessary logic to handle such failures is not - available inside the SQL transformer, unless of course, you are willing - to write a custom transformer. - Thus, the transformer approach is best for retrieving data. Creating - an XML representation of the query result is even simpler than when - using the ESQL logicsheet. The transformer also supports stored procedures. - No programming is required, apart from writing SQL. - </p> - <p> - For more detailed information, read: <link - href="../transformers/sql-transformer.html">SQL Transformer</link>. - </p> - </s1> + <s1 title="SQL Transformer Approach"> + <p> + An approach using the SQL transformer can be combined with any kind + of page. This will result in slightly cleaner pages as you don't need + some of the setup that an ESQL approach requires. + </p> + <p> + On the other hand, it is more or less impossible to react to operation + failures. This is due to the fact that the pipeline is already assembled + and the necessary logic to handle such failures is not + available inside the SQL transformer, unless of course, you are willing + to write a custom transformer. + Thus, the transformer approach is best for retrieving data. Creating + an XML representation of the query result is even simpler than when + using the ESQL logicsheet. The transformer also supports stored procedures. + No programming is required, apart from writing SQL. + </p> + <p> + For more detailed information, read: <link + href="../transformers/sql-transformer.html">SQL Transformer</link>. + </p> + </s1> </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/concepts/errorhandling.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/concepts/errorhandling.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/errorhandling.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/errorhandling.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/concepts/errorhandling.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/concepts/errorhandling.xml Wed Dec 29 22:55:55 2004 @@ -16,271 +16,271 @@ --> <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Error Handling</title> - <authors> - <person name="Björn Lütkemeier" email="[EMAIL PROTECTED]"/> - </authors> - </header> - <body> - <s1 title="Error Handling"> - <p> - During the execution of a Cocoon pipeline exceptions may occur within the involved components like generators, transformers etc. There are two possibilities to deal with them: The one would be not to handle them explicitly in the sitemap, which causes them to be logged and a default Cocoon error page to be displayed in the browser. The second is to define an error handling by using the sitemap tag <map:handle-errors>. Therein you are able to define any pipeline, that is executed in case of an exception occurred and displays an appropriate page. - </p> - <s2 title="ExceptionSelector"> - <p> - The ExceptionSelector allows to realize conditional error handling within <map:handle-errors>-tags depending on the type of the occurred exception. Each exception is configured centrally at the selector in the sitemap by associating a symbolic name to its class. - </p> - <p> - Furthermore it is possible to define, what exceptions are to be "unrolled". This means, that if an exception has been rethrown embedded in another exception, this original exception can be considered for choosing the correct error handling. - </p> - <p> - Example: - </p> - <source> - <![CDATA[ + <header> + <title>Error Handling</title> + <authors> + <person name="Björn Lütkemeier" email="[EMAIL PROTECTED]"/> + </authors> + </header> + <body> + <s1 title="Error Handling"> + <p> + During the execution of a Cocoon pipeline exceptions may occur within the involved components like generators, transformers etc. There are two possibilities to deal with them: The one would be not to handle them explicitly in the sitemap, which causes them to be logged and a default Cocoon error page to be displayed in the browser. The second is to define an error handling by using the sitemap tag <map:handle-errors>. Therein you are able to define any pipeline, that is executed in case of an exception occurred and displays an appropriate page. + </p> + <s2 title="ExceptionSelector"> + <p> + The ExceptionSelector allows to realize conditional error handling within <map:handle-errors>-tags depending on the type of the occurred exception. Each exception is configured centrally at the selector in the sitemap by associating a symbolic name to its class. + </p> + <p> + Furthermore it is possible to define, what exceptions are to be "unrolled". This means, that if an exception has been rethrown embedded in another exception, this original exception can be considered for choosing the correct error handling. + </p> + <p> + Example: + </p> + <source> + <![CDATA[ <map:selector name="exception" src="org.apache.cocoon.selection.ExceptionSelector"> - <exception name="processing" class="ProcessingException" unroll="true"/> - <exception name="sax" class="SAXException"/> - <exception name="application" class="ApplicationException"/> + <exception name="processing" class="ProcessingException" unroll="true"/> + <exception name="sax" class="SAXException"/> + <exception name="application" class="ApplicationException"/> </map:selector> ... <map:pipeline> - <map:match pattern="resource"> - ... - </map:match> - <map:handle-errors> - <map:select type="exception"> - <map:when test="processing">...</map:when> - <map:when test="sax">...</map:when> - <map:when test="application">...</map:when> - </map:select> - </map:handle-errors> + <map:match pattern="resource"> + ... + </map:match> + <map:handle-errors> + <map:select type="exception"> + <map:when test="processing">...</map:when> + <map:when test="sax">...</map:when> + <map:when test="application">...</map:when> + </map:select> + </map:handle-errors> </map:pipeline> - ]]> - </source> - <p> - Let's consider the following nested exceptions to occur: - </p> - <ol> - <li> - ProcessingException ( ApplicationException ): The ProcessingException is unrolled, so the error pipeline for "application" will be executed. - </li> - <li> - ProcessingException ( ValidationException ): Since ValidationException is not configured at all and therefore unknown, the ProcessingException is not unrolled even if unrolling is enabled. Therefore the pipeline for "processing" will be executed. - </li> - <li> - SAXException ( ApplicationException ): The unrolling is not enabled for SAXException, so the pipeline for "sax" will be executed. - </li> - </ol> - <p> - Please notice that the selector configuration is processed from top to bottom and stops at the first matching exception. Therefore the most specific classes must be configured first. This behaviour is the same as with Java catch statements. - </p> - </s2> - <s2 title="XPathExceptionSelector"> - <p> - The XPathExceptionSelector is an extension to the standard selector described above. It adds the possibility to configure additional conditions for each exception type by using JXPath expressions, that operate on the exception object. This configuration is also done centrally at the selector in the sitemap, where symbolic names are defined for all specific error situations. - </p> - <p> - Example: - </p> - <source> - <![CDATA[ + ]]> + </source> + <p> + Let's consider the following nested exceptions to occur: + </p> + <ol> + <li> + ProcessingException ( ApplicationException ): The ProcessingException is unrolled, so the error pipeline for "application" will be executed. + </li> + <li> + ProcessingException ( ValidationException ): Since ValidationException is not configured at all and therefore unknown, the ProcessingException is not unrolled even if unrolling is enabled. Therefore the pipeline for "processing" will be executed. + </li> + <li> + SAXException ( ApplicationException ): The unrolling is not enabled for SAXException, so the pipeline for "sax" will be executed. + </li> + </ol> + <p> + Please notice that the selector configuration is processed from top to bottom and stops at the first matching exception. Therefore the most specific classes must be configured first. This behaviour is the same as with Java catch statements. + </p> + </s2> + <s2 title="XPathExceptionSelector"> + <p> + The XPathExceptionSelector is an extension to the standard selector described above. It adds the possibility to configure additional conditions for each exception type by using JXPath expressions, that operate on the exception object. This configuration is also done centrally at the selector in the sitemap, where symbolic names are defined for all specific error situations. + </p> + <p> + Example: + </p> + <source> + <![CDATA[ <map:selector name="exception" src="org.apache.cocoon.selection.XPathExceptionSelector"> - <exception name="Denied" class="AuthenticationFailure"> - <xpath name="PasswordWrong" test="authCode=10"/> - <xpath name="PasswordExpired" test="errorCode=11"/> - <xpath name="AccessForbidden" test="errorCode>11"/> - </exception> + <exception name="Denied" class="AuthenticationFailure"> + <xpath name="PasswordWrong" test="authCode=10"/> + <xpath name="PasswordExpired" test="errorCode=11"/> + <xpath name="AccessForbidden" test="errorCode>11"/> + </exception> </map:selector> ... <map:pipeline> - <map:match pattern="login"> - ... - </map:match> - <map:handle-errors> - <map:select type="exception"> - <map:when test="PasswordWrong">...</map:when> - <map:when test="PasswordExpired">...</map:when> - <map:when test="AccessForbidden">...</map:when> - <map:when test="Denied">...</map:when> - <map:otherwise>...</map:otherwise> - </map:select> - </map:handle-errors> + <map:match pattern="login"> + ... + </map:match> + <map:handle-errors> + <map:select type="exception"> + <map:when test="PasswordWrong">...</map:when> + <map:when test="PasswordExpired">...</map:when> + <map:when test="AccessForbidden">...</map:when> + <map:when test="Denied">...</map:when> + <map:otherwise>...</map:otherwise> + </map:select> + </map:handle-errors> </map:pipeline> - ]]> - </source> - <p> - In this example the exception AuthenticationFailure is configured under name "Denied". Additionally three further conditions "PasswordWrong", "PasswordExpired" and "AccessForbidden" are defined by using JXPath expressions. Therefore instances of AuthenticationFailure are expected to have methods getAuthCode() and getErrorCode(). Now the error handler defined for resource "login" has five branches: If situation "PasswordWrong" occurs, which means that an AuthenticationFailure exception with auth code 10 has been thrown, the first error pipeline is executed. If the error code equals to 11 the second pipeline is executed, if it is greater that 11 the third one and all other AuthenticationFailure errors are handled by the fourth one. In any other error situation the fifth branch would be chosen. - </p> - <p> - Please notice that the selector stops when it finds the first JXPath expression in the configuration that matches: - </p> - <p> - Example: - </p> - <source> - <![CDATA[ - <map:selector name="exception" src="org.apache.cocoon.selection.XPathExceptionSelector"> - <exception name="application" class="ApplicationException"> - <xpath name="error3" test="errorCode>3"/> - <xpath name="error6" test="errorCode>6"/> - </exception> - </map:selector> - ... - <map:pipeline> - <map:match pattern="processForm"> - ... - </map:match> - <map:handle-errors> - <map:select type="exception"> - <map:when test="error6">...</map:when> <!-- handler 1 --> - <map:when test="error3">...</map:when> <!-- handler 2 --> - </map:select> - </map:handle-errors> - </map:pipeline> - ]]> - </source> - <p> - If an ApplicationException with error code 9 occurs, handler 2 is executed since error situation "error3" is configured before "error6" at the selector even if the expression for "error6" also evaluates to "true". - </p> - </s2> - <s2 title="Error Handler Hierarchy"> - <p> - The tag <map:handle-errors> may be attached to any <map:pipeline> or the <map:pipelines> tag of the root sitemap or a subsitemap. Therefore it is possible to define two kinds of error handlers: A default handler may be defined within <map:pipelines> for applying to all resources of a sitemap. Alternatively individual handlers may be configured for sets of resources within <map:pipeline>. - </p> - <p> - Example: - </p> - <source> - <![CDATA[ + ]]> + </source> + <p> + In this example the exception AuthenticationFailure is configured under name "Denied". Additionally three further conditions "PasswordWrong", "PasswordExpired" and "AccessForbidden" are defined by using JXPath expressions. Therefore instances of AuthenticationFailure are expected to have methods getAuthCode() and getErrorCode(). Now the error handler defined for resource "login" has five branches: If situation "PasswordWrong" occurs, which means that an AuthenticationFailure exception with auth code 10 has been thrown, the first error pipeline is executed. If the error code equals to 11 the second pipeline is executed, if it is greater that 11 the third one and all other AuthenticationFailure errors are handled by the fourth one. In any other error situation the fifth branch would be chosen. + </p> + <p> + Please notice that the selector stops when it finds the first JXPath expression in the configuration that matches: + </p> + <p> + Example: + </p> + <source> + <![CDATA[ + <map:selector name="exception" src="org.apache.cocoon.selection.XPathExceptionSelector"> + <exception name="application" class="ApplicationException"> + <xpath name="error3" test="errorCode>3"/> + <xpath name="error6" test="errorCode>6"/> + </exception> + </map:selector> + ... + <map:pipeline> + <map:match pattern="processForm"> + ... + </map:match> + <map:handle-errors> + <map:select type="exception"> + <map:when test="error6">...</map:when> <!-- handler 1 --> + <map:when test="error3">...</map:when> <!-- handler 2 --> + </map:select> + </map:handle-errors> + </map:pipeline> + ]]> + </source> + <p> + If an ApplicationException with error code 9 occurs, handler 2 is executed since error situation "error3" is configured before "error6" at the selector even if the expression for "error6" also evaluates to "true". + </p> + </s2> + <s2 title="Error Handler Hierarchy"> + <p> + The tag <map:handle-errors> may be attached to any <map:pipeline> or the <map:pipelines> tag of the root sitemap or a subsitemap. Therefore it is possible to define two kinds of error handlers: A default handler may be defined within <map:pipelines> for applying to all resources of a sitemap. Alternatively individual handlers may be configured for sets of resources within <map:pipeline>. + </p> + <p> + Example: + </p> + <source> + <![CDATA[ <map:pipelines> - <map:pipeline name="pipe1"> - <map:match pattern="res1"> - ... - </map:match> - <map:handle-errors> - <!-- this is an individual handler for pipe1 --> - </map:handle-errors> - </map:pipeline> - <map:pipeline name="pipe2"> - <map:match pattern="res2"> - ... - </map:match> - </map:pipeline> - <map:pipeline name="pipe3"> - <map:match pattern="res3"> - ... - </map:match> - </map:pipeline> - <map:handle-errors> - <!-- this is the default handler for the whole sitemap --> - </map:handle-errors> + <map:pipeline name="pipe1"> + <map:match pattern="res1"> + ... + </map:match> + <map:handle-errors> + <!-- this is an individual handler for pipe1 --> + </map:handle-errors> + </map:pipeline> + <map:pipeline name="pipe2"> + <map:match pattern="res2"> + ... + </map:match> + </map:pipeline> + <map:pipeline name="pipe3"> + <map:match pattern="res3"> + ... + </map:match> + </map:pipeline> + <map:handle-errors> + <!-- this is the default handler for the whole sitemap --> + </map:handle-errors> </map:pipelines> - ]]> - </source> - <p> - In conjunction with the ExceptionSelector resp. the XPathExceptionSelector it is possible to define a hierarchy of error handlers for an application. The behaviour then is the following: If an error occurs within a pipeline, Cocoon at first checks if an individual handler for this pipeline is defined. If so and it is able to handle the error due to its selection the processing terminates. Otherwise Cocoon looks for a default handler of the current sitemap. If one is found it is called. Now there is the same behaviour as above: If it can handle the exception the processing terminates otherwise the searching proceeds within the pipeline where the subsitemap is mounted. This goes on until the default handler of the root sitemap has been considered. If an error could not be handled at all, it is processed by the Cocoon engine in the end. - </p> - <p> - Please notice that a <map:otherwise> breaks the hierarchy since all errors will be handled on this level. Therefore all levels above will be called never. - </p> - <p> - Example: - </p> - <source> - <![CDATA[ + ]]> + </source> + <p> + In conjunction with the ExceptionSelector resp. the XPathExceptionSelector it is possible to define a hierarchy of error handlers for an application. The behaviour then is the following: If an error occurs within a pipeline, Cocoon at first checks if an individual handler for this pipeline is defined. If so and it is able to handle the error due to its selection the processing terminates. Otherwise Cocoon looks for a default handler of the current sitemap. If one is found it is called. Now there is the same behaviour as above: If it can handle the exception the processing terminates otherwise the searching proceeds within the pipeline where the subsitemap is mounted. This goes on until the default handler of the root sitemap has been considered. If an error could not be handled at all, it is processed by the Cocoon engine in the end. + </p> + <p> + Please notice that a <map:otherwise> breaks the hierarchy since all errors will be handled on this level. Therefore all levels above will be called never. + </p> + <p> + Example: + </p> + <source> + <![CDATA[ Root sitemap: <map:pipelines> - <map:pipeline> - <map:mount uri-prefix="sub" src="sub/"/> - <map:handle-errors> - <map:select type="exception"> - <map:when test="resourceNotFound">...</map:when> - </map:select> - </map:handle-errors> - </map:pipeline> - <map:handle-errors> - <map:generate src="generalerror.htm"/> - <map:serialize/> - </map:handle-errors> + <map:pipeline> + <map:mount uri-prefix="sub" src="sub/"/> + <map:handle-errors> + <map:select type="exception"> + <map:when test="resourceNotFound">...</map:when> + </map:select> + </map:handle-errors> + </map:pipeline> + <map:handle-errors> + <map:generate src="generalerror.htm"/> + <map:serialize/> + </map:handle-errors> </map:pipelines> Subsitemap: <map:pipelines> - <map:pipeline> - <map:match pattern="processForm"> - ... - </map:match> - <map:handle-errors> - <map:select type="exception"> - <map:when test="validation">...</map:when> - </map:select> - </map:handle-errors> - </map:pipeline> - <map:handle-errors> - <map:select type="exception"> - <map:when test="application">...</map:when> - </map:select> - </map:handle-errors> + <map:pipeline> + <map:match pattern="processForm"> + ... + </map:match> + <map:handle-errors> + <map:select type="exception"> + <map:when test="validation">...</map:when> + </map:select> + </map:handle-errors> + </map:pipeline> + <map:handle-errors> + <map:select type="exception"> + <map:when test="application">...</map:when> + </map:select> + </map:handle-errors> </map:pipelines> - ]]> - </source> - <p> - Let's consider four situations concerning the above example: - </p> - <ol> - <li> - A ValidationException occurs, because for instance the user entered an invalid value: The defined pipeline's handler is called. Since it has a matching <map:when>-section it is able to handle such an exception and therefore the processing is finished. - </li> - <li> - An ApplicationException occurs, because for instance a database connection has failed: The pipeline's handler is not able to handle the exception, so next the subsitemap's default handler is called. It has a matching <map:when>-section and is therefore able to handle the exception. - </li> - <li> - A ResourceNotFoundException occurs, because for instance some file is missing. Both the pipeline's and the subsitemaps' handlers are not able to handle it. Now Cocoon proceeds after the mount point of the subsitemap and finds its pipeline's handler next. It is able to handle a ResourceNotFoundException and therefore produces the output in this case. - </li> - <li> - A NullPointerException occurs, because something went completely wrong in the application: All handlers are not configured for such an exception and so the root sitemaps default handler will apply to it showing a general error page. - </li> - </ol> - <p> - When handling exceptions in error handlers one has to take care about recursion when working with redirects. Consider the following sitemap: - </p> - <p> - Example: - </p> - <source> - <![CDATA[ + ]]> + </source> + <p> + Let's consider four situations concerning the above example: + </p> + <ol> + <li> + A ValidationException occurs, because for instance the user entered an invalid value: The defined pipeline's handler is called. Since it has a matching <map:when>-section it is able to handle such an exception and therefore the processing is finished. + </li> + <li> + An ApplicationException occurs, because for instance a database connection has failed: The pipeline's handler is not able to handle the exception, so next the subsitemap's default handler is called. It has a matching <map:when>-section and is therefore able to handle the exception. + </li> + <li> + A ResourceNotFoundException occurs, because for instance some file is missing. Both the pipeline's and the subsitemaps' handlers are not able to handle it. Now Cocoon proceeds after the mount point of the subsitemap and finds its pipeline's handler next. It is able to handle a ResourceNotFoundException and therefore produces the output in this case. + </li> + <li> + A NullPointerException occurs, because something went completely wrong in the application: All handlers are not configured for such an exception and so the root sitemaps default handler will apply to it showing a general error page. + </li> + </ol> + <p> + When handling exceptions in error handlers one has to take care about recursion when working with redirects. Consider the following sitemap: + </p> + <p> + Example: + </p> + <source> + <![CDATA[ <map:pipelines> - <map:pipeline> - <map:match pattern="resource"> - ... - <map:transformer type="foo"/> - ... - </map:match> - <map:match pattern="error"> - ... - <map:transformer type="foo"/> - ... - </map:match> - <map:handle-errors> - <map:select type="exception"> - <map:when test="connection"> - <map:act type="redirect" src="cocoon:/error"/> - </map:when> - </map:select> - </map:handle-errors> - </map:pipeline> + <map:pipeline> + <map:match pattern="resource"> + ... + <map:transformer type="foo"/> + ... + </map:match> + <map:match pattern="error"> + ... + <map:transformer type="foo"/> + ... + </map:match> + <map:handle-errors> + <map:select type="exception"> + <map:when test="connection"> + <map:act type="redirect" src="cocoon:/error"/> + </map:when> + </map:select> + </map:handle-errors> + </map:pipeline> </map:pipelines> - ]]> - </source> - <p> - This configuration may lead to an infinite loop: Imagine to call "resource" where the FooTransformer throws a ConnectionException, because the connection to a backend system has broken. The defined error handler will handle it and the used action internally redirects to resource "error". This resource itself uses the FooTransformer to get some data from the backend, which of cause also causes a ConnectionException. This is handled by the error handler, which redirects to resource "error" and so on. Such an infinite loop may also occur when using several "nested" redirects, i.e. the error handler redirects to a resource, which redirects to another resource, which might produce the original exception. - </p> - <p> - When defining error handlers for an application such situation must be avoided. An easy rule would be: An error handling routine must never redirect to a resource for which the routine itself is responsible and which might produce the same error as just handled. - </p> - </s2> - </s1> - </body> + ]]> + </source> + <p> + This configuration may lead to an infinite loop: Imagine to call "resource" where the FooTransformer throws a ConnectionException, because the connection to a backend system has broken. The defined error handler will handle it and the used action internally redirects to resource "error". This resource itself uses the FooTransformer to get some data from the backend, which of cause also causes a ConnectionException. This is handled by the error handler, which redirects to resource "error" and so on. Such an infinite loop may also occur when using several "nested" redirects, i.e. the error handler redirects to a resource, which redirects to another resource, which might produce the original exception. + </p> + <p> + When defining error handlers for an application such situation must be avoided. An easy rule would be: An error handling routine must never redirect to a resource for which the routine itself is responsible and which might produce the same error as just handled. + </p> + </s2> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/concepts/modules.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/concepts/modules.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/modules.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/modules.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/concepts/modules.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/concepts/modules.xml Wed Dec 29 22:55:55 2004 @@ -194,11 +194,11 @@ The following example demonstrates the use of XPath function with <code>system-property</code> module. </p> - <source> + <source> <![CDATA[ <map:parameter name="users-home-base" value="{system-property:substring-before(user.home, user.name)}"/>]]> - </source> + </source> </s3> <s3 title="Step 2b: Use it on an XSP"> <p> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/concepts/mrustore.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/concepts/mrustore.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/mrustore.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/mrustore.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/concepts/mrustore.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/concepts/mrustore.xml Wed Dec 29 22:55:55 2004 @@ -89,7 +89,7 @@ if the MRUMemoryStore has reached its maximum object limit, or the JVM memory consumption is over the heap size limit. See StoreJanitor user docs for more information.</li> - </ol> + </ol> </s1> </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/concepts/sitemap.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/concepts/sitemap.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/sitemap.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/sitemap.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/concepts/sitemap.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/concepts/sitemap.xml Wed Dec 29 22:55:55 2004 @@ -725,11 +725,11 @@ </map:resource> <map:resource name="transform-data2svg" > - <map:transform src="xsl/data2svg.xsl" /> + <map:transform src="xsl/data2svg.xsl" /> </map:resource> <map:resource name="transform-data2html" > - <map:transform src="xsl/data2html.xsl" /> + <map:transform src="xsl/data2html.xsl" /> </map:resource> <map:resource name="pipe-data-raw"> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/concepts/xmlsearching.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/concepts/xmlsearching.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/xmlsearching.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/concepts/xmlsearching.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/concepts/xmlsearching.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/concepts/xmlsearching.xml Wed Dec 29 22:55:55 2004 @@ -201,14 +201,14 @@ in the <code>cocoon.xconf</code> file. </p> <s2 title="example"> - <p>This would set up the crawler to crawl all of your site, except pages in the 'search' section, also we are telling the crawler to use a non-standard cocoon-view for getting the links in documents, called <code>my-search-links</code>. </p> + <p>This would set up the crawler to crawl all of your site, except pages in the 'search' section, also we are telling the crawler to use a non-standard cocoon-view for getting the links in documents, called <code>my-search-links</code>. </p> <source><![CDATA[ <cocoon-crawler logger="core.search.crawler"> <exclude>.*/search/.*</exclude> <link-view-query>cocoon-view=my-search-links</link-view-query> </cocoon-crawler> ]]></source> - <p>This tells the indexer to use the non-standard 'my-search-content' view to retrieve the content for indexing. Also it tells the indexer that we would like to have any <code>title</code> or <code>subtitle</code> XML elements in the document added to the index as stored fields, so they can be retrieved and displayed to the user with any hits they get.</p> + <p>This tells the indexer to use the non-standard 'my-search-content' view to retrieve the content for indexing. Also it tells the indexer that we would like to have any <code>title</code> or <code>subtitle</code> XML elements in the document added to the index as stored fields, so they can be retrieved and displayed to the user with any hits they get.</p> <source><![CDATA[ <lucene-xml-indexer logger="core.search.lucene"> <store-fields>title, subtitle</store-fields> @@ -221,15 +221,15 @@ <code>sitemap.xmap</code> file. </p> <s2 title="example"> - <p>This would generate a document from a search, getting the query and other information from request parameters.</p> + <p>This would generate a document from a search, getting the query and other information from request parameters.</p> <source><![CDATA[ <map:generate type="search"/> ]]></source> - <p>This would generate a document from a search, getting the query from the sitemap parameter '1' and other information from request parameters.</p> + <p>This would generate a document from a search, getting the query from the sitemap parameter '1' and other information from request parameters.</p> <source><![CDATA[ <map:generate type="search"> <map:parameter name="query" value="{1}"/> -</map:generate> +</map:generate> ]]></source> </s2> </s1> @@ -296,26 +296,26 @@ <s1 title="Extending the Sample"> <p> It is easy to extend the search sample to display more information about the search hit than just the url of the resource.</p> - <p>In order to show, for example, the title and summary of a document, these first need to be added to the search index as 'Stored Fields'. Then when the documents are found during a search, that information is available to display, from the search engine itself.</p> + <p>In order to show, for example, the title and summary of a document, these first need to be added to the search index as 'Stored Fields'. Then when the documents are found during a search, that information is available to display, from the search engine itself.</p> <p>First, decide which fields you want to store.</p> <p>Decide where is the best place in your pipeline for content to be extracted for indexing, it might not always be the default view 'content'.</p> <p>Next, decide if you need an XSLT transformation on your documents, to make them more suitable for indexing. This may include deciding on one of several titles in your document, what part of your document gets added to the summary etc. You might want to strip certain tags out because you don't want their content searched. You might be able to raise hit scores on documents by re-arranging content, or keeping larger amounts of content in fewer tags.</p> - <p>Now you tell the search engine (in cocoon.xconf) which tags you'd like storing.</p> + <p>Now you tell the search engine (in cocoon.xconf) which tags you'd like storing.</p> <source><![CDATA[ <lucene-xml-indexer logger="core.search.lucene"> <store-fields>title, summary</store-fields> <content-view-query>cocoon-view=search-content</content-view-query> </lucene-xml-indexer> ]]></source> - <p>This example tells the indexer to store any tags called 'title' or 'summary' it finds in your documents. It also tells the indexer to get it's content from the view called 'search-content'.</p> + <p>This example tells the indexer to store any tags called 'title' or 'summary' it finds in your documents. It also tells the indexer to get it's content from the view called 'search-content'.</p> <source><![CDATA[ <map:view from-label="search" name="search"> <map:transform src="search-filter.xsl"/> <map:serialize type="xml"/> </map:view> ]]></source> - <p>This is how you might setup that custom view in your sitemap. You would then add a label attribute <code>label="search"</code> to the appropriate place in your pipelines. See the section on views for more information.</p> - <p>After you have re-indexed the site, when you do searches, the new fields will be available in the XML output by Lucene, in the form of a <code>search:field</code> tag, you will need to modify your XSLT that displays the hits to show this.</p> + <p>This is how you might setup that custom view in your sitemap. You would then add a label attribute <code>label="search"</code> to the appropriate place in your pipelines. See the section on views for more information.</p> + <p>After you have re-indexed the site, when you do searches, the new fields will be available in the XML output by Lucene, in the form of a <code>search:field</code> tag, you will need to modify your XSLT that displays the hits to show this.</p> <source><![CDATA[ <xsl:template match="search:hit"> <tr> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/flow/api.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/flow/api.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/flow/api.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/flow/api.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/flow/api.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/flow/api.xml Wed Dec 29 22:55:55 2004 @@ -27,7 +27,7 @@ <body> <s1 title="Flowscript"> - <p>Cocoon Flowscript is a JavaScript API to manage control flow based on an + <p>Cocoon Flowscript is a JavaScript API to manage control flow based on an <link href="http://cvs.cocoondev.org/cgi-bin/viewcvs.cgi/?cvsroot=rhino";>extended</link> version of the <link href="http://www.mozilla.org/rhino";>Mozilla Rhino</link> JavaScript interpreter that supports continuations.</p> </s1> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/flow/continuations.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/flow/continuations.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/flow/continuations.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/flow/continuations.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/flow/continuations.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/flow/continuations.xml Wed Dec 29 22:55:55 2004 @@ -107,20 +107,20 @@ <s2 title="What are continuations?"> - <p>A continuation is exactly the type of object that we need. - Think of a continuation as an object that, for a given point - in your program, contains a snapshot of the stack trace, - including all the local variables, and the program - counter. You can not only store these things in the - continuation object, but also restore the execution of the - program from a continuation object. This means that the stack - trace and the program counter of the running program become - the ones stored in a continuation.</p> + <p>A continuation is exactly the type of object that we need. + Think of a continuation as an object that, for a given point + in your program, contains a snapshot of the stack trace, + including all the local variables, and the program + counter. You can not only store these things in the + continuation object, but also restore the execution of the + program from a continuation object. This means that the stack + trace and the program counter of the running program become + the ones stored in a continuation.</p> - <p>Continuations are powerful concepts from the world of - functional languages, like <link - href="http://www.schemers.org/";>Scheme</link>, but they are - becoming popular in other languages as well.</p> + <p>Continuations are powerful concepts from the world of + functional languages, like <link + href="http://www.schemers.org/";>Scheme</link>, but they are + becoming popular in other languages as well.</p> </s2> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/flow/how-does-it-work.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/flow/how-does-it-work.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/flow/how-does-it-work.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/flow/how-does-it-work.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/flow/how-does-it-work.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/flow/how-does-it-work.xml Wed Dec 29 22:55:55 2004 @@ -26,30 +26,30 @@ <body> <s1 title="Cocoon and continuations"> - <p>With continuations in the language, you can essentially - store the continuation of <code>sendPageAndWait()</code> (think of all - the stack trace, and the program counter), put it in a global - hash table associated with an id. The id is then encoded in - the <code>response.xml</code> page as an URL. When the user - clicks on that URL, on the server side the associated - continuation is resumed. Resuming the processing happens as if - nothing was stopped, you get all the stack trace back, and all - the local variables.</p> + <p>With continuations in the language, you can essentially + store the continuation of <code>sendPageAndWait()</code> (think of all + the stack trace, and the program counter), put it in a global + hash table associated with an id. The id is then encoded in + the <code>response.xml</code> page as an URL. When the user + clicks on that URL, on the server side the associated + continuation is resumed. Resuming the processing happens as if + nothing was stopped, you get all the stack trace back, and all + the local variables.</p> - <p>So instead of using beans to store things in session, you - use normal variables in a program. Since each user has its own - version of the program, all the local variables in the program - are separate between users.</p> + <p>So instead of using beans to store things in session, you + use normal variables in a program. Since each user has its own + version of the program, all the local variables in the program + are separate between users.</p> - <p>With this approach clicking the <em>Back</em> button in the - browser is no longer a hassle to deal with for you as a - server-side programmer. They will simply refer to past - continuations objects, which have their own state of the local - variables.</p> + <p>With this approach clicking the <em>Back</em> button in the + browser is no longer a hassle to deal with for you as a + server-side programmer. They will simply refer to past + continuations objects, which have their own state of the local + variables.</p> - <p>Since continuations are objects, you can also store them in - a database, for really long-lived session, just like you do - with session beans.</p> + <p>Since continuations are objects, you can also store them in + a database, for really long-lived session, just like you do + with session beans.</p> </s1> </body> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/flow/jxtemplate.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/flow/jxtemplate.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/flow/jxtemplate.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/flow/jxtemplate.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/flow/jxtemplate.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/flow/jxtemplate.xml Wed Dec 29 22:55:55 2004 @@ -17,14 +17,14 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Advanced Control Flow</title> - <authors> - <person name="Christopher Oliver" email="[EMAIL PROTECTED]" /> - </authors> - </header> + <header> + <title>Advanced Control Flow</title> + <authors> + <person name="Christopher Oliver" email="[EMAIL PROTECTED]" /> + </authors> + </header> <body> - <s1 title="JXTemplate Generator"> + <s1 title="JXTemplate Generator"> <p> The JXTemplate Generator is a page template processor that allows you to inject data from Java and JavaScript objects passed by a Cocoon Flowscript into a Cocoon pipeline. It provides a set of tags (similar to the <link href="http://java.sun.com/products/jsp/jstl/";>JSTL</link> core tags) that allow you to iterate over Java collections (and Java or JavaScript arrays) and to test for the presence of optional or alternate bean properties, as well as embedded expressions to specify conditions and to access the properties of objects. The <em>JX</em>Template Generator gets its name from the embedded expression languages it supports, namely <link href="http://jakarta.apache.org/commons/jxpath";>Apache <em>JX</em>Path</link> and <link href="http://jakarta.apache.org/commons/jexl";>Apache <em>J</em>e<em>X</em>l</link>. </p> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_repeater_action.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_repeater_action.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_repeater_action.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_repeater_action.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_repeater_action.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_repeater_action.xml Wed Dec 29 22:55:55 2004 @@ -60,9 +60,9 @@ to be defined, see also <link href="eventhandling.html">Event Handling</link>. The interface to be implemented for Java event listeners is <code>org.apache.cocoon.forms.event.ActionListener</code>. The WidgetEvent subclass is <code>org.apache.cocoon.forms.event.ActionEvent</code>. - The event handlers are called <em>after</em> the action is performed except for the - <code>delete-rows</code> action where event handlers are called <em>before</em> the - selected rows are deleted.</p> + The event handlers are called <em>after</em> the action is performed except for the + <code>delete-rows</code> action where event handlers are called <em>before</em> the + selected rows are deleted.</p> </s1> </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_row_action.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_row_action.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_row_action.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_row_action.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_row_action.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/forms/widget_row_action.xml Wed Dec 29 22:55:55 2004 @@ -50,9 +50,9 @@ be defined, see also <link href="eventhandling.html">Event Handling</link>. The interface to be implemented for Java event listeners is <code>org.apache.cocoon.forms.event.ActionListener</code>. The WidgetEvent subclass is <code>org.apache.cocoon.forms.event.ActionEvent</code>. - The event handlers are called <em>after</em> the action is performed except for the - <code>delete</code> row action where event handlers are called <em>before</em> the - row is deleted.</p> + The event handlers are called <em>after</em> the action is performed except for the + <code>delete</code> row action where event handlers are called <em>before</em> the + row is deleted.</p> <p>Where all you want to do is submit a specific row on a repeater, simply add a fd:submit element to the widgets for the repeater.</p> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/generators/extractor-generator.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/generators/extractor-generator.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/generators/extractor-generator.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/generators/extractor-generator.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/generators/extractor-generator.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/generators/extractor-generator.xml Wed Dec 29 22:55:55 2004 @@ -17,32 +17,32 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Fragment Extractor Generator</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the fragment extractor generator of Cocoon</abstract> - </header> - <body> - <s1 title="Fragment Extractor Generator"> - <p> FragmentExtractor is a transformer-generator pair which is designed to allow + <header> + <title>Fragment Extractor Generator</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the fragment extractor generator of Cocoon</abstract> + </header> + <body> + <s1 title="Fragment Extractor Generator"> + <p> FragmentExtractor is a transformer-generator pair which is designed to allow sitemap managers to extract certain nodes from a SAX stream and move them into a separate pipeline. The main use for this is to extract inline SVG images and serve them up through a separate pipeline, usually serializing them to PNG or JPEG format first.</p> - <ul> - <li>Name : extractor</li> - <li>Class: org.apache.cocoon.generation.FragmentExtractorGenerator</li> - <li>Cacheable: no.</li> - </ul> + <ul> + <li>Name : extractor</li> + <li>Class: org.apache.cocoon.generation.FragmentExtractorGenerator</li> + <li>Cacheable: no.</li> + </ul> <source> <![CDATA[ <map:generate type="extractor"/> ]]> </source> - </s1> - </body> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/generators/file-generator.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/generators/file-generator.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/generators/file-generator.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/generators/file-generator.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/generators/file-generator.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/generators/file-generator.xml Wed Dec 29 22:55:55 2004 @@ -18,21 +18,21 @@ <document> <!-- This document will be enhanced by information taken from the javadoc --> - <header> - <title>File Generator</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the file generator of Cocoon.</abstract> - </header> - <body> - <s1 title="File Generator"> - <p>The file generator reads an xml document from the local file system or from any url. - While url generator may appear to be a more suitable name, it's known as the file generator for historical reasons.</p> - <p>The file generator is the default generator.</p> - <p>The location of the source xml document is specified in + <header> + <title>File Generator</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the file generator of Cocoon.</abstract> + </header> + <body> + <s1 title="File Generator"> + <p>The file generator reads an xml document from the local file system or from any url. + While url generator may appear to be a more suitable name, it's known as the file generator for historical reasons.</p> + <p>The file generator is the default generator.</p> + <p>The location of the source xml document is specified in the pipeline by the src attribute.</p> <source> <![CDATA[ @@ -50,6 +50,6 @@ that are not provided by Cocoon, and xml parsing errors. Use the "HTMLGenerator instead. </p> - </s1> - </body> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/generators/html-generator.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/generators/html-generator.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/generators/html-generator.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/generators/html-generator.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/generators/html-generator.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/generators/html-generator.xml Wed Dec 29 22:55:55 2004 @@ -17,32 +17,32 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>HTML Generator</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - <person name="Sylvain Wallez" email="[EMAIL PROTECTED]"/> - <person name="Gianugo Rabellino " email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the html generator of Cocoon.</abstract> - </header> - <body> - <s1 title="HTML Generator"> - <p>The html generator reads an html document from the local file system or from any url. - It acts similar to the file generator with the difference that it reads + <header> + <title>HTML Generator</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + <person name="Sylvain Wallez" email="[EMAIL PROTECTED]"/> + <person name="Gianugo Rabellino " email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the html generator of Cocoon.</abstract> + </header> + <body> + <s1 title="HTML Generator"> + <p>The html generator reads an html document from the local file system or from any url. + It acts similar to the file generator with the difference that it reads html documents and converts them using <link href="http://sourceforge.net/projects/jtidy";>JTidy</link> to xhtml.</p> - <p>This generator is optional and requires the jtidy package + <p>This generator is optional and requires the jtidy package in the lib directory when building Cocoon. However, the distribution includes this package already.</p> - <ul> - <li>Name : html</li> - <li>Class: org.apache.cocoon.generation.HTMLGenerator</li> - <li>Cacheable: yes - uses the last modification date of the html document for validation.</li> - </ul> - <p>The location of the source html document is specified in + <ul> + <li>Name : html</li> + <li>Class: org.apache.cocoon.generation.HTMLGenerator</li> + <li>Cacheable: yes - uses the last modification date of the html document for validation.</li> + </ul> + <p>The location of the source html document is specified in the pipeline by the src attribute.</p> <source> <![CDATA[ @@ -64,26 +64,26 @@ ]]> </source> - </s1> - <s1 title="Configuring JTidy"> - <p>Without any configuration, the generator produces an XHTML document, with the proper namespace. However, - JTidy offers a full range of options for converting the HTML document to XML.</p> - <p>These options can be specified in a properties file (key=value pairs) whose location is given in the - component configuration :</p> - <source> - <![CDATA[ + </s1> + <s1 title="Configuring JTidy"> + <p>Without any configuration, the generator produces an XHTML document, with the proper namespace. However, + JTidy offers a full range of options for converting the HTML document to XML.</p> + <p>These options can be specified in a properties file (key=value pairs) whose location is given in the + component configuration :</p> + <source> + <![CDATA[ <map:generator name="html" src="org.apache.cocoon.generation.HTMLGenerator"> <jtidy-config>jtidy.properties</jtidy-config> </map:generator> - ]]> - </source> - <p>The <code>jtidy-config</code> URL can be either relative (to the application context), one of Cocoon's special - protocols such as <code>resouce:</code> which searches the file in the classpath.</p> - <p>For more information on the available configurations, please refer to the - <link href="http://www.w3.org/People/Raggett/tidy/";>original Tidy page</link>. Beware that configuration - examples shown there use the ':' as a separator when JTidy requires a '=' as it is a standard Java properties file. - </p> - </s1> + ]]> + </source> + <p>The <code>jtidy-config</code> URL can be either relative (to the application context), one of Cocoon's special + protocols such as <code>resouce:</code> which searches the file in the classpath.</p> + <p>For more information on the available configurations, please refer to the + <link href="http://www.w3.org/People/Raggett/tidy/";>original Tidy page</link>. Beware that configuration + examples shown there use the ':' as a separator when JTidy requires a '=' as it is a standard Java properties file. + </p> + </s1> - </body> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/generators/imagedirectory-generator.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/generators/imagedirectory-generator.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/generators/imagedirectory-generator.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/generators/imagedirectory-generator.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/generators/imagedirectory-generator.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/generators/imagedirectory-generator.xml Wed Dec 29 22:55:55 2004 @@ -30,7 +30,7 @@ <body> <s1 title="Image Directory Generator"> <p>The Image Directory provides all the functionality of the - <link href="directory-generator.html">Directory Generator</link>. Additionally it + <link href="directory-generator.html">Directory Generator</link>. Additionally it ensures that the files are images and adds their dimensions (<code>width</code> and <code>height</code>) to the attributes. It is configured in the same way as the Directory Generator.</p> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/generators/jsp-generator.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/generators/jsp-generator.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/generators/jsp-generator.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/generators/jsp-generator.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/generators/jsp-generator.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/generators/jsp-generator.xml Wed Dec 29 22:55:55 2004 @@ -17,18 +17,18 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>JSP Generator</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the jsp generator of Cocoon.</abstract> - </header> - <body> - <s1 title="JSP Generator"> - <p>The JspGenerator selects a JSPEngine component. The JSPEngine component + <header> + <title>JSP Generator</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the jsp generator of Cocoon.</abstract> + </header> + <body> + <s1 title="JSP Generator"> + <p>The JspGenerator selects a JSPEngine component. The JSPEngine component launches a JSP servlet engine of your servlet container, feeds the HttpRequest into the JSP servlet engine, and pipes the jsp response as SAX events into Cocoon. @@ -40,15 +40,15 @@ You may specify your JSP pages either as JSP scriptlets or as JSP-XML. But keep in mind that your JSP output should be valid XML. </p> - <ul> - <li>Name : jsp</li> - <li>Class: org.apache.cocoon.generation.JspGenerator</li> - <li>Cacheable: no</li> - </ul> + <ul> + <li>Name : jsp</li> + <li>Class: org.apache.cocoon.generation.JspGenerator</li> + <li>Cacheable: no</li> + </ul> <source><![CDATA[ <map:generate type="jsp"/> ]]></source> - </s1> + </s1> <s1 title="JSPEngine"> <p>As JSP servlet engines are implemented differently, you may have to select the appropriate JSPEngine component. @@ -144,5 +144,5 @@ ]]></source> </s2> </s1> - </body> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/generators/request-generator.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/generators/request-generator.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/generators/request-generator.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/generators/request-generator.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/generators/request-generator.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/generators/request-generator.xml Wed Dec 29 22:55:55 2004 @@ -108,7 +108,7 @@ <!-- This will turn on attribute generation for this invocation only. --> <map:match pattern="request"> <map:generate type="request"> - <map:parameter name="generate-attributes" value="true"/> + <map:parameter name="generate-attributes" value="true"/> </map:generate> </map:match> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/generators/search-generator.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/generators/search-generator.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/generators/search-generator.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/generators/search-generator.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/generators/search-generator.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/generators/search-generator.xml Wed Dec 29 22:55:55 2004 @@ -48,7 +48,7 @@ <p>or</p> <source><![CDATA[ <map:generate type="search"> - <query>your query string</query> + <query>your query string</query> </map:generate> ]]></source> </s1> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/generators/serverpages-generator.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/generators/serverpages-generator.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/generators/serverpages-generator.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/generators/serverpages-generator.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/generators/serverpages-generator.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/generators/serverpages-generator.xml Wed Dec 29 22:55:55 2004 @@ -17,28 +17,28 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Server Pages Generator</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the server pages generator of Cocoon.</abstract> - </header> - <body> - <s1 title="Server Pages Generator"> - <p>????.</p> - <ul> - <li>Name : serverpages</li> - <li>Class: org.apache.cocoon.generation.ServerPagesGenerator</li> - <li>Cacheable: ????.</li> - </ul> + <header> + <title>Server Pages Generator</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the server pages generator of Cocoon.</abstract> + </header> + <body> + <s1 title="Server Pages Generator"> + <p>????.</p> + <ul> + <li>Name : serverpages</li> + <li>Class: org.apache.cocoon.generation.ServerPagesGenerator</li> + <li>Cacheable: ????.</li> + </ul> <source> <![CDATA[ <map:generate type="serverpages"/> ]]> </source> - </s1> - </body> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/generators/status-generator.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/generators/status-generator.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/generators/status-generator.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/generators/status-generator.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/generators/status-generator.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/generators/status-generator.xml Wed Dec 29 22:55:55 2004 @@ -18,39 +18,39 @@ <document> <!-- This document will be enhanced by information taken from the javadoc --> - <header> - <title>Status Generator</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the status generator of Cocoon.</abstract> - </header> - <body> - <s1 title="Status Generator"> - <p>The status generator creates xml from the current status of cocoon.</p> - <p>The information is surrounded by the root element <code>statusinfo</code> + <header> + <title>Status Generator</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the status generator of Cocoon.</abstract> + </header> + <body> + <s1 title="Status Generator"> + <p>The status generator creates xml from the current status of cocoon.</p> + <p>The information is surrounded by the root element <code>statusinfo</code> and grouped with the elements <code>group</code> and <code>value</code>.</p> - <p>The <code>statusinfo</code> element has the attributes <code>host</code> + <p>The <code>statusinfo</code> element has the attributes <code>host</code> and <code>date</code>.</p> <p>A group collects several informations about one topic. The topic is set by the attribute <code>name</code> of the group. A group can have subgroups (element <code>group</code>) or values.</p> <p>Each value has a name specified by the attribute <code>name</code> and can consist of one or several <code>line</code>.</p> - <p>All elements have the namespace <code>http://apache.org/cocoon/status/2.0</code>.</p> - <ul> - <li>Name : status</li> - <li>Class: org.apache.cocoon.generation.StatusGenerator</li> - <li>Cacheable: no.</li> - </ul> + <p>All elements have the namespace <code>http://apache.org/cocoon/status/2.0</code>.</p> + <ul> + <li>Name : status</li> + <li>Class: org.apache.cocoon.generation.StatusGenerator</li> + <li>Cacheable: no.</li> + </ul> <source> <![CDATA[ <map:generate type="status"/> ]]> </source> - </s1> + </s1> <s1 title="DTD"> <p>XML generated by status generator uses namespace <code>http://apache.org/cocoon/status/2.0</code>. The DTD of XML @@ -76,8 +76,8 @@ <!ELEMENT line (#PCDATA)+> ]]></source> </s1> - <s1 title="Example"> - <p>The current status generator outputs information about the jvm:</p> + <s1 title="Example"> + <p>The current status generator outputs information about the jvm:</p> <source> <![CDATA[ <?xml version="1.0" encoding="UTF-8"?> @@ -108,6 +108,6 @@ </group> </statusinfo> ]]> </source> - </s1> - </body> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/generators/stream-generator.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/generators/stream-generator.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/generators/stream-generator.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/generators/stream-generator.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/generators/stream-generator.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/generators/stream-generator.xml Wed Dec 29 22:55:55 2004 @@ -18,102 +18,102 @@ <document> <!-- This document will be enhanced by information taken from the javadoc --> - <header> - <title>Stream Generator</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Kinga Dziembowska" email="[EMAIL PROTECTED]"/> - <person name="Davanum Srinivas" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the stream generator of Cocoon.</abstract> - </header> - <body> - <s1 title="Stream Generator"> - <p> - The StreamGenerator is a class that reads XML from an HttpRequest - InputStream and generates SAX Events. StreamGenerator expects - XML data coming as HTTP request message. - </p> - <ul> - <li>Name : stream</li> - <li>Class: org.apache.cocoon.generation.StreamGenerator</li> - <li>Cacheable: no.</li> - </ul> - <p> - For POST requests with mimetype of application/x-www-form-urlencoded, - the xml data expects to be associated with the name specified - in the sitemap parameter. - </p> + <header> + <title>Stream Generator</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Kinga Dziembowska" email="[EMAIL PROTECTED]"/> + <person name="Davanum Srinivas" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the stream generator of Cocoon.</abstract> + </header> + <body> + <s1 title="Stream Generator"> + <p> + The StreamGenerator is a class that reads XML from an HttpRequest + InputStream and generates SAX Events. StreamGenerator expects + XML data coming as HTTP request message. + </p> + <ul> + <li>Name : stream</li> + <li>Class: org.apache.cocoon.generation.StreamGenerator</li> + <li>Cacheable: no.</li> + </ul> + <p> + For POST requests with mimetype of application/x-www-form-urlencoded, + the xml data expects to be associated with the name specified + in the sitemap parameter. + </p> - <p> - For HTTP requests with mimetypes: text/plain, text/xml, application/xml - the xml data is in the body of the HTTP request and its length is - specified by the value returned by getContentLength() method. - </p> - <s2 title="PostInputStream"> - <p> - The StreamGenerator uses helper class org.apache.cocoon.util.PostInputStream - for InputStream reading operations. At the time that Parser reads the data - out of InputStream - Parser has no knowledge about the length of data to be - read. The only way to signal to the Parser that all data was read from the - InputStream is to control reading operation - PostInputStream- and to - return to the requestor -1 when the number of bytes read is equal to the - getContentLength() value. - </p> - </s2> + <p> + For HTTP requests with mimetypes: text/plain, text/xml, application/xml + the xml data is in the body of the HTTP request and its length is + specified by the value returned by getContentLength() method. + </p> + <s2 title="PostInputStream"> + <p> + The StreamGenerator uses helper class org.apache.cocoon.util.PostInputStream + for InputStream reading operations. At the time that Parser reads the data + out of InputStream - Parser has no knowledge about the length of data to be + read. The only way to signal to the Parser that all data was read from the + InputStream is to control reading operation - PostInputStream- and to + return to the requestor -1 when the number of bytes read is equal to the + getContentLength() value. + </p> + </s2> - <s2 title="See it in Action"> - <p> - The Generator is a generic object, i.e. it can process any stream out of the - HTTP message. There are two ways to see StreamGenerator in action: - </p> + <s2 title="See it in Action"> + <p> + The Generator is a generic object, i.e. it can process any stream out of the + HTTP message. There are two ways to see StreamGenerator in action: + </p> - <ul> - <li>To invoke URL http://localhost:8080/cocoon/Order</li> - <li>To use telnet program to generate POST request</li> - </ul> + <ul> + <li>To invoke URL http://localhost:8080/cocoon/Order</li> + <li>To use telnet program to generate POST request</li> + </ul> - <p> - The first option is not a "pure" stream invocation, but it is quick way to - observe desired effects. The result of this invocation is a form containing - the XML document embedded in the textarea of the form. Submission of this - form will invoke StreamGenerator. The testarea name/value par is specified - as a parameter in the sitemap definition for the StreamGenerator. The expected - result is the submitted xml document send back to the browser. - </p> + <p> + The first option is not a "pure" stream invocation, but it is quick way to + observe desired effects. The result of this invocation is a form containing + the XML document embedded in the textarea of the form. Submission of this + form will invoke StreamGenerator. The testarea name/value par is specified + as a parameter in the sitemap definition for the StreamGenerator. The expected + result is the submitted xml document send back to the browser. + </p> - <p> - The second or "pure" option of testing StreamGenerator "in action," requires the - use of Telnet program or any other process able to generate correct HTTP message. - The procedure is: - </p> + <p> + The second or "pure" option of testing StreamGenerator "in action," requires the + use of Telnet program or any other process able to generate correct HTTP message. + The procedure is: + </p> - <ul> - <li>To invoke telnet, connect to localhost 8080 and to use content of - <link href="telnet.txt">telnet.txt</link> file as a post message. - </li> - <li>Here, the Copy-Paste method should be used.</li> - <li>Remember to hit the enter button twice enter after the contents of the post are set in telnet.</li> - </ul> + <ul> + <li>To invoke telnet, connect to localhost 8080 and to use content of + <link href="telnet.txt">telnet.txt</link> file as a post message. + </li> + <li>Here, the Copy-Paste method should be used.</li> + <li>Remember to hit the enter button twice enter after the contents of the post are set in telnet.</li> + </ul> - <p> - It is important because Content-len is calculated assuming two "enter" in the end of http message. - Once again, the performed task results in the mirror of the original document being sent back to the requestor. - </p> + <p> + It is important because Content-len is calculated assuming two "enter" in the end of http message. + Once again, the performed task results in the mirror of the original document being sent back to the requestor. + </p> - <p> - The "pure" stream generation can be observed using the telnet utility where you can invoke a - message targeting my processing. Any other method is good (URL object connection) as - long the message is well formed. - </p> + <p> + The "pure" stream generation can be observed using the telnet utility where you can invoke a + message targeting my processing. Any other method is good (URL object connection) as + long the message is well formed. + </p> <source> <![CDATA[ <map:generate type="stream"/> ]]> </source> <p> - If you want to process XML streams sent by clients that don't set the Content-Type HTTP header + If you want to process XML streams sent by clients that don't set the Content-Type HTTP header just use the defaultContentType parameter. </p> @@ -124,7 +124,7 @@ </map:generate> ]]> </source> - </s2> - </s1> - </body> + </s2> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldb-generator.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldb-generator.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldb-generator.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldb-generator.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldb-generator.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldb-generator.xml Wed Dec 29 22:55:55 2004 @@ -17,24 +17,24 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>XML:DB Generator</title> - <version>0.1</version> - <type>Technical document</type> - <authors> - <person name="Gianugo Rabellino" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the XML:DB generator of Cocoon.</abstract> - </header> - <body> - <s1 title="Warning!"> + <header> + <title>XML:DB Generator</title> + <version>0.1</version> + <type>Technical document</type> + <authors> + <person name="Gianugo Rabellino" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the XML:DB generator of Cocoon.</abstract> + </header> + <body> + <s1 title="Warning!"> <p> The XML:DB generators are currently unmaintained and going to be deprecated soon. Please use the XML:DB pseudo-protocol instead. </p> </s1> - <s1 title="XML:DB Generator"> - <p> + <s1 title="XML:DB Generator"> + <p> Generates XML documents out of an XML:DB compliant database. XML:DB is a generic API developed by the XML:DB group in order to allow access via a consistent API to the upcoming XML databases such as dbXML, @@ -69,5 +69,5 @@ end of the <code>base</code> tag. </p> </s1> - </body> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldbcollection-generator.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldbcollection-generator.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldbcollection-generator.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldbcollection-generator.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldbcollection-generator.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/generators/xmldbcollection-generator.xml Wed Dec 29 22:55:55 2004 @@ -17,25 +17,25 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>XML:DB Collection Generator</title> - <version>0.1</version> - <type>Technical document</type> - <authors> - <person name="Gianugo Rabellino" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the XML:DB + <header> + <title>XML:DB Collection Generator</title> + <version>0.1</version> + <type>Technical document</type> + <authors> + <person name="Gianugo Rabellino" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the XML:DB Collection generator of Cocoon.</abstract> - </header> - <body> - <s1 title="Warning!"> + </header> + <body> + <s1 title="Warning!"> <p> The XML:DB generators are currently unmaintained and going to be deprecated soon. Please use the XML:DB pseudo-protocol instead. </p> </s1> - <s1 title="XML:DB Collection Generator"> - <p> + <s1 title="XML:DB Collection Generator"> + <p> As for the filesystem there are two generators provided (a file generator and a directory generator), so is for XML:DB, which can roughly be tought as an XML filesystem, where Collections @@ -72,5 +72,5 @@ end of the <code>base</code> tag. </p> </s1> - </body> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/matchers/matchers.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/matchers/matchers.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/matchers/matchers.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/matchers/matchers.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/matchers/matchers.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/matchers/matchers.xml Wed Dec 29 22:55:55 2004 @@ -17,30 +17,30 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Matchers</title> - <subtitle>in Cocoon</subtitle> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - <person name="Gianugo Rabellino" email="[EMAIL PROTECTED]"/> - <person name="Diana Shannon, ed." email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes all of the available matchers of Cocoon.</abstract> - </header> - <body> - <s1 title="Goal"> - <p> + <header> + <title>Matchers</title> + <subtitle>in Cocoon</subtitle> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + <person name="Gianugo Rabellino" email="[EMAIL PROTECTED]"/> + <person name="Diana Shannon, ed." email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes all of the available matchers of Cocoon.</abstract> + </header> + <body> + <s1 title="Goal"> + <p> This document lists all of the available matchers of Apache Cocoon and describes their purpose. See also the concepts document <link href="../concepts/matchers_selectors.html">Using and Implementing Matchers and Selectors</link>. </p> - </s1> - <s1 title="Overview"> - <p> + </s1> + <s1 title="Overview"> + <p> A matcher is a core sitemap component of Cocoon. Matchers allow Cocoon to associate a pure "virtual" URI space with a given set of "instructions" @@ -88,7 +88,7 @@ requirement. For example, a URI request for "body-cocoon.xml" would match the second entry. </p> - </s1> + </s1> <s1 title="Order"> <p> It's important to understand that Cocoon is based on a "first-match" @@ -161,22 +161,22 @@ </li> </ul> </s1> - <s1 title="Matchers in Cocoon"> + <s1 title="Matchers in Cocoon"> <ul> - <li><strong>WildCard URI matcher</strong>(The default matcher): matches the URI against a wildcard pattern.</li> - <li><strong>Regexp URI matcher:</strong> + <li><strong>WildCard URI matcher</strong>(The default matcher): matches the URI against a wildcard pattern.</li> + <li><strong>Regexp URI matcher:</strong> matches the URI against a full-blown regular expression</li> - <li><strong>Request parameter + <li><strong>Request parameter matcher:</strong> matches a request parameters given as a pattern. If the parameter exists, its value is available for later substitution. </li> - <li><strong>Wildcard request parameter matcher:</strong> matches a wildcard + <li><strong>Wildcard request parameter matcher:</strong> matches a wildcard given as a pattern against the <strong>value</strong> of a configured parameter. </li> - <li><strong>Wildcard session parameter matcher</strong>: similar to the + <li><strong>Wildcard session parameter matcher</strong>: similar to the Wildcard request parameter matcher, but it matches a session parameter.</li> - </ul> - </s1> - </body> + </ul> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/matchers/template-matcher.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/matchers/template-matcher.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/matchers/template-matcher.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/matchers/template-matcher.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/matchers/template-matcher.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/matchers/template-matcher.xml Wed Dec 29 22:55:55 2004 @@ -17,7 +17,7 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <!-- - <![CDATA[ CVS Version: $Id: template-matcher.xml,v 1.6 2004/05/08 08:57:58 crossley Exp $ + <![CDATA[ CVS Version: $Id$ ]]> Using this TemplateMatcher: Modified: cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcardheader-matcher.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcardheader-matcher.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcardheader-matcher.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcardheader-matcher.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcardheader-matcher.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcardheader-matcher.xml Wed Dec 29 22:55:55 2004 @@ -17,7 +17,7 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <!-- - <![CDATA[ CVS Version: $Id: wildcardheader-matcher.xml,v 1.6 2004/05/08 08:57:58 crossley Exp $ + <![CDATA[ CVS Version: $Id$ ]]> --> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcarduri-matcher.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcarduri-matcher.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcarduri-matcher.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcarduri-matcher.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcarduri-matcher.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/matchers/wildcarduri-matcher.xml Wed Dec 29 22:55:55 2004 @@ -17,7 +17,7 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <!-- - <![CDATA[ CVS Version: $Id: wildcarduri-matcher.xml,v 1.6 2004/05/08 08:57:58 crossley Exp $ + <![CDATA[ CVS Version: $Id$ ]]> --> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/offline/ant.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/offline/ant.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/offline/ant.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/offline/ant.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/offline/ant.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/offline/ant.xml Wed Dec 29 22:55:55 2004 @@ -18,31 +18,31 @@ <document> <header> - <title>Offline Page Generation with Apache Ant</title> - <version>1.0</version> - <type>Technical document</type> - <authors><person name="Upayavira" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document explains how to use Cocoon to generate offline pages and sites with Apache Ant.</abstract> + <title>Offline Page Generation with Apache Ant</title> + <version>1.0</version> + <type>Technical document</type> + <authors><person name="Upayavira" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document explains how to use Cocoon to generate offline pages and sites with Apache Ant.</abstract> </header> <body> - <s1 title="Overview"> - <p>Apache Ant can be used to start Cocoon in its Offline mode. A specific Ant - task is available, allowing the user to embed the Cocoon configuration - information into Ant's build script. + <s1 title="Overview"> + <p>Apache Ant can be used to start Cocoon in its Offline mode. A specific Ant + task is available, allowing the user to embed the Cocoon configuration + information into Ant's build script. </p> - </s1> - <s1 title="Configuring the Ant task"> - <p>The main configuration for the task is to specify a <code>cocoon.context</code> property which points to the - Cocoon webapp from which the pages or site are to be generated.</p> - <p>From this property, a classpath can be created. By default, this should point to <code>WEB-INF/classes</code> - and all jar files in <code>WEB-INF/lib</code>. Futher classpaths can be added if they are needed.</p> - <p>The taskdef requires this classpath in order to invoke the Ant task, and the task itself needs the classpath in - order to invoke Cocoon.</p> - <p>Beyond these configurations, the rest are the same as is used by the <link href="cli.html">Command Line interface</link>, - and is detailed on the <link href="configuration.html">configuration</link> page.</p> - </s1> - <s1 title="Sample Ant Task"> + </s1> + <s1 title="Configuring the Ant task"> + <p>The main configuration for the task is to specify a <code>cocoon.context</code> property which points to the + Cocoon webapp from which the pages or site are to be generated.</p> + <p>From this property, a classpath can be created. By default, this should point to <code>WEB-INF/classes</code> + and all jar files in <code>WEB-INF/lib</code>. Futher classpaths can be added if they are needed.</p> + <p>The taskdef requires this classpath in order to invoke the Ant task, and the task itself needs the classpath in + order to invoke Cocoon.</p> + <p>Beyond these configurations, the rest are the same as is used by the <link href="cli.html">Command Line interface</link>, + and is detailed on the <link href="configuration.html">configuration</link> page.</p> + </s1> + <s1 title="Sample Ant Task"> <p>A sample ant build file is shown below. This sample shows only that which is required to configure the Ant task. For further details of configuring Cocoon, see the <link href="configuration.html">configuration</link> page.</p> @@ -85,7 +85,7 @@ src-prefix="" src="index.html" dest="${cocoon.context}/build/dest/"/> - </uris> + </uris> </cocoon> </target> </project> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/offline/bean.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/offline/bean.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/offline/bean.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/offline/bean.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/offline/bean.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/offline/bean.xml Wed Dec 29 22:55:55 2004 @@ -18,20 +18,20 @@ <document> <header> - <title>The Cocoon Bean</title> - <version>0.9</version> - <type>Technical document</type> - <authors><person name="Upayavira" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document details the basics of using the Cocoon bean.</abstract> + <title>The Cocoon Bean</title> + <version>0.9</version> + <type>Technical document</type> + <authors><person name="Upayavira" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document details the basics of using the Cocoon bean.</abstract> </header> <body> - <s1 title="Overview"> - <p>The Cocoon Bean provides a Java programmatic interface for embedding Cocoon into other - applications. - </p> - </s1> - <s1 title="Details"> + <s1 title="Overview"> + <p>The Cocoon Bean provides a Java programmatic interface for embedding Cocoon into other + applications. + </p> + </s1> + <s1 title="Details"> <p>At present, the bean is mainly used for offline page generation. However, there is no reason why it should only be used in offline applications.</p> <p>An example of an application that uses the bean is the Cocoon Command Line Interface (CLI). Modified: cocoon/trunk/src/documentation/xdocs/userdocs/selectors/browser-selector.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/selectors/browser-selector.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/browser-selector.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/browser-selector.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/selectors/browser-selector.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/selectors/browser-selector.xml Wed Dec 29 22:55:55 2004 @@ -17,7 +17,7 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <!-- - <![CDATA[ CVS Version: $Id: browser-selector.xml,v 1.6 2004/05/08 08:57:58 crossley Exp $ + <![CDATA[ CVS Version: $Id$ ]]> --> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/selectors/host-selector.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/selectors/host-selector.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/host-selector.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/host-selector.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/selectors/host-selector.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/selectors/host-selector.xml Wed Dec 29 22:55:55 2004 @@ -17,7 +17,7 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <!-- - <![CDATA[ CVS Version: $Id: host-selector.xml,v 1.7 2004/05/08 08:57:58 crossley Exp $ + <![CDATA[ CVS Version: $Id$ ]]> --> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/selectors/parameter-selector.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/selectors/parameter-selector.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/parameter-selector.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/parameter-selector.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/selectors/parameter-selector.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/selectors/parameter-selector.xml Wed Dec 29 22:55:55 2004 @@ -82,9 +82,9 @@ <map:selectors> ... <map:selector - name="parameter" - logger="sitemap.selector.parameter" - src="org.apache.cocoon.selection.ParameterSelector"/> + name="parameter" + logger="sitemap.selector.parameter" + src="org.apache.cocoon.selection.ParameterSelector"/> ...]]></source> <p> @@ -153,8 +153,8 @@ <map:when test="aggregate"> <map:aggregate element="site"> - <map:part src="cocoon:/{1}/sidebar-{1}/{2}.xml"/> - <map:part src="cocoon:/body-{1}/{2}.xsp"/> + <map:part src="cocoon:/{1}/sidebar-{1}/{2}.xml"/> + <map:part src="cocoon:/body-{1}/{2}.xsp"/> </map:aggregate> <map:transform src="stylesheets/aggregate2xhtml.xsl"/> <map:serialize/> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/selectors/regular-expression-header-selector.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/selectors/regular-expression-header-selector.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/regular-expression-header-selector.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/regular-expression-header-selector.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/selectors/regular-expression-header-selector.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/selectors/regular-expression-header-selector.xml Wed Dec 29 22:55:55 2004 @@ -136,8 +136,8 @@ <code><map:when></code> clause must be declared in a <code>pattern</code> name attribute. </p> - <p>The header-name can be overridden by a parameter element. - </p> + <p>The header-name can be overridden by a parameter element. + </p> </s2> <s2 title="Effect on Object Model and Sitemap Parameters"> <p> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestattribute-selector.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestattribute-selector.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestattribute-selector.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestattribute-selector.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestattribute-selector.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestattribute-selector.xml Wed Dec 29 22:55:55 2004 @@ -17,7 +17,7 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <!-- - <![CDATA[ CVS Version: $Id: requestattribute-selector.xml,v 1.7 2004/05/08 08:57:58 crossley Exp $ + <![CDATA[ CVS Version: $Id$ ]]> --> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestparameter-selector.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestparameter-selector.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestparameter-selector.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestparameter-selector.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestparameter-selector.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/selectors/requestparameter-selector.xml Wed Dec 29 22:55:55 2004 @@ -17,7 +17,7 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <!-- - <![CDATA[ CVS Version: $Id: requestparameter-selector.xml,v 1.8 2004/05/08 08:57:58 crossley Exp $ + <![CDATA[ CVS Version: $Id$ ]]> --> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/selectors/selectors.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/selectors/selectors.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/selectors.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/selectors/selectors.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/selectors/selectors.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/selectors/selectors.xml Wed Dec 29 22:55:55 2004 @@ -17,29 +17,29 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Selectors</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - <person name="Gianugo Rabellino" email="[EMAIL PROTECTED]"/> - <person name="Diana Shannon, ed." email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes all of the available selectors of Cocoon.</abstract> - </header> - <body> - <s1 title="Goal"> - <p> + <header> + <title>Selectors</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + <person name="Gianugo Rabellino" email="[EMAIL PROTECTED]"/> + <person name="Diana Shannon, ed." email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes all of the available selectors of Cocoon.</abstract> + </header> + <body> + <s1 title="Goal"> + <p> This document lists all of the available selectors of Apache Cocoon and describes their purpose. You may also wish to read <link href="../concepts/matchers_selectors.html">Using and Implementing Matchers and Selectors</link>. </p> - </s1> - <s1 title="Overview"> - <p> + </s1> + <s1 title="Overview"> + <p> Selectors in Apache Cocoon have a role similar to matchers with additional flexibility. If you haven't learned about matchers yet, read about them <link href="../matchers/matchers.html">here</link> @@ -93,40 +93,40 @@ ]]> </source> - </s1> - <s1 title="The Selectors in Cocoon"> - <p> + </s1> + <s1 title="The Selectors in Cocoon"> + <p> Available Selectors in Cocoon include the following: </p> - <ul> - <li><strong>BrowserSelector</strong>: matches the value of the "test" + <ul> + <li><strong>BrowserSelector</strong>: matches the value of the "test" parameter against the HTTP User-Agent header, allowing it to recognize the browser issuing the request;</li> - <li><strong>CodeSelector</strong>: matches a snippet of Java code + <li><strong>CodeSelector</strong>: matches a snippet of Java code given as the "test" parameter against the environment;</li> - <li><strong>HostSelector</strong>: matches the "test" parameter value + <li><strong>HostSelector</strong>: matches the "test" parameter value against the Host request header</li> - <li><link href="parameter-selector.html">ParameterSelector</link>: matches the string specified + <li><link href="parameter-selector.html">ParameterSelector</link>: matches the string specified in the "test" parameter against a specified Cocoon internal (e.g. sitemap) parameter;</li> - <li><strong>HeaderSelector</strong>: same as the Parameter selector, + <li><strong>HeaderSelector</strong>: same as the Parameter selector, but matches against the request headers;</li> - <li><link href="regular-expression-header-selector.html">RegexpHeaderSelector</link>: same as the Header selector, + <li><link href="regular-expression-header-selector.html">RegexpHeaderSelector</link>: same as the Header selector, but uses a regular expression for matching;</li> - <li><strong>RequestSelector</strong>: again, same as the Parameter selector, + <li><strong>RequestSelector</strong>: again, same as the Parameter selector, but matches against the Request parameters;</li> - <li><strong>SessionSelector</strong>: finally, this selector is used as + <li><strong>SessionSelector</strong>: finally, this selector is used as the Parameter selector to match against an arbitrary session attribute;</li> - </ul> - </s1> - </body> + </ul> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/serializers/link-serializer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/serializers/link-serializer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/serializers/link-serializer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/serializers/link-serializer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/serializers/link-serializer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/serializers/link-serializer.xml Wed Dec 29 22:55:55 2004 @@ -17,19 +17,19 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Link Serializer</title> - <version>1.0</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - <person name="Torsten Knodt" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the link serializer of Cocoon.</abstract> - </header> - <body> - <s1 title="Link Serializer"> - <p>The link serializer generates a list of links + <header> + <title>Link Serializer</title> + <version>1.0</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + <person name="Torsten Knodt" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the link serializer of Cocoon.</abstract> + </header> + <body> + <s1 title="Link Serializer"> + <p>The link serializer generates a list of links using <link href="http://www.w3.org/TR/xlink/";>XLink</link> from the sax events. Most <link href="http://www.w3.org/MarkUp/";>XHTML</link> @@ -38,14 +38,14 @@ <code>application/x-cocoon-links</code>. This serializer is required by the link status generator and the command line mode to follow links.</p> - <ul> - <li>Name: links</li> - <li>Class: org.apache.cocoon.serialization.LinkSerializer</li> - <li>Cacheable: no</li> - </ul> - </s1> + <ul> + <li>Name: links</li> + <li>Class: org.apache.cocoon.serialization.LinkSerializer</li> + <li>Cacheable: no</li> + </ul> + </s1> <s1 title="Usage"> - <p>To use the link serializer for the command-line or the + <p>To use the link serializer for the command-line or the link status generator, you need the following entries in your sitemap:</p> <source><![CDATA[ @@ -63,5 +63,5 @@ </map:views> ]]></source> </s1> - </body> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svg-serializer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svg-serializer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svg-serializer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svg-serializer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svg-serializer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svg-serializer.xml Wed Dec 29 22:55:55 2004 @@ -77,7 +77,7 @@ <map:match pattern="sample.jpeg"> <map:generate type="file" src="sample.svg"/> <map:serialize type="svg2jpeg"/> - </map:match> + </map:match> </map:pipeline> ]]></source> <p> @@ -120,7 +120,7 @@ <map:match pattern="sample.jpeg"> <map:generate type="file" src="sample.svg"/> <map:serialize type="svg2jpeg"/> - </map:match> + </map:match> </map:pipeline> ]]></source> <p> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svgtiff-serializer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svgtiff-serializer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svgtiff-serializer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svgtiff-serializer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svgtiff-serializer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/serializers/svgtiff-serializer.xml Wed Dec 29 22:55:55 2004 @@ -86,7 +86,7 @@ </p> <table> <tr><th>Parameter</th><th>Type</th><th>Comment</th></tr> - <tr><td>force_transparent_white</td><td>boolean</td><td>It controls whether the encoder should + <tr><td>force_transparent_white</td><td>boolean</td><td>It controls whether the encoder should force the image's fully transparent pixels to be fully transparent white instead of fully transparent black. This is usefull when the encoded TIFF is displayed in a viewer which does not support TIFF Modified: cocoon/trunk/src/documentation/xdocs/userdocs/serializers/vrml-serializer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/serializers/vrml-serializer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/serializers/vrml-serializer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/serializers/vrml-serializer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/serializers/vrml-serializer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/serializers/vrml-serializer.xml Wed Dec 29 22:55:55 2004 @@ -17,23 +17,23 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>VRML Serializer</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the vrml serializer of Cocoon.</abstract> - </header> - <body> - <s1 title="VRML Serializer"> - <p>????.</p> - <ul> - <li>Name : vrml</li> - <li>Class: org.apache.cocoon.serialization.TextSerializer</li> - <li>Cacheable: yes.</li> - </ul> - </s1> - </body> + <header> + <title>VRML Serializer</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the vrml serializer of Cocoon.</abstract> + </header> + <body> + <s1 title="VRML Serializer"> + <p>????.</p> + <ul> + <li>Name : vrml</li> + <li>Class: org.apache.cocoon.serialization.TextSerializer</li> + <li>Cacheable: yes.</li> + </ul> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/serializers/ziparchive-serializer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/serializers/ziparchive-serializer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/serializers/ziparchive-serializer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/serializers/ziparchive-serializer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/serializers/ziparchive-serializer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/serializers/ziparchive-serializer.xml Wed Dec 29 22:55:55 2004 @@ -17,19 +17,19 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Zip archive Serializer</title> - <version>1.0</version> - <type>Technical document</type> - <authors> - <person name="Sylvain Wallez" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the Zip archive serializer of Cocoon.</abstract> - </header> - <body> - <s1 title="Zip archive Serializer"> - <p>The Zip archive serializer generates a zip archive by aggregating several sources.</p> - + <header> + <title>Zip archive Serializer</title> + <version>1.0</version> + <type>Technical document</type> + <authors> + <person name="Sylvain Wallez" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the Zip archive serializer of Cocoon.</abstract> + </header> + <body> + <s1 title="Zip archive Serializer"> + <p>The Zip archive serializer generates a zip archive by aggregating several sources.</p> + <p>The input document should describe entries of the archive by means of their name (which can be a path) and their content either as URLs or inline data :</p> @@ -60,11 +60,11 @@ </zip:archive> </source> - <ul> - <li>Name: zip</li> - <li>Class: org.apache.cocoon.serialization.ZipArchiveSerializer</li> - <li>Cacheable: no</li> - </ul> - </s1> - </body> + <ul> + <li>Name: zip</li> + <li>Class: org.apache.cocoon.serialization.ZipArchiveSerializer</li> + <li>Cacheable: no</li> + </ul> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/transformers/cinclude-transformer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/transformers/cinclude-transformer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/cinclude-transformer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/cinclude-transformer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/transformers/cinclude-transformer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/transformers/cinclude-transformer.xml Wed Dec 29 22:55:55 2004 @@ -132,75 +132,75 @@ ]]></source> </s1> <s1 title="Including External XML (simple)"> - <p>One feature of the cinclude transformer (this is currently not - supported by the caching cinclude transformer) is including XML from - external sources, e.g. files or from an HTTP server. - The <code>cinclude:includexml</code> tag starts including of XML:</p> - <source> + <p>One feature of the cinclude transformer (this is currently not + supported by the caching cinclude transformer) is including XML from + external sources, e.g. files or from an HTTP server. + The <code>cinclude:includexml</code> tag starts including of XML:</p> + <source> <cinclude:includexml> <!-- Include XML from HTTP server --> <cinclude:src>http://external.news.com/flashnews.xml</cinclude:src> </cinclude:includexml> </source> - <p> This would be a simple way of "get"ting XML data from an - external site. Using this method it is also possible to pass parameters in the - url - just as you would in a "get" sent from a browser.</p> - <source> + <p> This would be a simple way of "get"ting XML data from an + external site. Using this method it is also possible to pass parameters in the + url - just as you would in a "get" sent from a browser.</p> + <source> <cinclude:includexml> <!-- Include XML from HTTP server --> <cinclude:src>http://external.news.com/flashnews.xml?id=1234&myname=matthew</cinclude:src> </cinclude:includexml> </source> - <p>If the external XML is not valid or not available, the - transformer signals an error to the pipeline and the document containing the - include command is not available.</p> - <p>For this purpose the <code>ignoreErrors</code> attribute can be - used:</p> - <source> + <p>If the external XML is not valid or not available, the + transformer signals an error to the pipeline and the document containing the + include command is not available.</p> + <p>For this purpose the <code>ignoreErrors</code> attribute can be + used:</p> + <source> <cinclude:includexml ignoreErrors="true"> ... </cinclude:includexml></source> - </s1> - <s1 title="Including External XML (advanced)"> - <p>The above section shows you how to include XML data from an - external source such as an HTTP server using the simple "get" method supplied - in the HTTP protocol. For more advanced uses you will wish to be able to send - "Post" or other HTTP methods to the server. In addition you may want to - actually send XML data to the server - just as you would using an HTML form. - The format of this resource is slightly more complicated:</p> - <source> + </s1> + <s1 title="Including External XML (advanced)"> + <p>The above section shows you how to include XML data from an + external source such as an HTTP server using the simple "get" method supplied + in the HTTP protocol. For more advanced uses you will wish to be able to send + "Post" or other HTTP methods to the server. In addition you may want to + actually send XML data to the server - just as you would using an HTML form. + The format of this resource is slightly more complicated:</p> + <source> <?xml version="1.0"?> <data xmlns:cinclude="http://apache.org/cocoon/include/1.0"> <cinclude:includexml> <cinclude:src>http://itsunshine/tamino/blah</cinclude:src> <cinclude:configuration> - <cinclude:parameter> - <cinclude:name>method</cinclude:name> - <cinclude:value>POST</cinclude:value> - </cinclude:parameter> + <cinclude:parameter> + <cinclude:name>method</cinclude:name> + <cinclude:value>POST</cinclude:value> + </cinclude:parameter> </cinclude:configuration> <cinclude:parameters> <cinclude:parameter> - <cinclude:name>message</cinclude:name> - <cinclude:value>Hi there</cinclude:value> - </cinclude:parameter> - <cinclude:parameter> - <cinclude:name>_Process</cinclude:name> - <cinclude:value><name>matti</name><age>36</age></cinclude:value> - </cinclude:parameter> + <cinclude:name>message</cinclude:name> + <cinclude:value>Hi there</cinclude:value> + </cinclude:parameter> + <cinclude:parameter> + <cinclude:name>_Process</cinclude:name> + <cinclude:value><name>matti</name><age>36</age></cinclude:value> + </cinclude:parameter> </cinclude:parameters> </cinclude:includexml> </data> - </source> - <p>Lets look at the tags. The tag <code>cinclude:src</code> defines the address of the - resource we want to access and then comes a list of (optional) - connection-specific parameters (enclosed in the <code>cinclude:configuration</code> tag). - In this example the HTTP-method ("POST") is passed into the connection. The - format of these parameters is discussed next.</p> - <p>Then comes the list of parameters we wish to pass into the - function. Each parameter defined has a name and a value. The value can either - be text or XML.</p> - <p>The format of the parameters is the same as for the connection - configuration.</p> - </s1> + </source> + <p>Lets look at the tags. The tag <code>cinclude:src</code> defines the address of the + resource we want to access and then comes a list of (optional) + connection-specific parameters (enclosed in the <code>cinclude:configuration</code> tag). + In this example the HTTP-method ("POST") is passed into the connection. The + format of these parameters is discussed next.</p> + <p>Then comes the list of parameters we wish to pass into the + function. Each parameter defined has a name and a value. The value can either + be text or XML.</p> + <p>The format of the parameters is the same as for the connection + configuration.</p> + </s1> <s1 title="Caching"> <p>This transformer includes XML in the current stream and acts therefore as a kind of (dynamic) content aggregation. However, the included content Modified: cocoon/trunk/src/documentation/xdocs/userdocs/transformers/extractor-transformer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/transformers/extractor-transformer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/extractor-transformer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/extractor-transformer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/transformers/extractor-transformer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/transformers/extractor-transformer.xml Wed Dec 29 22:55:55 2004 @@ -17,24 +17,24 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Fragment Extractor Transformer</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the Fragment Extractor transformer of Cocoon.</abstract> - </header> - <body> - <s1 title="Fragment Extractor Transformer"> - <p>This transformer sieves an incoming stream of xml with embedded SVG images + <header> + <title>Fragment Extractor Transformer</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the Fragment Extractor transformer of Cocoon.</abstract> + </header> + <body> + <s1 title="Fragment Extractor Transformer"> + <p>This transformer sieves an incoming stream of xml with embedded SVG images and replaces the images with an xlink locator pointing to the image.</p> - <ul> - <li>Name : extractor</li> - <li>Class: org.apache.cocoon.transformation.FragmentExtractorTransformer</li> - <li>Cacheable: no.</li> - </ul> - </s1> - </body> + <ul> + <li>Name : extractor</li> + <li>Class: org.apache.cocoon.transformation.FragmentExtractorTransformer</li> + <li>Cacheable: no.</li> + </ul> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/transformers/filter-transformer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/transformers/filter-transformer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/filter-transformer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/filter-transformer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/transformers/filter-transformer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/transformers/filter-transformer.xml Wed Dec 29 22:55:55 2004 @@ -17,26 +17,26 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Filter Transformer</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - <person name="Sven Beauprez" email="[EMAIL PROTECTED]"/> - <person name="Davanum Srinivas" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the Filter transformer of Cocoon.</abstract> - </header> - <body> - <s1 title="Filter Transformer"> - <p>The filter transformer can be used to let only an amount of elements + <header> + <title>Filter Transformer</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + <person name="Sven Beauprez" email="[EMAIL PROTECTED]"/> + <person name="Davanum Srinivas" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the Filter transformer of Cocoon.</abstract> + </header> + <body> + <s1 title="Filter Transformer"> + <p>The filter transformer can be used to let only an amount of elements through in a given block.</p> - <ul> - <li>Name : filter</li> - <li>Class: org.apache.cocoon.transformation.FilterTransformer</li> - <li>Cacheable: no.</li> - </ul> + <ul> + <li>Name : filter</li> + <li>Class: org.apache.cocoon.transformation.FilterTransformer</li> + <li>Cacheable: no.</li> + </ul> <p> When you for example query a database and it returns too many rows too process at once, you might want to take a block of elements, process this block and ignore the rest @@ -128,6 +128,6 @@ The FilterTransformer is a standalone component, you don't need to use it in combination with the SQLTransformer. </p> - </s1> - </body> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/transformers/ldap-transformer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/transformers/ldap-transformer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/ldap-transformer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/ldap-transformer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/transformers/ldap-transformer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/transformers/ldap-transformer.xml Wed Dec 29 22:55:55 2004 @@ -17,29 +17,29 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>LDAP Transformer</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the LDAP transformer of Cocoon.</abstract> - </header> - <body> - <s1 title="LDAP Transformer"> - <p> + <header> + <title>LDAP Transformer</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the LDAP transformer of Cocoon.</abstract> + </header> + <body> + <s1 title="LDAP Transformer"> + <p> The <code>LDAPTransformer</code> is a class that can be plugged into a pipeline to transform the SAX events which passes through this transformer into queries to an ldap interface and transforms the response to SAX events which are passed on in the pipeline. </p> - <ul> - <li>Name : ldap</li> - <li>Class: org.apache.cocoon.transformation.LDAPTransformer</li> - <li>Cacheable: no.</li> - </ul> - <p>This transformer is optional and not available in the binary distribution. + <ul> + <li>Name : ldap</li> + <li>Class: org.apache.cocoon.transformation.LDAPTransformer</li> + <li>Cacheable: no.</li> + </ul> + <p>This transformer is optional and not available in the binary distribution. However if you want to use it, you have to retrieve the jndi package, copy the jar file into the lib directory of Cocoon and rebuild. </p> @@ -78,6 +78,6 @@ <!ELEMENT debug (TRUE | FALSE)>* (default: FALSE)<br/> can also be defined as parameter in the sitemap. </p> - </s1> - </body> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/transformers/log-transformer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/transformers/log-transformer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/log-transformer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/log-transformer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/transformers/log-transformer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/transformers/log-transformer.xml Wed Dec 29 22:55:55 2004 @@ -17,18 +17,18 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Log Transformer</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the Log transformer of Cocoon.</abstract> - </header> - <body> - <s1 title="Log Transformer"> - <p>This transformations main purpose is debugging. + <header> + <title>Log Transformer</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the Log transformer of Cocoon.</abstract> + </header> + <body> + <s1 title="Log Transformer"> + <p>This transformations main purpose is debugging. The <code>LogTransformer</code> is a class that can be plugged into a pipeline to print the SAX events which passes through this transformer in a readable form to a file.</p> @@ -45,11 +45,11 @@ Because the log file will be hardcoded into the sitemap this LOGTransformer will not be thread save! If you don't specify the logfile the output is send to the standard output of your servlet engine.</p> - <ul> - <li>Name : log</li> - <li>Class: org.apache.cocoon.transformation.LogTransformer</li> - <li>Cacheable: no.</li> - </ul> - </s1> - </body> + <ul> + <li>Name : log</li> + <li>Class: org.apache.cocoon.transformation.LogTransformer</li> + <li>Cacheable: no.</li> + </ul> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/transformers/readdomsession-transformer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/transformers/readdomsession-transformer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/readdomsession-transformer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/readdomsession-transformer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/transformers/readdomsession-transformer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/transformers/readdomsession-transformer.xml Wed Dec 29 22:55:55 2004 @@ -17,26 +17,26 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Read DOM Session Transformer</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - <person name="Sven Beauprez" email="[EMAIL PROTECTED]"/> - <person name="Davanum Srinivas" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the read dom session transformer of Cocoon.</abstract> - </header> - <body> - <s1 title="Read DOM Session Transformer"> - <p>With this transformer, a DOM-object that is stored in the session, can be inserted + <header> + <title>Read DOM Session Transformer</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + <person name="Sven Beauprez" email="[EMAIL PROTECTED]"/> + <person name="Davanum Srinivas" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the read dom session transformer of Cocoon.</abstract> + </header> + <body> + <s1 title="Read DOM Session Transformer"> + <p>With this transformer, a DOM-object that is stored in the session, can be inserted in the SAX stream at a given position.</p> - <ul> - <li>Name : readDOMsession</li> - <li>Class: org.apache.cocoon.transformation.ReadDOMSessionTransformer</li> - <li>Cacheable: no.</li> - </ul> + <ul> + <li>Name : readDOMsession</li> + <li>Class: org.apache.cocoon.transformation.ReadDOMSessionTransformer</li> + <li>Cacheable: no.</li> + </ul> <p> Simply transforms a DOM to SAX-events, which can be used further on in the pipeline. Once you stored the result of a query in the session with the @@ -79,6 +79,6 @@ The ReadDOMSessionTransformer is a standalone component, you don't need to use it in combination with the WriteDOMSessionTransformer. </p> - </s1> - </body> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/transformers/transformers.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/transformers/transformers.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/transformers.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/transformers.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/transformers/transformers.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/transformers/transformers.xml Wed Dec 29 22:55:55 2004 @@ -17,21 +17,21 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Transformers</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes all of the available transformers of Cocoon.</abstract> - </header> - <body> - <s1 title="Goal"> - <p>This document lists all of the available transformers of Apache Cocoon and + <header> + <title>Transformers</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes all of the available transformers of Cocoon.</abstract> + </header> + <body> + <s1 title="Goal"> + <p>This document lists all of the available transformers of Apache Cocoon and describes their purpose.</p> - </s1> - <s1 title="Overview"> + </s1> + <s1 title="Overview"> <p> A transformer is the central point in a sitemap pipeline. Within a pipeline match, transformers consume SAX events and emit SAX events. Transformers are placed inside a pipeline match between a generator and a serializer. You can include several transformers within a pipeline match. Any pipeline match containing a generator and transformer must end with a serializer. </p> @@ -45,24 +45,24 @@ <s1 title="The Transformers in Apache Cocoon"> <ul> <li><link href="xslt-transformer.html">XSLT Transformer</link> (The default transformer)</li> - <li><link href="extractor-transformer.html">Fragment Extractor Transformer</link></li> - <li><link href="i18n-transformer.html">I18n Transformer</link></li> - <li><link href="log-transformer.html">Log Transformer</link></li> - <li><link href="sql-transformer.html">SQL Transformer</link></li> - <li><link href="filter-transformer.html">Filter Transformer</link></li> - <li><link href="readdomsession-transformer.html">Read DOM Session Transformer</link></li> - <li><link href="writedomsession-transformer.html">Write DOM Session Transformer</link></li> - <li><link href="xinclude-transformer.html">XInclude Transformer</link></li> - <li><link href="cinclude-transformer.html">CInclude Transformer</link></li> - <li><link href="encodeurl-transformer.html">EncodeURL Transformer</link></li> - <li><link href="sourcewriting-transformer.html">SourceWriting Transformer</link></li> + <li><link href="extractor-transformer.html">Fragment Extractor Transformer</link></li> + <li><link href="i18n-transformer.html">I18n Transformer</link></li> + <li><link href="log-transformer.html">Log Transformer</link></li> + <li><link href="sql-transformer.html">SQL Transformer</link></li> + <li><link href="filter-transformer.html">Filter Transformer</link></li> + <li><link href="readdomsession-transformer.html">Read DOM Session Transformer</link></li> + <li><link href="writedomsession-transformer.html">Write DOM Session Transformer</link></li> + <li><link href="xinclude-transformer.html">XInclude Transformer</link></li> + <li><link href="cinclude-transformer.html">CInclude Transformer</link></li> + <li><link href="encodeurl-transformer.html">EncodeURL Transformer</link></li> + <li><link href="sourcewriting-transformer.html">SourceWriting Transformer</link></li> <li><link href="augment-transformer.html">Augment Transformer</link></li> - <li><link href="ldap-transformer.html">LDAP Transformer</link> (optional)</li> + <li><link href="ldap-transformer.html">LDAP Transformer</link> (optional)</li> <li><link href="lexer-transformer.html">Lexical Transformer</link> (optional)</li> <li><link href="parser-transformer.html">Parser Transformer</link> (optional)</li> <li><link href="pattern-transformer.html">Pattern Transformer</link> (optional)</li> <li><link href="../../developing/webapps/contexts.html">Session Transformer</link> (optional)</li> </ul> </s1> - </body> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/transformers/writedomsession-transformer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/transformers/writedomsession-transformer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/writedomsession-transformer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/writedomsession-transformer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/transformers/writedomsession-transformer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/transformers/writedomsession-transformer.xml Wed Dec 29 22:55:55 2004 @@ -17,25 +17,25 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>Write DOM Session Transformer</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - <person name="Sven Beauprez" email="[EMAIL PROTECTED]"/> - <person name="Davanum Srinivas" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the write dom session transformer of Cocoon.</abstract> - </header> - <body> - <s1 title="Write DOM Session Transformer"> - <p>Make a DOM object from SAX events and write it to the session.</p> - <ul> - <li>Name : writeDOMsession</li> - <li>Class: org.apache.cocoon.transformation.WriteDOMSessionTransformer</li> - <li>Cacheable: no.</li> - </ul> + <header> + <title>Write DOM Session Transformer</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + <person name="Sven Beauprez" email="[EMAIL PROTECTED]"/> + <person name="Davanum Srinivas" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the write dom session transformer of Cocoon.</abstract> + </header> + <body> + <s1 title="Write DOM Session Transformer"> + <p>Make a DOM object from SAX events and write it to the session.</p> + <ul> + <li>Name : writeDOMsession</li> + <li>Class: org.apache.cocoon.transformation.WriteDOMSessionTransformer</li> + <li>Cacheable: no.</li> + </ul> <p> If you only use the FilterTransformer in combination with the SQLTransformer, you have to query the database each time the user wants to see another part of @@ -72,6 +72,6 @@ The WriteDOMSessionTransformer is a standalone component, you don't need to use it in combination with the SQLTransformer. </p> - </s1> - </body> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/transformers/xslt-transformer.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/transformers/xslt-transformer.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/xslt-transformer.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/transformers/xslt-transformer.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/transformers/xslt-transformer.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/transformers/xslt-transformer.xml Wed Dec 29 22:55:55 2004 @@ -17,52 +17,52 @@ <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN" "document-v10.dtd"> <document> - <header> - <title>XSLT Transformer</title> - <version>0.9</version> - <type>Technical document</type> - <authors> - <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> - <person name="Sylvain Wallez" email="[EMAIL PROTECTED]"/> - </authors> - <abstract>This document describes the xslt transformer of Cocoon.</abstract> - </header> - <body> - <s1 title="Trax/XSLT Transformer"> - <p>The xslt transformer reads an xsl document from the local file system or from any url. - It transforms the sax stream using this stylesheet.</p> - <p>The xslt transformer is the default transformer .</p> - <ul> - <li>Name : xslt</li> - <li>Class: org.apache.cocoon.transformation.TraxTransformer</li> - <li>Cacheable: yes - uses the last modification date of the xsl document for validation.</li> - </ul> - <p>The xslt transformer is configurable. You can specify one or more of + <header> + <title>XSLT Transformer</title> + <version>0.9</version> + <type>Technical document</type> + <authors> + <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/> + <person name="Sylvain Wallez" email="[EMAIL PROTECTED]"/> + </authors> + <abstract>This document describes the xslt transformer of Cocoon.</abstract> + </header> + <body> + <s1 title="Trax/XSLT Transformer"> + <p>The xslt transformer reads an xsl document from the local file system or from any url. + It transforms the sax stream using this stylesheet.</p> + <p>The xslt transformer is the default transformer .</p> + <ul> + <li>Name : xslt</li> + <li>Class: org.apache.cocoon.transformation.TraxTransformer</li> + <li>Cacheable: yes - uses the last modification date of the xsl document for validation.</li> + </ul> + <p>The xslt transformer is configurable. You can specify one or more of the following configuration information:</p> - <ul> - <li>use-request-parameters: true|false - Setting this to true makes all + <ul> + <li>use-request-parameters: true|false - Setting this to true makes all request parameters available in the XSLT stylesheet. Note that this might have issues concerning cachability of the generated output of this transformer, the caching algorithm not only checks the last modification date but also all values of the request parameters. This property is false by default. If set to true the values of a request parameter is available using a variable in the xslt with the name of the parameter.</li> - <li>use-browser-capabilities-db: true|false - This configuration forces the transformer to make all + <li>use-browser-capabilities-db: true|false - This configuration forces the transformer to make all properties from the browser capability database available in the XSLT stylesheet as. Note that this might have issues concerning cachability of the generated output of this transformer as the caching algorithm adds this values to the validation phase. The default for this property is false.</li> - <li>use-cookies: true|false - This configuration forces the transformer to make all - cookies from the request available in the XSLT stylesheetas. - Note that this might have issues concerning cachability of the generated output of this - transformer. This property is false by default.</li> - <li>xslt-processor-role: [role name] - This configuration allows to specify the XSLT processor (see below) - that will be used by its role name. This allows to have several XSLT processors in the configuration - (e.g. Xalan and Saxon) and choose one or the other depending on the needs of stylesheet - specificities. This property defaults to "org.apache.cocoon.components.xslt.XSLTProcessor" - which is the standard role name for an XSLTProcessor.</li> - </ul> - <p>The "use-request-parameters" and "use-browser-capabilities-db" configuration + <li>use-cookies: true|false - This configuration forces the transformer to make all + cookies from the request available in the XSLT stylesheetas. + Note that this might have issues concerning cachability of the generated output of this + transformer. This property is false by default.</li> + <li>xslt-processor-role: [role name] - This configuration allows to specify the XSLT processor (see below) + that will be used by its role name. This allows to have several XSLT processors in the configuration + (e.g. Xalan and Saxon) and choose one or the other depending on the needs of stylesheet + specificities. This property defaults to "org.apache.cocoon.components.xslt.XSLTProcessor" + which is the standard role name for an XSLTProcessor.</li> + </ul> + <p>The "use-request-parameters" and "use-browser-capabilities-db" configuration of a transformer can be changed for one single pipeline by specifying parameters with the same name:</p> <source> @@ -71,33 +71,33 @@ <!-- The type attribute can be omitted as it is the default transformer. --> ]]> </source> - <p>The "use-request-parameters" and "use-browser-capabilities-db" configuration + <p>The "use-request-parameters" and "use-browser-capabilities-db" configuration of a transformer can be changed for one single pipeline by specifying parameters with the same name:</p> <source> <![CDATA[ <map:transform src="stylesheet.xsl"> - <map:parameter name="use-request-parameters" value="true"/> + <map:parameter name="use-request-parameters" value="true"/> </map:transform> ]]> </source> - <p>In addition all other parameters to the transformer are + <p>In addition all other parameters to the transformer are available in the stylesheet as <xsl:param/>s (These values are also used in the caching algorithm.)</p> - </s1> + </s1> <s1 title="The XSLT Processor"> - <p>The XSLT Transformer uses a component called XSLTProcessor. This component is + <p>The XSLT Transformer uses a component called XSLTProcessor. This component is configured in the cocoon.xconf. You can configure it as follows:</p> - <ul> - <li>use-store: true|false - If set to true it forces the xslt processor + <ul> + <li>use-store: true|false - If set to true it forces the xslt processor to put the generated templates from the XSLT stylesheet into the - system store. This property is true by default.</li> - <li>transformer-factory: [class name] - tells the transformer to use a particular - implementation of javax.xml.transform.TransformerFactory. This allows to force the use of - a given TRAX implementation (e.g. xalan or saxon) if several are available in the classpath. - If this property is not set, the transformer uses the standard TRAX mechanism - (TransformerFactory.newInstance()).</li> - </ul> - </s1> - </body> + system store. This property is true by default.</li> + <li>transformer-factory: [class name] - tells the transformer to use a particular + implementation of javax.xml.transform.TransformerFactory. This allows to force the use of + a given TRAX implementation (e.g. xalan or saxon) if several are available in the classpath. + If this property is not set, the transformer uses the standard TRAX mechanism + (TransformerFactory.newInstance()).</li> + </ul> + </s1> + </body> </document> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/xsp/esql.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/xsp/esql.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/xsp/esql.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/xsp/esql.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/xsp/esql.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/xsp/esql.xml Wed Dec 29 22:55:55 2004 @@ -70,31 +70,31 @@ . . . </xsp:page> ]]></source> - + <s2 title="Connection"> - <p>Esql can use connection pools configured in <code>cocoon.xconf</code> or - individually set up connections.</p> - - <p><code>esql:pool</code> gives the name of the connection pool to use.</p> - - <p>Individually configured connections use the <code>esql:driver, - esql:dburl, esql:username, esql:password</code> tags. Their meaning - should be obvious.</p> - - <s3 title="Connection Options"/> - <p>Per default, esql will try to switch a connection to <em>autocommit</em> - mode. This is because it prevents hanging transactions that hold locks and - disturb further database accesses. Esql can be forced to not use - autocommit, by giving the - <code><esql:autocommit>false</esql:autocommit></code> nested - element to <code>esql:connection</code>.</p> - - <note>Even if a connection is configured with autocommit off in - <code>cocoon.xconf</code>, esql will switch autocommit on if not - instructed to do otherwise.</note> + <p>Esql can use connection pools configured in <code>cocoon.xconf</code> or + individually set up connections.</p> + + <p><code>esql:pool</code> gives the name of the connection pool to use.</p> + + <p>Individually configured connections use the <code>esql:driver, + esql:dburl, esql:username, esql:password</code> tags. Their meaning + should be obvious.</p> + + <s3 title="Connection Options"/> + <p>Per default, esql will try to switch a connection to <em>autocommit</em> + mode. This is because it prevents hanging transactions that hold locks and + disturb further database accesses. Esql can be forced to not use + autocommit, by giving the + <code><esql:autocommit>false</esql:autocommit></code> nested + element to <code>esql:connection</code>.</p> + + <note>Even if a connection is configured with autocommit off in + <code>cocoon.xconf</code>, esql will switch autocommit on if not + instructed to do otherwise.</note> - <p>Other options like limiting the size of the resultset are discussed - below.</p> + <p>Other options like limiting the size of the resultset are discussed + below.</p> </s2> </s1> @@ -385,11 +385,11 @@ For a more general alternative see further below.</p> <p>Parameters for a stored procedure call may be of - <code>direction="in|out|inout"</code> with the usual JDBC meaning. In - addition a <code>type</code> needs to be supplied for "out" and "inout" - parameters. This would be the same "XXX" as used in a <code>get-XXX</code> - JDBC-method call. Alternatively, you can use a fully qualified field name, - e.g. "java.sql.Types.CHAR"</p> + <code>direction="in|out|inout"</code> with the usual JDBC meaning. In + addition a <code>type</code> needs to be supplied for "out" and "inout" + parameters. This would be the same "XXX" as used in a <code>get-XXX</code> + JDBC-method call. Alternatively, you can use a fully qualified field name, + e.g. "java.sql.Types.CHAR"</p> <p><code><esql:call-results/></code> (child of <code><esql:execute-query/></code>) may contain code that will @@ -458,10 +458,10 @@ <p>The same holds true for <code>esql:update-results</code> and <code>esql:no-results</code> blocks as well.</p> - <note>Support for multiple results is not widely available with DBMSs. - Therefore support is disabled by default. Use the - <code><esql:allow-multiple-results>yes</esql:allow-multiple-results></code> - parameter to the <esql:connection/>.</note> + <note>Support for multiple results is not widely available with DBMSs. + Therefore support is disabled by default. Use the + <code><esql:allow-multiple-results>yes</esql:allow-multiple-results></code> + parameter to the <esql:connection/>.</note> <p>Example: Suppose stored procedure <code>bar</code> returns an update Modified: cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-concepts.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-concepts.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-concepts.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-concepts.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-concepts.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-concepts.xml Wed Dec 29 22:55:55 2004 @@ -46,13 +46,13 @@ </li> <li> <link href="#java-logicsheets"> - XSLT Logicsheets and XSP for Java - </link> + XSLT Logicsheets and XSP for Java + </link> </li> <li> <link href="#logicsheet-language"> - The SiLLy Logicsheet Language - </link> + The SiLLy Logicsheet Language + </link> </li> </ul> </s1> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-forms.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-forms.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-forms.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-forms.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-forms.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/xsp/logicsheet-forms.xml Wed Dec 29 22:55:55 2004 @@ -405,12 +405,12 @@ <s2 title="Other Validations"> - <p> - In addition to validating form input, other actions exists that validate - values from different sources using the same techniques and syntax. For - example, the <code>SessionValidatorAction</code> operates on session - attributes. - </p> + <p> + In addition to validating form input, other actions exists that validate + values from different sources using the same techniques and syntax. For + example, the <code>SessionValidatorAction</code> operates on session + attributes. + </p> </s2> Modified: cocoon/trunk/src/documentation/xdocs/userdocs/xsp/sendmail.xml Url: http://svn.apache.org/viewcvs/cocoon/trunk/src/documentation/xdocs/userdocs/xsp/sendmail.xml?view=diff&rev=123702&p1=cocoon/trunk/src/documentation/xdocs/userdocs/xsp/sendmail.xml&r1=123701&p2=cocoon/trunk/src/documentation/xdocs/userdocs/xsp/sendmail.xml&r2=123702 ============================================================================== --- cocoon/trunk/src/documentation/xdocs/userdocs/xsp/sendmail.xml (original) +++ cocoon/trunk/src/documentation/xdocs/userdocs/xsp/sendmail.xml Wed Dec 29 22:55:55 2004 @@ -46,42 +46,42 @@ <body> <s1 title="Description"> <p>The Sendmail logicsheet (taglib) is a XSP logicsheet that - wraps XML tags around the operation of sending an email - message. Specifically, the Sendmail logicsheet provides an XML - interface to the primary methods of the Java Mail API for - sending an internet mail including the ability to attach any - binary data files to the message (see the - <link - href="http://java.sun.com/products/javamail/";>Java - Mail API</link> ) for more - information.</p> + wraps XML tags around the operation of sending an email + message. Specifically, the Sendmail logicsheet provides an XML + interface to the primary methods of the Java Mail API for + sending an internet mail including the ability to attach any + binary data files to the message (see the + <link + href="http://java.sun.com/products/javamail/";>Java + Mail API</link> ) for more + information.</p> <p>The Sendmail logicsheet is an alternative to the <link - href="../actions/sendmail-action.html">Sendmail - action</link>.</p> + href="../actions/sendmail-action.html">Sendmail + action</link>.</p> </s1> <s1 title="Usage"> <p>As an XSP logicsheet, the Sendmail logicsheet can only be used - in an XSP page. It may be helpful to be familiar with <link - href="xsp.html">XSP</link> before working with this (or any) - logicsheet.</p> + in an XSP page. It may be helpful to be familiar with <link + href="xsp.html">XSP</link> before working with this (or any) + logicsheet.</p> <p>Since the Sendmail logicsheet is not activated in the default - Cocoon setup, a couple of steps must be taken before an email - can be send.</p> + Cocoon setup, a couple of steps must be taken before an email + can be send.</p> <p>First of all Cocoon must have been compiled with the required - Java Mail API libraries. The libraries <code>mail.jar</code> - from the Java Mail distribution and the library - <code>activation.jar</code> from the Java Activation Framework - have to be copied to the location <code>lib/local</code> of - Cocoon's source distribution. Cocoon must then be recompiled. + Java Mail API libraries. The libraries <code>mail.jar</code> + from the Java Mail distribution and the library + <code>activation.jar</code> from the Java Activation Framework + have to be copied to the location <code>lib/local</code> of + Cocoon's source distribution. Cocoon must then be recompiled. </p> <p>Before the Sendmail logicsheet can be used, some setup in - <code>cocoon.xconf</code> is required. See, if the following - fragment is already existing.</p> + <code>cocoon.xconf</code> is required. See, if the following + fragment is already existing.</p> <source> <![CDATA[ @@ -95,17 +95,17 @@ </source> <p>If it is not present, it is easiest to simply locate the - entry <code>xsp-response</code> for the Response logicsheet - and put the above fragment before the - <code><builtin-logicsheet></code> of the Response - logicsheet entry. This can either be done before recompilation - or later, when Cocoon is already deployed. If done later, - Cocoon must be reloaded.</p> + entry <code>xsp-response</code> for the Response logicsheet + and put the above fragment before the + <code><builtin-logicsheet></code> of the Response + logicsheet entry. This can either be done before recompilation + or later, when Cocoon is already deployed. If done later, + Cocoon must be reloaded.</p> <p>To use the Sendmail logicsheet, you must first declare the - <em>sendmail</em> namespace, mapping it to the uri - <em>http://apache.org/cocoon/sendmail/1.0</em>. These - steps will result in code like this:</p> + <em>sendmail</em> namespace, mapping it to the uri + <em>http://apache.org/cocoon/sendmail/1.0</em>. These + steps will result in code like this:</p> <source> <![CDATA[ @@ -120,16 +120,16 @@ </source> <p>You may then use any of the elements in the <em>sendmail</em> - namespace described in the <link - href="sendmail.html#elements">Elements Reference</link> - section below.</p> + namespace described in the <link + href="sendmail.html#elements">Elements Reference</link> + section below.</p> </s1> <s1 title="Example Code"> <p>The following code shows an example of using the Sendmail - logicsheet. A HTML form is used, to post information about - updated documentation to some imaginary mailing list. The XSP - page is invoked from a HTML form like this.</p> + logicsheet. A HTML form is used, to post information about + updated documentation to some imaginary mailing list. The XSP + page is invoked from a HTML form like this.</p> <source> <![CDATA[ @@ -154,16 +154,16 @@ </source> <p>Since the form allows to attach upto two arbitrary files, it - is important, that <code>enctype="multipart/form-data"</code> - is used. This is the XSP code, that is invoked:</p> + is important, that <code>enctype="multipart/form-data"</code> + is used. This is the XSP code, that is invoked:</p> <source> <![CDATA[ <?xml version="1.0" encoding="ISO-8859-1"?> <xsp:page language="java" - xmlns:xsp="http://apache.org/xsp"; - xmlns:xsp-request="http://apache.org/xsp/request/2.0"; - xmlns:sendmail="http://apache.org/cocoon/sendmail/1.0";> + xmlns:xsp="http://apache.org/xsp"; + xmlns:xsp-request="http://apache.org/xsp/request/2.0"; + xmlns:sendmail="http://apache.org/cocoon/sendmail/1.0";> <email> <xsp:logic> StringBuffer body = new StringBuffer(); @@ -200,9 +200,9 @@ </p> </sendmail:on-success> <sendmail:on-error> - <p style="color:red;"> + <p style="color:red;"> An error occurred: <sendmail:error-message/> - </p> + </p> </sendmail:on-error> </sendmail:send-mail> </email> @@ -211,24 +211,24 @@ </source> <p>Cocoons feature to automatically disassemble the incoming - request puts the uploaded files automatically into the upload - directory and the files are accessible through the - <code>uploaded_file[12]</code> request parameters (make sure, - that <code>autosave-uploads</code> is set to <code>true</code> - in the <code>WEB-INF/web.xml</code> file of the Cocoon - context). By using - <code><xsp:expr>request.get("req-param")</xsp:expr></code> - you actually get an object of class - <code>org.apache.cocoon.servlet.multipart.Part</code>. - The <code><sendmail:send-mail></code> fragment is - replaced with an <code><error></code> element, if an - error occurs during the sending of the message.</p> + request puts the uploaded files automatically into the upload + directory and the files are accessible through the + <code>uploaded_file[12]</code> request parameters (make sure, + that <code>autosave-uploads</code> is set to <code>true</code> + in the <code>WEB-INF/web.xml</code> file of the Cocoon + context). By using + <code><xsp:expr>request.get("req-param")</xsp:expr></code> + you actually get an object of class + <code>org.apache.cocoon.servlet.multipart.Part</code>. + The <code><sendmail:send-mail></code> fragment is + replaced with an <code><error></code> element, if an + error occurs during the sending of the message.</p> <p>Another noteworthy item is the formatting of the body text - through a Java <code>StringBuffer</code>. Any formatting, that - would be placed inside the <code><sendmail:body></code> - element would be lost due to the internal workings of the - Sendmail logicsheet.</p> + through a Java <code>StringBuffer</code>. Any formatting, that + would be placed inside the <code><sendmail:body></code> + element would be lost due to the internal workings of the + Sendmail logicsheet.</p> </s1> @@ -253,14 +253,14 @@ <td>sendmail:attachment</td> <td> - </td> + </td> <td>Sets the attachment for this email. Attributes for setting name, mime-type, or an URL (e.g. using cocoon:-protocol!). Parameters can be set dynamically using <sendmail:param/> syntax. If an object is to be attached, it must be set this way. Use the following - expression to obtain the correct object from the request: - <code><xsp:expr>request.get("req-param")</xsp:expr></code>. + expression to obtain the correct object from the request: + <code><xsp:expr>request.get("req-param")</xsp:expr></code>. </td> </tr> @@ -271,8 +271,8 @@ </td> <td>Sets the recipients of a blind carbon copy of the - email. This can be a list of comma separated email - addresses.</td> + email. This can be a list of comma separated email + addresses.</td> </tr> <tr> @@ -293,7 +293,7 @@ </td> <td>Sets the recipients of a carbon copy of this email. This - can be a list of comma separated email addresses.</td> + can be a list of comma separated email addresses.</td> </tr> <tr> @@ -303,7 +303,7 @@ </td> <td>Sets the character set for encoding the message. This - tag has only an effect, if no attachments are send.</td> + tag has only an effect, if no attachments are send.</td> </tr> <tr> @@ -322,8 +322,8 @@ </td> <td>The IP-address or the name of the host, which should - deliver the email message. Better known as the mail - transfer agent or short MTA.</td> + deliver the email message. Better known as the mail + transfer agent or short MTA.</td> </tr> <tr> @@ -341,8 +341,8 @@ <td></td> <td>Sets the destination/to address of the email message. - This can be a list of comma separated email - addresses.</td> + This can be a list of comma separated email + addresses.</td> </tr> </table> @@ -350,8 +350,8 @@ <s1 title="Hint"> <p>Please read this <link - href="../actions/sendmail-action.html#hint">hint</link>, - since it applies here as well.</p> + href="../actions/sendmail-action.html#hint">hint</link>, + since it applies here as well.</p> </s1> </body> </document>
