Zim Applications’ Input Parameters

Zim Applications’ Input Parameters

Welcome to our Knowledge Base

Documentation | Blog | Demos | Support

< All Topics
Print

Zim Applications’ Input Parameters

 

Input parameters are those parameters supplied as input to the Zim application.

Parameters tend to work in the same way as the ZimCGI, except that:

  • The TEMPLATE parameter is required, except where a default parameter template has been specifed for a procedure.
  • There are more parameters with reserved meanings – namely PATHINFO, STYLE, PAGETEMPLATE and RENDER.
  • Parameters can come from HTTP sessions and cookies as well as form input.
  • Form parameters can come from both POST and GET requests.

 

N.B. Parameter names are not case sensitive.

Parameter sources

Input parameters can come from three different sources:

  • Form parameters (i.e. POST/GET).
  • Session parameters.
  • Cookie parameters.

 

You must specify the parameters to be passed to your Zim application in the TEMPLATE parameter, or the default parameter template for the procedure.

Normally, if the same parameter exists in several places then the form parameters have priority over the session parameters, and these have priority over the cookie parameters.

However, if a parameter has a name beginning with the prefix session. e.g. session.IsLoggedIn then it can only come from the HTTP session parameters.

Similarly, if a parameter has a name beginning with the prefix cookie. e.g. cookie.UserName then it can only come from the cookie parameters.

Parameters with new or changed meanings

Parameters with new or changed meanings, compared with the ZimCGI, are:

 

ZimCGI parameters which have been modified
TEMPLATEThe meaning and format of this parameter has not been changed, but it is required (unlike the ZimCGI), unless the procedure has a default parameter template.
DEBUGThe meaning and format of this parameter has not been changed – if you set the parameter DEBUG to any value in the request parameters then the debugging information will be sent to the client. However, the debugging information is a lot more comprehensive, including the raw output of the Zim database agent.
Note: For security reasons, any commands in the Zim database agent output are not processed in a DEBUG request.
Note also that a request for debugging information from a client will be ignored unless debug capability has been enabled.
Request information parameters
PATHINFOThe PathInfo of the request is placed in the PATHINFO parameter, which you can place in your TEMPLATE.
For example, say the ZimWeb servlet (ZII) is at the URL http:www.mycorp.com/ZII/servlet/ZII – if it receives a request for a URL relative to that e.g. http:www.mycorp.com/ZII/servlet/ZII/one/two, then the PATHINFO parameter would be set to /one/two.
REQUESTURLThe URL the client entered; N.B. this includes any PathInfo, but excludes any parameters.
SESSIONFROMCOOKIESet to 1 if the client HTTP session is being tracked through a cookie (e.g. the JSESSIONID cookie in Tomcat), otherwise 0.
N.B. This will be set on the second and subsequent calls to the servlet – the session is not set up the first time a client invokes the servlet. Of course, HTTP session tracking through cookies requires that cookies be enabled on the browser.
SESSIONFROMURLSet to 1 if the client http session is being tracked through URL rewriting, otherwise 0.
N.B. Session tracking does not currently work effectively through URL rewriting – instead you should track sessions by enabling cookies on the browser.
Authentication parameters
AUTHUSERNAMEThe user authenticated by the web server.
AUTHTYPEThe authentication method used by the web server – BASIC etc.
CLIENTUSERNAMEThe (not necessarily authenticated) user name the client is claiming.
CLIENTPASSWORDThe (not necessarily authenticated) password the client is claiming.
XSLT styling parameters
STYLEThis parameter indicates that a particular XSLT stylesheet is to be applied to the output of the Zim Server agent.
If the Zim Server agent output includes an apply-xslt: command, then the stylesheet specified in the STYLE parameter overrides the that specified by the apply-xslt: command.
The STYLE parameter specifies a file path relative to the base path of the ZimWeb application. If you have installed the ZimWeb in the manner described in the installation instructions then specifying STYLE as /styles/cool.xsl will refer to the file [TOMCAT_ROOT]/ZII/styles/cool.xsl.
If you specify STYLE=NONE then the Zim agent output (presumably XML) will be returned as-is, without the application of any XSLT or form template processing.
Note: specifying a STYLE automatically suppresses any XSL-FO rendering specified by the Zim Server agent, unless the RENDER parameter is also supplied.
Page template parameters
PAGETEMPLATE This parameter indicates that a particular page template is to be applied to the output of the Zim Server agent.
If the Zim Server agent output includes an apply-page-template: command, then the page template specified in the PAGETEMPLATE parameter overrides the that specified by the apply-page-template: command.
The PAGETEMPLATE parameter specifies a file path relative to the base path of the ZimWeb application. If you have installed the ZimWeb in the manner described in the installation instructions then specifying PAGETEMPLATE as /styles/fancy.html will refer to the file [TOMCAT_ROOT]/ZII/styles/fancy.html.
Read more about ZII page templates.
If you specify PAGETEMPLATE=NONE then the Zim agent output (presumably XML) will be returned as-is, without the application of any XSLT or form template processing.
Note: specifying a PAGETEMPLATE automatically suppresses any XSL-FO rendering specified by the Zim Server agent, unless the RENDER parameter is also supplied.
XSL Formatting Objects parameters
RENDERThis parameter indicates that the Zim agent output, or the result of the other content processing (typically XSLT), is to be treated as XSL Formatting Objects and rendered according to the RENDER parameter.
The two rendering options currently available are PDF (Adobe Portable Document Format), for which you would specify the value PDF, or alternatively RTF (Rich Text Format), for which you would specify the value RTF..
Note: that rendering to PDF is much more accurate than rendering to RTF.
If you specify RENDER=NONE then rendering is suppressed, and the XSL-FO is returned directly to the browser.
Was this article helpful?
0 out of 5 stars
5 Stars 0%
4 Stars 0%
3 Stars 0%
2 Stars 0%
1 Stars 0%
5
How can we improve this article?
Please submit the reason for your vote so that we can improve the article.

Leave a Reply

Your email address will not be published. Required fields are marked *

en_CAEnglish