Testing InputModules

Return-Path: Delivered-To: apmail-xml-cocoon-cvs-archive@xml.apache.org Received: (qmail 74798 invoked by uid 500); 4 Dec 2002 10:34:33 -0000 Mailing-List: contact cocoon-cvs-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: cocoon-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list cocoon-cvs@xml.apache.org Received: (qmail 11396 invoked by uid 500); 4 Dec 2002 09:51:11 -0000 Delivered-To: apmail-xml-cocoon2-cvs@apache.org Date: 4 Dec 2002 09:51:09 -0000 Message-ID: <20021204095109.35217.qmail@icarus.apache.org> From: haul@apache.org To: xml-cocoon2-cvs@apache.org Subject: cvs commit: xml-cocoon2/src/documentation/xdocs/userdocs/concepts modules.xml X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N haul 2002/12/04 01:51:09 Modified: src/documentation/xdocs/userdocs/concepts Tag: cocoon_2_0_3_branch modules.xml Log: remove obsolete note Revision Changes Path No revision No revision 1.1.2.5 +159 -131 xml-cocoon2/src/documentation/xdocs/userdocs/concepts/modules.xml Index: modules.xml =================================================================== RCS file: /home/cvs/xml-cocoon2/src/documentation/xdocs/userdocs/concepts/modules.xml,v retrieving revision 1.1.2.4 retrieving revision 1.1.2.5 diff -u -r1.1.2.4 -r1.1.2.5 --- modules.xml 18 Sep 2002 16:28:10 -0000 1.1.2.4 +++ modules.xml 4 Dec 2002 09:51:09 -0000 1.1.2.5 @@ -12,73 +12,73 @@ - -

- Many sitemap components serve a purpose regardless how the input is - obtained. Still, to provide a wide range of components to quickly get - you up to speed, variants for different inputs exist. Modules allow to - create generic components and plug-in input or output later. -

- This document will explain how modules work and how to make use of - them. If you plan on writing your own modules, it is highly recommended - to read - Developing With Apache Avalon. It is a very good description - of the underlying rationale and principles. -

- - -

- Currently, three different types of modules exist: Input modules - provide means to enumerate parameters and to retrieve them, output - modules allow storing of data and exhibit transaction like semantics, - database modules encapsulate different mechanisms for auto increment - columns of various database management systems. Please refer to the - javadoc documentation of these interfaces. -

- Input modules are modelled after request parameters. The main - difference is, that every method takes two additional arguments, the - request object and a configuration object. The configuration object is - used to allow arbitrarily complex instructions for the input module. - Apart from that, input modules are more or less a drop-in replacement. -

- Output modules are again very similar to using request - attributes. Basically, they provide a method to set an attribute to a - value. Again, a request and a configuration object is the only change - to request attributes. A fundamental difference is, however, that - output modules should exhibit transactional behaviour. Thus setting an - attributes implicitly starts a transaction that must be ended by - calling rollback or commit. Only if the transaction is completed by - calling commit, the values set should be visible. This is needed - e.g. by the database actions. -

- Database modules, actually named AutoIncrementModule, contains - configuration information how to retrieve a value for an auto increment - column. It is possible to obtain the value before inserting a row, - while inserting as part of the SQL or after successful insert. If the - value is obtained before inserting, it can be generated - externally. Currently, supported database management systems include - HSQL, Informix, MySQL, and querying the database for the current max - value. -

- - -

- Using any of these modules requires a two step setup process. Step one - has already been done for your for all modules that come with Apache - Cocoon. Exception to this rule are the auto increment modules: only the - HSQL module is already setup. -

- -

- Like other core components of Apache Cocoon, modules are declared in - cocoon.xconf. There are already too many to list here. -

- + +

+ Many sitemap components serve a purpose regardless how the input is + obtained. Still, to provide a wide range of components to quickly get + you up to speed, variants for different inputs exist. Modules allow to + create generic components and plug-in input or output later. +

+ This document will explain how modules work and how to make use of + them. If you plan on writing your own modules, it is highly recommended + to read + Developing With Apache Avalon. It is a very good description + of the underlying rationale and principles. +

+ + +

+ Currently, three different types of modules exist: Input modules + provide means to enumerate parameters and to retrieve them, output + modules allow storing of data and exhibit transaction like semantics, + database modules encapsulate different mechanisms for auto increment + columns of various database management systems. Please refer to the + javadoc documentation of these interfaces. +

+ Input modules are modelled after request parameters. The main + difference is, that every method takes two additional arguments, the + request object and a configuration object. The configuration object is + used to allow arbitrarily complex instructions for the input module. + Apart from that, input modules are more or less a drop-in replacement. +

+ Output modules are again very similar to using request + attributes. Basically, they provide a method to set an attribute to a + value. Again, a request and a configuration object is the only change + to request attributes. A fundamental difference is, however, that + output modules should exhibit transactional behaviour. Thus setting an + attributes implicitly starts a transaction that must be ended by + calling rollback or commit. Only if the transaction is completed by + calling commit, the values set should be visible. This is needed + e.g. by the database actions. +

+ Database modules, actually named AutoIncrementModule, contains + configuration information how to retrieve a value for an auto increment + column. It is possible to obtain the value before inserting a row, + while inserting as part of the SQL or after successful insert. If the + value is obtained before inserting, it can be generated + externally. Currently, supported database management systems include + HSQL, Informix, MySQL, and querying the database for the current max + value. +

+ + +

+ Using any of these modules requires a two step setup process. Step one + has already been done for your for all modules that come with Apache + Cocoon. Exception to this rule are the auto increment modules: only the + HSQL module is already setup. +

+ +

+ Like other core components of Apache Cocoon, modules are declared in + cocoon.xconf. There are already too many to list here. +

- - - defaultSkin - http://localhost:8080/cocoon - + + + defaultSkin + http://localhost:8080/cocoon + @@ -125,62 +125,90 @@ --> ]]> - -

- The above snippet declares a number of modules. After this, the - modules are accessible through the given name. Thus, when an - input-module is expected, it is sufficient to give the - name of a module, like header. -

- For the auto increment modules only one is declared as the name - "auto" has special meaning to the modular database - actions. If more than one is needed at the same time, the - configuration of the database actions needs to explicitly specify - which one to use. -

- -

- Two alternatives for using modules exist: -

- -

- Input modules can be used in a sitemap almost like a sitemap - variable. If the variable name contains a colon (":"), the - preceeding string is used as the name of the module to use and the - trailing string is passed to the module. The expression is replaced - with the string value returned from the module. -

- + +

+ The above snippet declares a number of modules. After this, the + modules are accessible through the given name. Thus, when an + input-module is expected, it is sufficient to give the + name of a module, like header. +

+ For the auto increment modules only one is declared as the name + "auto" has special meaning to the modular database + actions. If more than one is needed at the same time, the + configuration of the database actions needs to explicitly specify + which one to use. +

+ + +

+ The following alternatives for using modules exist: +

+ +

+ Input modules can be used in a sitemap almost like a sitemap + variable. If the variable name contains a colon (":"), the + preceeding string is used as the name of the module to use and the + trailing string is passed to the module. The expression is replaced + with the string value returned from the module. +

+ ]]> - -

- The above example uses the variable skin declared - e.g. by an action for the stylesheet to apply to the page. The - example below uses an input module instead. The way this module was - declared above allows to override the skin with a request parameter - named "skin". -

- - The above sitemap syntax is only available with the 2.1-dev version - of Apache Cocoon. - - + +

+ The above example uses the variable skin declared + e.g. by an action for the stylesheet to apply to the page. The + example below uses an input module instead. The way this module was + declared above allows to override the skin with a request parameter + named "skin". +

+ ]]> - - - -

- This depends on the component that is to be used. As an example the - CachingWildcardMatcher requires to set the - input-module on declaration. -

- + + + +

+ The input logicsheet allows easy use of InputModules from an + XSP. Currently, it provides tags for getting one value, an + array of values, and an Iterator for a Collection of + parameter names. +

+ + + + + + + + Testing InputModules + +

+ Parameter name=; +

+ Parameter cars=; +

+ + +]]> + + + +

+ This depends on the component that is to be used. As an example the + CachingWildcardMatcher requires to set the + input-module on declaration. +

+ ]]> - -

- By replacing the input module name with any of the other declared - input modules, this matcher can be used to match e.g. on session - attributes, request headers or even dates! -

- - - + +

+ By replacing the input module name with any of the other declared + input modules, this matcher can be used to match e.g. on session + attributes, request headers or even dates! +

+ + + ---------------------------------------------------------------------- In case of troubles, e-mail: webmaster@xml.apache.org To unsubscribe, e-mail: cocoon-cvs-unsubscribe@xml.apache.org For additional commands, e-mail: cocoon-cvs-help@xml.apache.org