Home >> All >> org >> apache >> cocoon >> [ acting Javadoc ]

•	org.apache.cocoon.acting.modular.* (7)

• org.apache.cocoon.acting: Javadoc index of package org.apache.cocoon.acting.


Package Samples:

• org.apache.cocoon.acting.modular

Classes:

• AbstractValidatorAction: Abstract implementation of action that needs to perform validation of parameters (from session, from request, etc.). All `validator' actions share the same description xml file. In such file every parameter is described via its name, type and its constraints. One large description file can be used among all validator actions, because each action should explicitely specify which parameters to validate - through a sitemap parameter. <root> <parameter name="username" type="string" nullable="no"/> <parameter name="role" type="string" nullable="no"/> <parameter name="oldpassword" ...
• AbstractDatabaseAction: Set up environment for configurable form handling data. It is important to note that all DatabaseActions use a common configuration format. This group of actions are unique in that they employ a terciary mapping. There is the Form parameter, the database column, and the type. Each configuration file must use the same format in order to be effective. The name of the root configuration element is irrelevant. <root> <connection>personnel<connection> <table> <keys> <key param="id" dbcol="id" type="int"/> </keys> <values> <value param="name" dbcol="name" ...
• FormValidatorAction: This is the action used to validate Request parameters. The parameters are described via the external xml file (its format is defined in AbstractValidatorAction). Variant 1 <map:act type="form-validator"> <parameter name="descriptor" value="context://descriptor.xml"> <parameter name="validate" value="username,password"> </map:act> The list of parameters to be validated is specified as a comma separated list of their names. descriptor.xml can therefore be used among many various actions. If the list contains only of * , all parameters in the file will be validated. Variant ...
• LocaleAction: LocaleAction is a class which obtains the request's locale information (language, country, variant) and makes it available to the sitemap/pipeline. Definition in sitemap: <map:actions> <map:action name="locale" src="org.apache.cocoon.acting.LocaleAction"/> </map:actions> Examples: <map:match pattern="file"> <map:act type="locale"> <map:generate src="file_{lang}{country}{variant}.xml"/> </map:act> </map:match> or <map:match pattern="file"> <map:act type="locale"> <map:generate src="file.xml?locale={locale}"/> </map:act> </map:match> ...
• DatabaseCookieAuthenticatorAction: This action is used to authenticate user by comparing several cookie values (username, password) with the values in database. The description of the process is given via external xml description file simiar to the one used for all actions derived from AbstractDatabaseAction. <root> <connection>personnel</connection> <table name="users_table> <select dbcol="username" cookie-name="username" to-session="username"/> <select dbcol="password" cookie-name="password" nullable="yes"/> <select dbcol="role" to-session="role" type="string"/> <select dbcol="skin" ...
• DatabaseAuthenticatorAction: This action is used to authenticate user by comparing several request fields (username, password) with the values in database. The description of the process is given via external xml description file simiar to the one used for all actions derived from AbstractDatabaseAction. <root> <connection>personnel</connection> <table name="users_table> <select dbcol="username" request-param="username" to-session="username"/> <select dbcol="password" request-param="password" nullable="yes"/> <select dbcol="role" to-session="role" type="string"/> <select dbcol="skin" ...
• DbXMLAuthenticatorAction: This action is used to authenticate user by comparing several request fields (username, password) with the values in a DBXML compliant database. The description of the process is given via external xml description file simiar to the one used for all actions derived from AbstractDatabaseAction. org.apache.xindice.client.xmldb.DatabaseImpl xmldb:xindice:///db/beta The values specified via "request-param" describe the name of HTTP request parameter, "element" indicates matching document node, "nullable" means that request-param which is null or empty will not be included in the WHERE clause. This ...
• SessionStateAction: Store the session's current state in a session attribute. To keep track of the state of a user's session, a string is stored in a session attribute in order to allow to chose between different pipelines in the sitemap accordingly. For added flexibility it is possible to use sub states as well. For this declare your own name for the session state attribute and give the number of sublevels plus the level to modify. (This is one based!) Sub states below the current one are removed from the session so that the default sub state will be reentered when the user returns. If you don't like this behaviour ...
• DatabaseAction: Abstract action for common function needed by database actions. The difference to the other Database*Actions is, that the actions in this package use additional components ("modules") for reading and writing parameters. In addition the descriptor format has changed to accomodate the new features. This action is heavily based upon the original DatabaseAddActions. Modes have to be configured in cocoon.xconf. Mode names from descriptor.xml file are looked up in the component service. Default mode names can only be set during action setup. The number of affected rows is returned to the sitemap with ...
• RequestParamAction: This action makes some request details available to the sitemap via parameter substitution. {context} - is the context path of the servlet (usually "/cocoon") {requestURI} - is the requested URI without parameters {requestQuery} - is the query string like "?param1=test" if there is one Additionlly all request parameters can be made available for use in the sitemap. if the parameter "parameters" is set to true. (A variable is created for each request parameter (only if it doesn't exist) with the same name as the parameter itself) Default values can be set for request parameters, by including sitemap ...
• ServerPagesAction: Allows actions to be written in XSP. This allows to use XSP to produce XML fragments that are later reused in generators. This action works in concert with the "action" logicheet, that offers actions-related services such as redirect or result map access, and the "capture" logicsheet that allows to capture parts of XSP-generated XML either as an XMLizable containing serialized SAX events, or as a DOM Node . As for generators, the XSP file name is set using the "src" attribute. This action accepts a single parameter, "output-attribute", which names the request attribute where the XSP-generated document ...
• SessionValidatorAction: This is the action used to validate Session parameters (attributes). The parameters are described via the external xml file (its format is defined in AbstractValidatorAction). Variant 1 <map:act type="session-validator"> <parameter name="descriptor" value="context://descriptor.xml"> <parameter name="validate" value="username,password"> </map:act> The list of parameters to be validated is specified as a comma separated list of their names. descriptor.xml can therefore be used among many various actions. Variant 2 <map:act type="session-validator"> <parameter name="descriptor" ...
• CookieValidatorAction: This is the action used to validate Cookie parameters (values). The parameters are described via the external xml file (its format is defined in AbstractValidatorAction). Variant 1 <map:act type="cookie-validator"> <parameter name="descriptor" value="context://descriptor.xml"> <parameter name="validate" value="username,password"> </map:act> The list of parameters to be validated is specified as a comma separated list of their names. descriptor.xml can therefore be used among many various actions. Variant 2 <map:act type="cookie-validator"> <parameter name="descriptor" ...
• RequestParameterExistsAction: This action simply checks to see if a given request parameter exists. It takes an arbitrary number of default parameters to check named 'parameter-name'. Non-default parameters need to be separated by spaces and passed as value of a sitemap parameter named 'parameters'. The action returns a map with all parameters if all of them exist and null otherwise. Parameter names can only be added to this list but no default parameters can be overridden by specific ones. This action is very closely related to @link{RequestParamAction} and FormValidatorAction . However this action is considerably simpler ...
• CookieCreatorAction: The CookieCreatorAction class create or remove cookies. The action needs these parameters: name the cookie name value the cookie value comment a comment to the cookie domain the domain the cookie is sent to path the path of the domain the cookie is sent to secure use a secure transport protocol (default is false) maxage Age in seconds. Use -1 to remove cookie. (default is 0; cookie lives within the session and it is not stored) version version of cookie(default is 0) If you want to set a cookie you only need to specify the cookie name. Its value is an empty string as default. The maxage is 0 that ...
• SendmailAction: The SendmailAction class sends email. The action needs four parameters: smtphost the smtp server to send the mail through from the email address the mail appears to be from to the email address the mail it sent to subject the subject of the email body the body of the email The class attempts to load all of these parameters from the sitemap, but if they do not exist there it will read them from the request. The exception is the smtphost parameter, which is assumed to be localhost if not specified in the sitemap. Note it's strongly recommended that the to address be specified by the sitemap, not ...
• DatabaseQueryAction: Executes an arbitrary query. The query is associated with a table and selected through the others mode. All keys and values are set in order of appearance, starting with keys, thus the query needs to have as many placeholders for prepared statement parameters. If it is an update query, the number of affected rows is returned to the sitemap. <table name="example"> <queries> <query mode="one">update example set count=count+1 where id=?</query> <query mode="two">select count, name from example where id=?</query> </queries> <keys> <key name="id"/> ...
• LangSelect: LangSelect Action returns two character language code to sitemap. Definition in sitemap: <map:actions> <map:action name="lang_select" src="org.apache.cocoon.acting.LangSelect"/> And you use it in following way: <map:match pattern="file"> <map:act type="lang_select"> <map:generate src="file_{lang}.xml"/> </map:act> {lang} is substituted with language code. eg. if user selects url ../file?lang=en then Sitemap engine generates file_en.xml source. Creation date: (3.11.2000 14:32:19) Modification date: (29.05.2001 0:30:01)
• TestAction: Demo action that uses componentized input / output layer. In order to stop combinatorial explosion of actions, matchers, and selectors they should instead use components to access their inputs and outputs. Available components include request parameters, attributes, headers, and session attributes. Which component to use can be specified upon setup via "input-module" and "output-module" tags through the name attribute. This particular action copies all available parameters obtained from the input component to the output component or, if a specific parameter is specified through parameter-name, ...
• ConfigurableComposerAction: The ComposerAction will allow any Action that extends this to access SitemapComponents. Basically a copy of ComposerAction that inherits from AbstractConfigurableAction .
• SessionPropagatorAction: This is the action used to propagate parameters into session. It simply propagates given expression to the session. If session does not exist, action fails. Additionaly it will make all propagated values available via returned Map. <map:act type="session-propagator"> <paramater name="example" value="{example}"> <paramater name="example1" value="xxx"> </map:act>
• SetCharacterEncodingAction: Sets the character encoding of parameters. Components use this encoding as default after the action. Configuration parameters: form-encoding (optional) The supposed encoding of the request parameter. These configuration options supported in both declaration and use time. If no encoding specified, the action does nothing.
• DatabaseAddAction: Adds record in a database. The action can update one or more tables, and can add more than one row to a table at a time. The form descriptor semantics for this are still in a bit of a state of flux. Note that if a secondary table relies on the value of a new primary key in a primary table, the primary key must be created using manual mode.
• SectionCutterAction: An action designed to set any number of variables, based on the current site section. The action matches the request uri against a configurable set of regular expressions (note: currently not implemented. Checking the beggining of the URI). When an expression matches, the action will set the configured variable in the Map.
• ResourceExistsAction: This action simply checks to see if a given resource exists. It checks whether the specified in the src attribute source exists or not. The action returns empty Map if it exists, null otherwise. Instead of src attribute, source can be specified using parameter named 'url' (this is old syntax).

Home | Contact Us | Privacy Policy | Terms of Service